1. Elastic Transactions Unleashing Concurrency of Transactional Memory Pascal Felber Vincent Gramoli Rachid Guerraoui

2. Goal: Concurrent Programming 1.Easiness: simple adaptation of sequential programming 2.Extensibility: existing code should be re-usable 3.Efficiency: high concurrency

3. Pessimistic vs. Optimistic Paradigm Pessimistic: first validate, then execute – May I modify the data safely? – If so go on, otherwise wait. Optimistic: first execute, then validate – Execute & hope for the best. – In worst case, roll-back!

4. Pessimistic vs. Optimistic Paradigm ( cont'd.) Pessimistic approaches: Locks or Lock-free – Coarse-grained locking: large lock for mutual exclusion – Fine-grained locking: small multiple locks – Lock-free: universal primitives (e.g., Compare&Swap) Optimistic approach: Transactional Memory – Execute a transaction (tx), i.e., a set of operations – Check for potential conflicts (e.g., (write/read)-write) – Commit or abort so that conflicts are avoided

5. Pessimistic vs. Optimistic Paradigm ( cont'd.) EasyExtensibleEfficient PessimisticFine-grained locking ? Coarse-grained locking Lock-free universal primitives OptimisticTransactional models (either lock-based, lock-free, obs-free…)

6. Bucket Hash Table Example y y x x max @1 @2 … @k @ = Hash(x) z z max … one sorted linked list

7. Bucket Hash Table Example (cont’d.) 1.Easiness: simple basic insert/delete/search operations 2.Extensibility: move(x,y) = delete(x) + insert(y) 3.Efficiency: conflict(insert(y), search(x)) only if x=y, x=y.next, or y=x.next.

8. Coarse-grained Locking Coarse-grained: inefficient y y x x max @1 @2 … @k z z max … Insert(t)

9. Coarse-grained Locking Coarse-grained: inefficient y y x x max @1 @2 … @k z z max … Insert(t) conflict( insert(t), search(y) ) whereas y≠t, y≠t.next, and t ≠y.next. t t

10. Fine-grained locking Lazy alg. [Heller et al. OPODIS05]: Uneasy y y x x max @1 @2 … @k z z max … P2 delete P1 delete

11. Fine-grained locking Lazy alg. [Heller et al. OPODIS05]: Uneasy y y x x max @1 @2 … @k z z max … P2 delete P1 would like to insert P1 delete P2 would like to insert DEADLOCK!

12. Lock-free universal primitives Harris-Michael [DISC01,SPAA02]: Non-extensible y y x x max @1 @2 … @k z z max … Compare&Swap P1 deletes

13. Harris-Michael [DISC01,SPAA02]: Non-extensible Lock-free universal primitives y y x x max @1 @2 … @k z z max … Compare&Swap u u P1 deletes P1 inserts move(y,u) ≠ delete(y) + insert(u)

14. Harris-Michael [DISC01,SPAA02]: Non-extensible Lock-free universal primitives y y x x max @1 @2 … @k z z max … Compare&Swap y y P1 deletes P1 inserts move(x,y) ≠ delete(x) + insert(y) To become resizable, lock-free HT is completely re-factored [JACM 2006]. Yet the resulting HT is not movable. To become resizable, lock-free HT is completely re-factored [JACM 2006]. Yet the resulting HT is not movable.

15. Software Transactional Memories TinySTM, LSA-STM, SSTM, SwissTM: efficient? y y x x max @1 @2 … @k z z max … insert(t) / search(y)

16. Software Transactional Memories TinySTM, LSA-STM, SSTM, SwissTM: efficient? y y x x max @1 @2 … @k z z max … insert(t) / search(y) conflict( insert(t), search(y) ) whereas y≠t, y≠t.next, or t≠y.next. t t

17. Elastic Transactional Memory (ε-STM) Elastic transactions: weaker than normal ones y y x x max @1 @2 … @k z z max … insert(t) / search(y) t t

18. Elastic Transactional Memory (ε-STM) Elastic transactions: weaker than normal ones y y x x max @1 @2 … @k z z max … insert(t) / search(y) t t It is cut in 2 parts each w/ ops π(x,*) and π(y,*) if: - all writes are in the same part; - the first op of any part is a read; - there are no two writes on x and y between.

19. Elastic Transactional Memory (ε-STM) Elastic transactions: weaker than normal ones y y x x max @1 @2 … @k z z max … insert(t) / search(y) t t No conflict( insert(t), search(y) ) if y≠t, y≠t.next, or t≠y.next.

20. Elastic Transactional Memory (ε-STM) 1.Easiness: labeling “BEGIN(elastic)/END” is the only requirement (instead of “BEGIN(normal)/END”) 2.Extensibility: – move(x,y) = delete(x) + insert(y) – compatible with normal transactions: sum_all(){BEGIN(normal); … END();} 3.Efficiency: relax the atomic snapshot of traditional transactions

21. μBenchmarks

22. μBenchmarks (Cont’d.)

23. Related Work: Other Transactional Models Open Nesting: – Each sub-transaction commits independently from its parent transaction(s) Early Release: – Some reads may be forgotten (removed from r-set)

24. Related Work: Other Transactional Models Open Nesting: – Each sub-transaction commits independently from its parent transaction(s) – Programmer must identify commutative operations – Programmer must define inverse operations Early Release: – Some reads may be forgotten (release() method) – Programmer must carefully identify when and what should be released

25. Related Work: Other Transactional Models Open Nesting: – Each sub-transaction commits independently from its parent transaction(s) – Programmer must identify commutative operations – Programmer must define inverse operations Early Release: – Some reads may be forgotten (release() method) – Programmer must carefully identify when and what should be released Complex roll-back experienced [Ni et al. PPoPP’07] Complex roll-back experienced [Ni et al. PPoPP’07] Issues prevent automatization [Harris et al. TRANSACT’07] Issues prevent automatization [Harris et al. TRANSACT’07]

26. Conclusion EasyExtensibleEfficent PessimisticFine-grained locking ✖✖✓ Coarse-grained locking ✓✓✖ Lock-free universal primitives ✖✖✓ OptimisticTransactional model ✓✓✖ Open nesting, early release ✖✓✓ Elastic Transactions ✓✓✓

27. ε-STM http://lpd.epfl.ch/gramoli/php/estm