Algorithmics for Software Transactional Memory

1. Algorithmics for Software Transactional Memory Hagit AttiyaTechnion

2. Moore's Law is dead … says Gordon Moore (TechWorld, 4/2005) Intel announces a drastic change in its business strategy (San Francisco, 5/2004): «Multicore is the way to boost performance» Many applications will be concurrent • Forking threads is easy, • Handling the conflicts is hard!

3. Transactional Synchronization A transaction is a sequence of operations by a single process on a set of data items (data set) to be executed atomically We consider only read/write operations: Read set:the items read by T Write set:the items written by T Read X Write X Read Z Read Y

4. Transactional Synchronization A transaction is a sequence of operations by a single process on a set of data items (data set) to be executed atomically 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. Software Implementation of TM Data representation for transactions & data Algorithms to execute transactions in terms of low-levelprimitives (read, write, CAS…) on base objects (memory locations) Must provide • Opacity [Guerroui & Kapalka]or strict serializability [Papadimitriou] • Obstruction freedom

6. Typical Implementation Scheme • To write data item O, a transaction acquires O, possibly aborting the transaction that owns O (killer write) • To read an object, a transaction takes a snapshot to see if the system hasn’t changed since its previous reads; else T is aborted (careful read) • Or: validate the reads when the transaction asks to commit (optimistic read)

7. Algorithmics • Acquiring several data items • Validating that a set of values read is consistent Multi-location Synchronization Atomic Snapshot

8. (Full) Atomic Snapshot [Afek et al. 1990] n components Update a single component Scan all the components “at once” (atomically) Provides an instantaneous view of the whole memory update scan v1,…,vn ok

9. Partial Snapshot [Attiya, Guerraoui, Ruppert, 2008] n components Update a single component Scan components “at once” (atomically) Allows to read parts of the memory Worthwhile if we can do it more efficiently than a (full) scan update scan vi1,…,vir ok

10. Optimizing Partial Scans • Transactions that only observe the data • Empty write set • Be invisible (not write to base objects) • Avoid contention for the memory • Always terminate successfully (wait-free)

11. T1 T3 T1 Read(Y) Write(X1) Write(X2) T2 T3 Read(X2) Read(X1) DAP: Disjoint Access Parallelism Y X1 X2 Disjoint data sets  no contention Data sets are connected  may contend Improves scalability for large data structures by reducing interference

12. DAP: More Formally An STM implementation is disjoint access parallel if two 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

13. State of the Art

14. Inherent Tradeoff Theorem. There is no TM implementation that is DAPand has invisible & wait-free read-only transactions [Attiya, Hillel & Milani] Proof utilizes the notion of a flippable execution, used to prove lower bounds for atomic snapshot objects [Israeli, Shirazi] [Attiya, Ellen & Fatourou]

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

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

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

18. Why Flippable Executions? Lemma 1. The read-only transaction of q cannot terminate successfully Relies on strict serializabitly (linearizability) • Any interleaving of the transactions yields a result that can be achieved in a sequential execution of the same set of transactions (a serialization) • The serialization must preserve the real-time order of (non-overlapping) transactions

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

20. 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 X1 = l-2 X2= l-3 X1 = l X2= l-3 X1 = l X2= l-1 s1 … sl-1sl … sk q Serialization x

21. Constructing a Flippable Execution Lemma 2. In a DAP TM, two consecutive transactions writing to different data items do notcontend on the same base object. U1 U2

22. First contending access to o Last contending access to o Proof of Lemma 2 Towards a contradiction, assumme U1 and U2 contend on a base object Let o be the last base object accessed by U1 for which U2 has a contending access U1 U2

23. First contending access to o Last contending access to o Proof of Lemma 2 By contradictions, assumme U1 and U2 contend on a base object U1 and U2 have disjoint data sets & contend on a base object U1 Not DAP U2 U1 U2

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

25. Extensions… Also a Lower Bound: • A transaction with a data set of size t must write to t-2 base objects The results hold also for weaker TM consistency conditions: • Serializability • Snapshot Isolation

26. Algorithmics • Acquiring several locations • Validating that a set of values read is consistent Multi-location Synchronization Atomic Snapshot

27. Acquire nodes in the data set How to resolve conflicts with blocking operations (holding a required data item)? To reduce delays Multi-Location Synchronization

28. Acquire nodes in the data set How to resolve conflicts with blocking operations (holding a required data item)? To reduce delays To avoid deadlock Multi-Location Synchronization

29. E.g., [Touitou & Shavit] Acquired items by increasing order (e.g., of addresses) Avoids deadlocks But not delays Cannot be applied when data items are given in piecemeal… Multi-Location Synchronization: Classical Solution 8 6 10 5 13 2

30. Use a contention manager to decide which transaction has the object (the other aborts) The other operation aborts & restarts But this requires support from the operating system Does not have provable guarantees Multi-Location Synchronization:Practical STM Implementations

31. Multi-Location Synchronization: More Concurrency [Attiya, Hillel] • Acquire locks in arbitrary order • No need to know the data set in advance When there is a conflict between two transactions contending for a data item, either • Wait for the other operation • Abort & reset the other operation

32. Distributed Conflict Resolution Depends on the operations’ progress The more advanced operation wins • How to gauge progress? • What to do on a tie?

33. Who’s More Advanced? • The operation that locked more data items • If a less advanced operation needs an item • wait (blocking in a limited radius) orhelp the conflicting operation • If a more advanced operation needs an item • abort the conflicting operation and claim the item

34. What about Ties? 2 2 When two transactions locked the same number of items Each transaction has a descriptorwith a lock Use DCAS to race for locking the two descriptors • Winner calls the shots…

35. Wrap-Up • Can be shown to guarantee progress in small neighborhoods • If I take many steps, then a transaction within “short distance” completes • The distance depends on size of the data set. • Can be made non-blocking / wait-free • By integrating a helping mechanism In a graph on the transactions defined by data conflicts

36. Measuring Concurrency: Spatial Relations between Operations A set of operations induces a conflict graph Nodes represent items Edges connect items of the same operation Chains of operations Paths Distance is length of path (here, 2)

37. Measuring Concurrency: Spatial Relations between Operations Disjoint access Non adjacent edges Distance is infinite Overlapping operations Adjacent edges Distance is 0 d-neighborhood of an operation: all operations at distance ≤ d

38. Formally: Interference between Operations Disjoint access Overlapping operations Non-overlapping operations Provides more concurrency & yields better throughput Interference inevitable Should not interfere! no interference

39. A Lot More to be Done • Better algorithms for partial snapshots, incorporated into full-fledged STM • Other lower bounds (w/ weaker notions of DAP or weaker consistency conditions) • More precise definitions of concurrency(& their practical validation) Better and simpler algorithms • Definitions of other STM properties (liveness, responsiveness)

40. Thank you!