Beyond Harris and Fraser: Nested Transactions for Java

1. Beyond Harris and Fraser:Nested Transactions for Java Eliot Moss moss@cs.umass.edu University of Massachusetts, Amherst Dagstuhl Atomicity Workshop 3/2006

2. Harris & Fraser OOPSLA 2003 Java atomic block: atomic {S} Sexecuted once; may involve retry Java conditional critical region (CCR): atomic (P) {S} S executed once, but not until P may evaluate P more than once, and retry P and S Dagstuhl Atomicity Workshop 3/2006

3. A Low Level Execution Model Purposes: intuition; implementation notions • Read set = heap locations read • Write set = heap locations written (+ old values) • Conflict: T1 writes overlap T2 reads or writes • Rule: If conflict would occur at next step, abort T1 or T2 • Abort = restore values of written locations; restart from beginning of atomic block • CCR evaluation: if P false, abort Dagstuhl Atomicity Workshop 3/2006

4. Possible Formalization (SOS style, thanks to Cliff Jones …) If  [B]* ’ then  [ atomic{B} ] ’ and If  [P]* (true ’’)  ’’ [B]* ’, then  [ atomic(P){B} ] ’ Dagstuhl Atomicity Workshop 3/2006

5. Closed Nesting Model “Flat” transactions, plus: • Child transactions within any transaction • Definitions revised: • Child never conflicts with ancestors • Otherwise, conflicts if r/w sets overlap • Child sees parent’s state • Child abort: unwind writes, drop r/w sets • Child commit: merge r/w sets with parent Dagstuhl Atomicity Workshop 3/2006

6. How to Formalize? • Question: Does previous approach work? Answer: I think so … • Question: Does it capture everything? Answer: Again, I think so … I solicit help to verify (or fix) this … Dagstuhl Atomicity Workshop 3/2006

7. Open Nesting: Intuition atomic {S} onabort {A} oncommit {C} ondone {D} “Intuitive” meaning: • Execute S atomically; could retry, etc. • Effects are “permanent” on commit of S • If parent commits, run C and later D • If parent aborts, run A and later D • Note: A, C, and D are deferred Dagstuhl Atomicity Workshop 3/2006

8. Open Nesting: “Standard” Use atomic {S} onabort {A} oncommit {C} ondone {D} Clean / justifiable use: • A is an undo/compensating action • S acquires a suitable abstract lock • D releases the lock • C helpful if there is any “clean up” Dagstuhl Atomicity Workshop 3/2006

9. Open Nesting: An Execution Model • When S aborts: as for closed nesting • When S commits, roughly: • Read set dropped (gives more concurrency) • Write set values installed: • To “memory”, i.e., top level (“permanent”), and • To all other r/w sets that mention the location • A added to parent’s abort list • C added to parent’s commit list • D added to parent’s done list Dagstuhl Atomicity Workshop 3/2006

10. Open Nesting: Parent Steps • When parent aborts: unwind writes; perform abort list then done list actions … as open nested actions • When parent commits similarly … Dagstuhl Atomicity Workshop 3/2006

11. Open Nesting: Some Issues • Order of parent steps? • Abort actions in reverse order • Unwind writes in batches (can do w/more nesting levels): r r w [A] w w r [B] r w r X abort! Insures “nice” memory state for each abort (“undo”) action • Environment of action execution? • Full closure: save stack frame(s) … unpleasant • Method (operation) with parameter values … better Dagstuhl Atomicity Workshop 3/2006

12. Open Nesting: Formalizing • Can do low-level “operational” semantics • Be clear about steps and order: define using SOS • Want more insight, esp. in “justified” case • Think that Rely/Guarantee may help atomic {S} onabort{A} oncommit{C} ondone{D} p {S} qL : pre-condition p, post-condition q, lock guarantee L where L preserves L and q qL {A;D} p , that is, A;D undoes S qL {C;D} r, where r is the overall post-condition desired Other threads can know only pqr; this thread knows more Dagstuhl Atomicity Workshop 3/2006

13. Open Nesting: Formalizing … • What about further operations on the same object by the same transaction? • They abort before we abort: S1; S2; S3; A3; A2; A1; D1; D2; D3 • They commit after we commit: S1; S2; S3; C1; C2; C3; D1; D2; D3 • Must be more things I have not (yet) thought of! Dagstuhl Atomicity Workshop 3/2006

14. More broadly: Is this a good idea? • Pros: • Increased concurrency • “Escape hatch” • Programmable model: flexible • Cons: • Implementation effort and complexity: only done once • Can real programmers use it sensibly? • Most code should use only closed nesting! • Most open nesting done by experts, in libraries • Can provide patterns,and libraries for abstract locking Dagstuhl Atomicity Workshop 3/2006

15. Horizons • What can reasonably happen in hardware? • Suitable transactional memory API • Compiler optimizations • Durability • C library / OS: bring into scope with new API? • Dealing with communication • Java: run-time support, exceptions, GC, threads, synchronized, … Dagstuhl Atomicity Workshop 3/2006