1. Safety Definitions and Inherent Bounds of Transactional Memory Eshcar Hillel

2. 2 Transactional Memory Concurrency control mechanism Concurrent processes synchronize via in-memory transactions Inspired by database transactions A transaction is  a sequence of operations  on a set of data items (data set)  to be executed atomically

3. 3 The Specification (Signature) of Transactions A transaction (T) applies operations on high-level data items In general Read and Write operations:  Read set: the items read by T  Write set: the items written by T Other operations, such as:  Push (into a queue)  Remove (from a list)  Increment (a counter) Read X Write X Read Z Read Y Read X Write X Read Z Read Y

4. 4 The Specification (Signature) of Transactions A transaction (T) applies operations on high-level data items In general Read and Write operations:  Read set: the items read by T  Write set: the items written by T A transaction ends either by committing  all its updates take effect or by aborting  no update is effective Read X Write X Read Z Read Y Commit/ Abort Read X Write X Read Z Read Y Commit/ Abort

5. 5 What is A Correct Implementation? Txs appear to be executed sequentially Committed txs take effect instantaneously  at some single unique point in time Aborted transaction are discarded  never become visible All transactions observe a consistent state (view) Additionally, transactions are expected to  Preserve their real time order  Allow Read operations return not the last written value

6. 6 Outline of This Talk Model of TM Safety conditions Liveness conditions Implementations restrictions (Next hour) Inherent limitations on TMs  Time complexity lower bound  Impossibility result

7. 7 Model of Transactional Memory Operation = invocation + response events Invocation events: try-commit, try-abort Response events: commit, abort A (high-level) history H is  a sequence of invocation and response events  performed by all txs in a given execution  well-formed In a sequential (serial) history S txs run sequentially

8. 8 What is A Correct Implementation? Safety Conditions Candidates Serializability: every history is equivalent to some sequential history  Do not preserve real time order Strict serializability: (like serializability and)  Preserves real time order  Read operations must return the last written value 1-copy serializability: (like serializability and)  Allows a Read to return not the last written value  Assumes only Read and Write operations

9. 9 What is A Correct Implementation? Safety Conditions Candidates Global atomicity:  Distributed db  Each transaction is divides into subtransactions  executed locally in different sites  All sites must commit or all abort  Allows a Read operation to return not the last written value  Do not limit to Read/Write operations  Concerns only committed transactions, aborted transactions may access inconsistent state

10. 10 What is A Correct Implementation? Safety Conditions Candidates Global atomicity + strict recovability:  if a tx T updates an item, then no other tx applies any operation to this item until T either commits or aborts  Insufficient p1p1 p2p2 W(x,2) W(y,2) C W(x,1) C R(x,1) R(y,2) A

11. 11 What is A Correct Implementation? Safety Conditions Candidates Global atomicity + strict recovability:  if a tx T updates an item, then no other tx applies any operation to this item until T either commits or aborts  Insufficient  And in fact, too strict p2p2 p3p3 x.Inc() p1p1

12. 12 What is A Correct Implementation? Opacity In a complete history all txs are completed Complete(H) is a set of all possible completions of H in which  Every commit-pending tx is committed/aborted  Other live txs are aborted Visible(S) is the longest subsequence of S  Committed txs  At most one aborted tx at the suffix of S

13. 13 What is A Correct Implementation? Opacity A history H ensures opacity if for every prefix H' of H, some history in Complete(H') is equivalent to a sequential history S, such that: S preserves the real-time order of H' For every complete prefix S' of S, Visible(S') is legal

14. 14 What is A Correct Implementation? Opacity - Refined A history H ensures opacity if some history in Complete(H) is equivalent to a sequential history S, such that: S preserves the real-time order of H Visible(S) is legal

15. 15 What is A Correct Implementation? Opacity - Refined A history H ensures opacity if for every prefix H' of H, some history in Complete(H') is equivalent to a sequential history S, such that: S preserves the real-time order of H' Visible(S) is legal p1p1 p2p2 R(x,1) tC C W(x,1) tC C

