CPL 2016, week 13 Software transactional memory Oleg Batrashev - PowerPoint PPT Presentation

CPL 2016, week 13 Software transactional memory Oleg Batrashev Institute of Computer Science, Tartu, Estonia May 2, 2016

Overview Last weeks ◮ Clojure language core ◮ Immutable data structures ◮ Clojure simple state and design This week ◮ Software transactional memory (STM) Next weeks ◮ Agents in Clojure

Software transactional memory 68/83 Transactions - Outline Software transactional memory Transactions Software transactional memory

Software transactional memory 69/83 Transactions - ACID properties ◮ long used with databases ◮ result is either abort or commit ◮ actions with ◮ atomicity – all or none effects of the action become visible ◮ consistency – data stays in consistent state after a transaction ◮ isolation – during its work the action is “completely” unaffected by other threads ◮ durability – survives system failures ◮ Clojure STM transactions satisfy atomicity, consistency and isolation ◮ durability

Software transactional memory 70/83 Transactions - Isolation levels Not as obvious as may seem. Concurrency with ANSI isolation levels 1. serializable – ideal case, as if run sequentially 2. repeatable read – new data may interfere (where clause in SQL) ◮ phantom reads – second read returns more rows than first read 3. read committed – see the results of other transactions ◮ non-repeatable reads – read data changed by another commit 4. read uncommitted – see the changes in other transactions ◮ dirty reads – read data changed in another transaction

Software transactional memory 71/83 Transactions - Isolation levels (2) There is a criticism that ANSI levels ◮ too ambiguous ◮ does not cover all possible scenarios! See A Critique of ANSI SQL Isolation Levels (1995)

Software transactional memory 72/83 Software transactional memory - Outline Software transactional memory Transactions Software transactional memory

Software transactional memory 73/83 Software transactional memory - Classical problem ◮ transfer money from bankA to bankB (defn transfer [from to amount] (reset! from (- @from amount )) (reset! to (+ @to amount ))) ◮ Works without problems with single thread (def bankA (atom 20.0)) (def bankB (atom 10.0)) (transfer bankA bankB 4.0) (println @bankA) ; -> 16.0 (println @bankB) ; -> 14.0 ◮ deref/reset! is not atomic, so two threads may end up with incorrect result ◮ classical Java solution uses locks

Software transactional memory 74/83 Software transactional memory - Atomic is not enough ◮ make both operations atomic themselves (defn transfer2 [from to amount] (swap! from (fn [v] (- v amount ))) (swap! to (fn [v] (+ v amount )))) ◮ both swap! operations are atomic themselves ◮ however, if the second one fails (by any reason), the first one has already removed money from the first account ◮ it is required to restore the original state ◮ there are more complex examples with many reads/writes

Software transactional memory 75/83 Software transactional memory - Refs ◮ mutable entities that STM operates with ◮ must be accessed within a transaction ( dosync ) ◮ @/deref – read value of a ref ◮ inside transaction has repeatable read semantics ◮ in fact uses the value that was at the start of the transaction ◮ can do that using versions (explanation follows) ◮ ref-set – sets the value inside a transaction ◮ (alter ref update-fn & args...) – changes the value inside the transaction ◮ other transactions see it only after this commits ◮ commute – special case where mutation time is not critical ◮ re-executed at the end of a transaction if needed

Software transactional memory 76/83 Software transactional memory - STM Example ◮ banking example (def bankC (ref 20.0)) (def bankD (ref 10.0)) ◮ using deref and ref-set (defn transfer3 [from to amount] (dosync (ref -set from (- @from amount )) (ref -set to (+ @to amount )))) ◮ using alter (defn transfer4 [from to amount] (dosync (alter from (fn [v] (- v amount ))) (alter to (fn [v] (+ v amount )))))

Software transactional memory 77/83 Software transactional memory - STM Diagram

Software transactional memory 78/83 Software transactional memory - STM in Clojure multiversion concurrency control (MVCC) in Clojure (implementation may differ from these semantics) ◮ every transaction has start time ◮ every ref has version – time of last commit ◮ read fails if current transaction start time < ref time, transaction restarted unless ◮ copy has been made earlier on a write ◮ or there is appropriate version in the ref history queue (see next slide) ◮ creates in-transaction copy for every ref written in transaction ◮ copies are saved to the ref on commit, if their versions (times) has not been changed since the start of the transaction

Software transactional memory 79/83 Software transactional memory - Ref history queue ◮ every ref has history queue of previous ref values (ref -history -count rf) ◮ initially history is not maintained (count=0), even when written ◮ history queue count is increased if there is failed read (see previous slide) ◮ no actual value is yet stored at this point ◮ value is stored on any following commit ◮ idea: transaction need not be restarted if there is the version in the history that was at the start of the transaction ◮ ref-min-history, ref-max-history (see ref documentation)

Software transactional memory 80/83 Software transactional memory - Write-skew ◮ value used in a transaction that is never written, but may be modified at the end of the transaction ◮ book example: daylight parameter that defines how much damage is inflicted in the battle ◮ my example: max energy available <= sum of consumed energies ◮ if max energy is rewritten while transaction changes one of consumed energies ◮ transaction uses historical value of the max energy ◮ Clojure solution: ensure command – as (ref-set a @a) but more efficient ◮ does not cause other transactions to fail

Software transactional memory 81/83 Software transactional memory - Livelock problem ◮ one long transaction ◮ many short transactions that modify a value read or written by the long one ◮ read fails because history queue needs to grow very long before long transaction may succeed ◮ write fails because confilcted value always overwritten when long transaction finishes, so it has to restart Guideline: ◮ try to reduce number of refs with potential conflict ◮ try to keep transactions short

Software transactional memory 82/83 Software transactional memory - Summary ◮ Use two levels in your program: 1. immutable state of objects 2. stored in mutable refs that are modified in transactions ◮ for example 1. game state (field state, player states) is stored in immutable structures 2. game itself is stored in mutable ref that may be modified by several threads (e.g. socket listener threads)