Software Perspectives on Transactional Memory

1. Software Perspectives on Transactional Memory Ben Liblit CS 838-3

2. Architects Keep PL People Busy • You gave us instruction sets • We made high level languages • You gave us RISC instead • We made optimizing compilers • You gave us context switching • We made a big ugly mess: threads + locks • You may soon give us transactions • Ooh! New toy! What can we make with it?

3. Are Locks Really That Bad? • Yes, locks are really that bad • Entire careers built on making them less awful • But not a problem for most programmers (!) • Most aren’t crazy enough to use threads • Used only in restricted contexts, or by specialized “mad genius” programmers • Need something better • Maybe transactions are that something

4. Transactions and Language Design • Look at two key design questions • Control structures • Non-transactional operations (“magic”) • Assorted issues & tricky bits • Running themes • Compositionality • What happens in hardware/software?

5. atomic { ... atomic { ... } ... } Obvious stuff Start trans on entry Commit trans on exit Nesting? We will nest, whether hardware likes it or not Compositionality! Locks are deeply broken here Control Structure: Atomic Blocks

6. atomic (g) { work(); } Wait until g is true Useful where condition variables might be used What can guard be? Just a memory word? Negated? Arbitrary expression? …with side effects? Conditional Critical Regions

7. atomic (g) { work(); } done = false; while (!done) { begin(); if (g) { work(); done = commit(); } else wait(); } CCRs Using Low-Level Ops

8. done = false; while (!done) { begin(); if (g) { work(); done = commit(); } else wait(); } Abort transaction Back to begin() Spin wait, or… Hardware assist! Track locations read Wait for write to any of them Can you do this? Implementing wait()

9. atomic { ... throw foo; ... } Abort or commit? If abort, what happens to exception object? Consensus: commit Just one more way to exit a block of code Nothing special from programmer’s standpoint, but… Managing Exceptions

10. atomic { ... throw foo; ... } done = false; while (!done) { begin(); try { work(); done = commit(); } catch (t) { done = commit(); if (done) throw t; } } Managing Exceptions Can hardware still help?

11. Can I please have abort() too? void move(Map src, Map dest, int key) { atomic { try { Object val = src.remove(key); dest.insert(key, val); } catch (MapFullException e) { src.insert(key, val); } } } Am I getting too greedy? Does this exceed the transactional mandate?

12. Speculation and Validation atomic { if (x != y) while (1) {} } atomic { ++x; ++y; } • If right commits between left reads … stuck! • Either don’t speculate or add periodic validation • Is your favorite transactional hardware vulnerable? • Can hardware help here, or is this compiler’s job?

13. Speculation and Validation atomic { if (x != y) launchMissiles(); } atomic { ++x; ++y; } • If right commits between left reads … stuck! • Either don’t speculate or add periodic validation • Is your favorite transactional hardware vulnerable? • Can hardware help here, or is this compiler’s job?

14. Control Structures: API Recap void begin(); // basics bool commit(); // basics void wait(); // CCRs void abort(); // greedy? bool validate(); // speculate

15. Non-Transactional Operations • All software has “magic” on the edges • Magical operations outside system definition • Walk off the edge? No coming back! • Operations which cannot be rolled back • Operating system: physical world • User code: system calls • Bytecode: native methods / system calls (?)

16. Not All Magic Is Alike! • Standard examples • Input/output • Memory allocation • Query current time • Thread creation • Can/should these be rolled back? • Can user code help hardware “fake it”?

17. Some Unattractive Options • Forbid magic inside atomic blocks • Non-compositional • Limits transactional memory to tiny tasks • Detect violations at compile time / run time? • Ban speculation for blocks with magic • Compositionality survives • Sacrifice performance • What about our beloved abort() call?

18. Compensation Code • Magic + compensation == transactional • (Well, we pretend it is) • Software, not hardware • Example: buffering • Delicate interaction with hardware roll-back • Language/library designers must • Decide on abstract machine model • Build compensations consistent with model

19. Ben’s Free Prognostication • Will see a mix of strategies • Virtual compensation in virtual machines • Initially, dynamic enforcement • Or no enforcement at all! • Eventual development of static program analyses to prevent dynamic violations

20. Atomic With Respect To… • Other threads in same process? • Other atomic blocks in same process? • But not threads which are outside atomic blocks • Other processes on same machine? • Consider shared memory-mapped pages • Consider shared file system • Connections to security, journaling file systems

21. Granularity of Conflict Detection • Difference between address and “thing” • Which of these can cause roll-backs? • int x, y; • struct { int x, y; } point; • long long int xy; • Shame to expose machine-level details • But precedents exist in C and even Java

22. Garbage Collectors • Read large amounts of memory • Likely to clash with everything else • Cause transaction thrashing? • Concurrent garbage collection • We know how to do this now, but it wasn’t easy! • How will we do it with transactions? • Future employment opportunity for “mad genius” programmers who used to do fine-grained lock coding!

23. Conclusions • Locks are a nightmare; time to wake up • Atomicity may be the right abstraction • Study: 80% of Java methods are atomic • Push years of PL research into the archives • But we’ll thank you for it • Atomicity is nicer for program analysis too! • Compositionality is critical