1 / 22

On the COST of concurrency In Transactional Memory

On the COST of concurrency In Transactional Memory. Petr Kuznetsov TU Berlin/DT-Labs Joint work with Srivatsan Ravi. Euro-TM, 2011. STM is about ease-of-programming and efficient use of concurrency. Does it come with a cost?.

iman
Download Presentation

On the COST of concurrency In 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. On the COST of concurrency In Transactional Memory Petr Kuznetsov TU Berlin/DT-Labs Joint work with Srivatsan Ravi Euro-TM, 2011

  2. STM is about ease-of-programming and efficient use of concurrency Does it come with a cost?

  3. Ease-of-programming: transactions with all-or-nothing semantics • Opacity:total order on transactions, including aborted ones, every read returns the last committed value • Concurrency: running multiple transactions in parallel • When a transaction must commit?

  4. Progress conditions: when to commit? • Single-lock: if no overlap with another transaction • Zero concurrency • Progressiveness: if no overlap with a conflictingtransaction • Some concurrency • Permissiveness: whenever possible (without affecting correctness) • Maximal (?) concurrency

  5. How to measure the cost of concurrency? • The number of expensive synchronization patterns [Attiya et al., POPL 2011] : • Read-after-write (RAW) • Atomic-write-after-read (AWAR)

  6. Our results • In every permissive STMs, a transaction performs Ω(k) RAW/AWAR patterns for a read set of size k • There exist progressive STMs that incur at most one RAW or AWAR per transaction

  7. Read-after-Write: imposing order in relaxed memory models In the code In almost all modern architectures ... write(X,1) read(Y) ... ... read(Y) ... write(X,1) ... Read-after write reordering

  8. Enforcing the order • read-after-write (RAW) fence ... write(X,1) fence() // enforce the order read(Y) ...

  9. Enforcing the order • atomic-write-after-read (AWAR) • E.g., CAS, TAS, fetch&add,… atomic{ read(Y) ... write(X,1) }

  10. Why care about RAW/AWARs? • One RAW fences/AWAR takes ~50 RMRs! • But [Attiya et al., POPL 2011] any implementation that exports strongly non-commutativemethods must use RAW/AWARs • Queues, counters, sets,… • Mutual exclusion • … and transactions in STMs

  11. Non-commutative transactions T1influences T2 and T2influences T1 => • T1 must write to some base object x • … and then read from some y≠x • (or AWAR is performed) At least one RAW/AWAR is used in T1 T1 W(X,1) TryC R(Y) W(Y,1) R(X) TryC T2

  12. In single-lock STMs, every reading and updating committed transaction performs at least one RAW/AWAR Extends to progressive and permissive STMs

  13. Permissive STMs [R(Xm)] and [W(Xm);TryC] are strongly non-commutative => T3 enforces R(Xm) to perform a RAW/AWAR =>T1 performs Ω(m) RAW/AWARs T1 R(X1) R(X2) ... R(Xm) T2 W(X1) TryC T3 R(X1) W(Xm) TryC

  14. In permissive STMs, a transaction performs at least one RAW/AWAR per read What about weaker progress conditions?

  15. What about progressiveness? Constant (multi) RAW/AWAR implementations: • Multi-trylocks: acquire a lock on a set of objects using one multi-RAW • mCAS: atomically verify the read-set and update the write set using at most one AWAR No RAW/AWAR in read-only or aborted transactions

  16. Protected data • Intuition: at some moment, every transaction must protect all objects in its write set • E.g., by acquiring locks or using time-outs • In every progressive disjoint-access-parallel STM, each transaction has to protect Ω(k) objects for a write set of size k

  17. Summary Trade-offs between the degree of concurrency and the cost of implementation • Linear RAW/AWAR complexity for permissive STMs • Constant RAW/AWAR complexity for progressive STMs (optimal) • Extends to strong progressiveness • But even a progressive STM requires to protect a linear number of objects (e.g., acquire a linear number of locks)

  18. Future challenges • Exploring the space of progress conditions • Obstruction-freedom, … • Relaxing opacity • View transactions, elastic transactions, virtual world consistency, snapshot isolation, etc. • Refining the notion of protected data More in TR, CoRR, http://arxiv.org/abs/1103.1302, 2011

  19. THANK YOU! QUESTIONS?

  20. What’s wrong with reordering? Process P: ... write(X,1) read(Y) ... Process Q: ... write(Y,1) read(X) ... R(Y) W(X,1) W(X,1) P Q W(Y,1) R(X)

  21. Possible outcomes Out-of-order: both think they run solo P Q P reads before Q writes Q reads after P writes P reads after Q writes Q reads before P writes

  22. Read-after-Write: imposing order in relaxed memory models In almost all modern architectures ... write A read B ... read B write A Read-after write reordering ... write A fence read B ... RAW fence: enforce order

More Related