1 / 27

Elastic Transactions Unleashing Concurrency of Transactional Memory

Elastic Transactions Unleashing Concurrency of Transactional Memory. Pascal Felber Vincent Gramoli Rachid Guerraoui. Goal : Concurrent Programming . Easiness : simple adaptation of sequential programming Extensibility : existing code should be re-usable Efficiency : high concurrency.

azure
Download Presentation

Elastic Transactions Unleashing Concurrency of Transactional Memory

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Goal: Concurrent Programming • Easiness: simple adaptation of sequential programming • Extensibility: existing code should be re-usable • 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.)

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

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

  8. Coarse-grained Locking • Coarse-grained: inefficient Insert(t) x y max max … z max

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

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

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

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

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

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

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

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

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

  18. Elastic Transactional Memory (ε-STM) • Elastic transactions: weaker than normal ones t insert(t) / search(y) x y max max … z max • 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 t insert(t) / search(y) x y max max … z max No conflict(insert(t), search(y)) if y≠t, y≠t.next, or t≠y.next.

  20. Elastic Transactional Memory (ε-STM) • Easiness: labeling “BEGIN(elastic)/END” is the only requirement (instead of “BEGIN(normal)/END”) • Extensibility: • move(x,y) = delete(x) + insert(y) • compatible with normal transactions: sum_all(){BEGIN(normal); … END();} • 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] Issues prevent automatization [Harris et al. TRANSACT’07]

  26. Conclusion

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

More Related