Safety Definitions and Inherent Bounds of Transactional Memory

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

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. 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

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

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. 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. Model of Transactional Memory • Operation = invocation+ response events • Invocation events: try-commit, try-abort • Response events: commit, abort • A (high-level) historyH 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. 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. 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. W(x,1) C R(x,1) R(y,2) A W(x,2) W(y,2) C 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 p1 p2

11. x.Inc() x.Inc() x.Inc() 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 p1 p2 p3

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. 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. 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. W(x,1) tC C R(x,1) tC C 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 p1 p2

16. W(x,1) R(x,5) 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 p1 p2

17. W(x,1) C R(x,1) R(y,2) A W(x,2) W(y,2) C 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 p1 p2

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. 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. 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. T1 T3 T1 Read(Y) Write(X1) Write(X2) T2 T3 Read(X2) Read(X1) Implementation Restrictions Y • DAP: Disjoint-Access Parallelism X1 X2 Disjoint data sets  no contention Data sets are connected  may contend Improves scalability for large data structures by reducing interference

22. DAP: More Formally An STM implementation is disjoint-access parallel if two concurrent transactions T1 and T2access the same base objectONLY IF the data sets of T1 and T2are connected. The data sets of T1 & T2 either intersect or are connected via other transactions

23. Questions? (Coffee) Break

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. 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 R11 … R1k-1 R1k p1 W21 … W2k p2

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) R11 … R1k-1 R1k p1 W21 … W2k p2

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■ R11 … R1k-1 R1k p1 W21 … W2k p2

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. Flippable Execution w/ 2 Updaters U0 … Ul-1 … Uk p1 Ek U1 …Ul … p2 s1 … sl-1sl … sk q A complete transaction in which p1 writes l-1 to X1 A read-only transaction by q that reads X1 , X2

30. U0 … Ul-1 … Uk p1 U1 …Ul … p2 s1 … sl-1sl … sk q Flippable Execution w/ 2 Updaters Ek Indistinguishable from executions where the order of (each pair of) updates is flipped… In one of two ways (forward and backward).

31. U0 … Ul-1 … Uk p1 U1 …Ul … p2 s1 … sl-1sl … sk q Flippable Execution: Forward Flip Ek

32. Flippable Execution: Forward Flip U0 … Ul-1 … Uk p1 U1 …Ul … p2 s1 … sl-1sl … sk q Forward Flip

33. U0 … Ul-1 … Uk p1 U1 …Ul … p2 s1 … sl-1sl … sk q Flippable Execution: Forward Flip Ek Forward Flip U0 … Ul-1 … Uk p1 U1 …Ul … p2 s1 … sl-1sl … sk q

34. U0 … Ul-1 … Uk p1 U1 …Ul … p2 s1 … sl-1sl … sk q Flippable Execution: Backward Flip Ek

35. Flippable Execution: Backward Flip U0 … Ul-1 … Uk p1 U1 …Ul … p2 s1 … sl-1sl … sk q Backward Flip

36. U0 … Ul-1 … Uk p1 U1 …Ul … p2 s1 … sl-1sl … sk q Flippable Execution: Backward Flip Ek Backward Flip U0 … Ul-1 … Uk p1 U1 …Ul … p2 s1 … sl-1sl … sk q

37. Why Flippable Executions? 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

38. U0 Ul-1 Uk U1 …Ul … Serialization of Ek U0 … Ul-1 … Uk p1 Ek U1 …Ul … p2 Returns (l-1,l-2) s1 … sl-1sl … sk q Serialization of Ek: Possible serialization point

39. U0 Ul-1 Uk U0 U1 …Ul Ul-1 … Uk U1 …Ul … Nowhere to Serialize U0 … Ul-1 … Uk p1 Indistinguishable from some flip (say, backward) Ek U1 …Ul … p2 Returns (l-1,l-2) s1 … sl-1sl … sk q Serialization U0 … Ul-1 … Uk p1 BW Flip Still returns (l-1,l-2) U1 …Ul … p2 s1 … sl-1sl … sk q Serialization x X1 = l-3 X2= l-2 X1 = l-3 X2= l X1 = l-1 X2= l

40. Lemma 2 In a DAP TM, two consecutive txs U1, U2 from a quiescent configuration, that write to disjoint data sets do notcontend on the same base object.

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

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

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 Ul & Ul-1do 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. The Assumptions are Necessary

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

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!