Программная транзакционная память - пример компоновки

Пример, когда блокировки не создаются в Java:

class Account{
  float balance;
  synchronized void deposit(float amt){
    balance += amt;
  }
  synchronized void withdraw(float amt){
    if(balance < amt)
      throw new OutOfMoneyError();
    balance -= amt;
  }
  synchronized void transfer(Account other, float amt){
    other.withdraw(amt);
    this.deposit(amt);
  }
}

Итак, депозит в порядке, вывод в порядке, но перевод не в порядке: если A начинает передачу в B, когда B начинает передачу в A, может возникнуть тупиковая ситуация.

Теперь в Haskell STM:

withdraw :: TVar Int -> Int -> STM ()
withdraw acc n = do bal <- readTVar acc
                    if bal < n then retry
                    writeTVar acc (bal-n)

deposit :: TVar Int -> Int -> STM ()
deposit acc n = do bal <- readTVar acc
                   writeTVar acc (bal+n)

transfer :: TVar Int -> TVar Int -> Int -> STM ()
transfer from to n = do withdraw from n
                        deposit to n

Поскольку явной блокировки нет, withdraw и deposit естественно составляют transfer. Семантика по-прежнему гарантирует, что в случае неудачи вывода произойдет сбой всей передачи. Это также гарантирует, что снятие и депозит будут выполняться автоматически, поскольку система типов гарантирует, что вы не сможете вызвать перевод за пределы atomically.

atomically :: STM a -> IO a

Этот пример взят из следующего: http://cseweb.ucsd.edu/classes/wi11/cse230/static/lec-stm-2x2.pdf На основе этого документа вы, возможно, захотите прочитать: http://research.microsoft.com/pubs/74063/beautiful.pdf

Перевод примера Птивала на Clojure:

;; (def example-account (ref {:amount 100}))

(defn- transact [account f amount]
  (dosync (alter account update-in [:amount] f amount)))

(defn debit [account amount] (transact account - amount))
(defn credit [account amount] (transact account + amount))
(defn transfer [account-1 account-2 amount]
  (dosync
    (debit account-1 amount)
    (credit account-2 amount)))

Таким образом, debit и credit можно вызывать сами по себе, и, как и в версии Haskell, транзакции гнездятся, поэтому вся transfer операция является атомарной, повторные попытки будут происходить при коллизиях фиксации, вы можете добавить валидаторы для согласованности и т. Д.

И, конечно же, семантика такова, что они никогда не зайдут в тупик.

Вот пример Clojure:

Предположим, у вас есть вектор банковских счетов (в реальной жизни вектор может быть несколько длиннее ....):

(def accounts 
 [(ref 0) 
  (ref 10) 
  (ref 20) 
  (ref 30)])

(map deref accounts)
=> (0 10 20 30)

И функция «перевода», которая безопасно переводит сумму между двумя счетами за одну транзакцию:

(defn transfer [src-account dest-account amount]
  (dosync
    (alter dest-account + amount)
    (alter src-account - amount)))

Что работает следующим образом:

(transfer (accounts 1) (accounts 0) 5)

(map deref accounts)
=> (5 5 20 30)

Затем вы можете легко составить функцию передачи для создания транзакции более высокого уровня, например, для перевода с нескольких учетных записей:

(defn transfer-from-all [src-accounts dest-account amount]
  (dosync
    (doseq [src src-accounts] 
      (transfer src dest-account amount))))

(transfer-from-all 
  [(accounts 0) (accounts 1) (accounts 2)] 
  (accounts 3) 
  5)

(map deref accounts)
=> (0 0 15 45)

Обратите внимание, что все множественные переводы произошли в одной комбинированной транзакции, т.е. можно было «составить» более мелкие транзакции.

Сделать это с помощью блокировок будет очень сложно: если предположить, что учетные записи должны быть индивидуально заблокированы, вам нужно будет сделать что-то вроде установления протокола для порядка получения блокировки, чтобы избежать взаимоблокировок. Как справедливо отмечает Джон, в некоторых случаях это можно сделать, отсортировав все блокировки в системе, но в большинстве сложных систем это невозможно. Совершить ошибку, которую трудно обнаружить, очень легко. STM избавляет вас от всей этой боли.

А чтобы сделать пример trprcolin еще более идиоматичным, я бы предложил изменить порядок параметров в функции transact и сделать определения дебет и кредит более компактными.

(defn- transact [f account amount]
    ....  )

(def debit  (partial transact -))
(def credit (partial transact +))