16. 16 What is A Correct Implementation? Opacity A history H ensures opacity if for every prefix H' of H, some history in Complete(H') is equivalent to a sequential history S, such that: S preserves the real-time order of H' For every complete prefix S' of S, Visible(S') is legal p1p1 p2p2 R(x,5) W(x,1)

17. 17 What is A Correct Implementation? Opacity A history H ensures opacity if for every prefix H' of H, some history in Complete(H') is equivalent to a sequential history S, such that: S preserves the real-time order of H' For every complete prefix S' of S, Visible(S') is legal p1p1 p2p2 W(x,2) W(y,2) C W(x,1) C R(x,1) R(y,2) A

18. 18 Liveness Conditions Obstruction-free: if a transaction is (eventually) running solo then it completes Nonblocking: always some tx terminate successfully Wait-free: all txs always terminate successfully

19. 19 Implementing TM in Software Data representation for txs & data Algorithms to execute operations in terms of (low-level) primitives on base objects e.g.,  read  write  CAS

20. 20 Implementation Restrictions Progressive: abort transactions only on real conflicts Invisible reads: no base object is modified during read operations Read-only txs only observe the data  Empty write set  Invisible: not modify any base object  Invisibility helps avoid contention for the memory Single version: store only latest committed values in items  Vs multi-version TMs

21. 21 Implementation Restrictions T1T1 Read(Y) Write(X 1 ) T2T2 Write(X 2 ) T3T3 Read(X 2 ) Read(X 1 ) Disjoint data sets  no contention Data sets are connected  may contend Y X2X2 X1X1 T3T3 T1T1 Improves scalability for large data structures by reducing interference DAP: Disjoint-Access Parallelism

22. 22 DAP: More Formally An STM implementation is disjoint-access parallel if two concurrent transactions T 1 and T 2 access the same base object ONLY IF the data sets of T 1 and T 2 are connected. The data sets of T 1 & T 2 either intersect or are connected via other transactions

23. Questions? (Coffee) Break

24. 24 Time Complexity Lower Bound Theorem: Some operation in a progressive, single-version TM implementation that ensures opacity and uses invisible reads has Ω(k) time complexity  k is the number of items  The proof refers to the size of the data set (which can be as big as the number of items)

25. 25 Time Complexity Lower Bound Proof intuition: Consider an execution of two txs T1, T2:  T1 reads k-1 items  T2 writes to k items and commits  T1 reads an item written by T2 p1p1 p2p2 R 1 1 … R 1 k-1 R1kR1k W 2 1 … W 2 k

26. 26 Time Complexity Lower Bound Proof intuition: T1 cannot abort if the view is consistent (progressive) If T1 returns a value then it returns the value written by T2(single version) p1p1 p2p2 R 1 1 … R 1 k-1 R1kR1k W 2 1 … W 2 k

27. 27 Time Complexity Lower Bound Proof intuition: T1 needs to validate the k-1 first items (opacity) T2 cannot help/notify T1 in case of inconsistent view (invisible reads)  T1 needs to do the job - Ω(k) steps - by itself ■ p1p1 p2p2 R 1 1 … R 1 k-1 R1kR1k W 2 1 … W 2 k

28. 28 Impossibility Result Theorem. There is no DAP implementation with invisible & wait-free read-only transactions of an opaque TM Proof utilizes the notion of a flippable execution, used to prove lower bounds for atomic snapshot objects [Attiya, Ellen & Fatourou]

29. 29 Flippable Execution w/ 2 Updaters p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k A complete transaction in which p 1 writes l-1 to X 1 A read-only transaction by q that reads X 1, X 2 EkEk

30. 30 Flippable Execution w/ 2 Updaters p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k EkEk Indistinguishable from executions where the order of (each pair of) updates is flipped… In one of two ways (forward and backward).

31. 31 Flippable Execution: Forward Flip p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k EkEk

32. 32 Flippable Execution: Forward Flip p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k Forward Flip

33. 33 Flippable Execution: Forward Flip p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k EkEk p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k Forward Flip

34. 34 Flippable Execution: Backward Flip p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k EkEk

35. 35 Flippable Execution: Backward Flip p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k Backward Flip

36. 36 Flippable Execution: Backward Flip p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k EkEk p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k Backward Flip

37. 37 Lemma 1 The read-only transaction of q cannot terminate successfully Relies on strict serializabitly  Any history is equivalent to a sequential history of the same set of transactions (a serialization)  The serialization must preserve the real-time order of (non-overlapping) transactions Why Flippable Executions?

38. 38 Serialization of E k p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k EkEk U 1 … U l …U 0 U l-1 U k Serialization of E k : Possible serialization point Returns (l-1,l-2)

39. 39 Nowhere to Serialize p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k EkEk U 1 … U l …U 0 U l-1 U k Serialization Returns (l-1,l-2) p1p1 p2p2 q s 1 … s l-1 s l … s k U 1 … U l … U 0 … U l-1 … U k BW Flip Still returns (l-1,l-2) U 1 … U l U l-1 … U k U0U0 Serialization x Indistinguishable from some flip (say, backward) X 1 = l-3 X 2 = l-2 X 1 = l-3 X 2 = l X 1 = l-1 X 2 = l

40. 40 Lemma 2 In a DAP TM, two consecutive txs U 1, U 2 from a quiescent configuration, that write to disjoint data sets do not contend on the same base object.

41. 41 Proof of Lemma 2 Assume U 1 and U 2 contend on some base object Let o be the last base object accessed by U 1 for which U 2 has a contending access U1U1 C U2U2 Last contending access to o First contending access to o

42. 42 Proof of Lemma 2 C U2U2 U1U1 U1 and U2 have disjoint data set and they contend on some base object Not a DAP Implementation U1U1 C U2U2 Last contending access to o First contending access to o

43. 43 Completing the Proof Show that a flippable execution exists  The steps of the read-only transaction can be removed (since it is invisible)  Since their data sets are disjoint, transactions U l & U l-1 do not “communicate” (by Lemma 2)  Can be flipped  By Lemma 1, the read-only transaction cannot terminate successfully  If aborts, can apply the same argument again…

44. 44 The Assumptions are Necessary Read-only Tx termination Invisible read-only Tx DAPAlgorithm  [Herlihy, Luchangco, Moir & Scherer]  [Avni & Shavit]  [Riegel, Felber & Fetzer] ~~  Harris, Fraser & Pratt]

45. 45 Also a Lower Bound A transaction with a data set of size t must write to t-1 base objects

46. 46 Sources On the correctness of transactional memory, Rachid Guerraoui, Michal Kapalka, PPOPP 2008 Inherent Limitations on Disjoint-Access Parallel Implementations of Transactional Memory, Hagit Attiya, Eshcar Hillel, and Alessia Milani, TRANSACT 2009 Thank you!