Authors Eric Koskinen Maurice Herlihy Brown University Presented by – Nagashri Setty

1. Checkpoints and Continuationsinstead ofNested Transactions (SPAA’08) AuthorsEric KoskinenMaurice HerlihyBrown UniversityPresented by – Nagashri Setty

2. Overview • Pros and Cons - Nested transaction • Transactional Boosting • Mechanism for Partially aborting transactions • Examples • Conclusion

3. Partial Aborts • Early TMs aborted entire transactions • Useful to partially abort • Performance: resolve conflict, without unnecessary rollback • Semantic constructs: conditional and orelse synchronization, priority

4. But what about Nesting? • TM literature is a nest of nested transactions • Claim that nesting gives you partial abort • Let’s take a closer look ...

5. Example 1 atomic { Object x = swap(htA, key, y); HashTable.Insert(htB, key, x); } Nesting for Modularity! Object swap(HashTable ht, int key , Object newVal) { atomic { Object r = HashTable Remove(ht,key); HashTable Insert ( ht , key , newVal); return r ; } }

6. Example 2 global int list[10]; atomic { int x = list[0]; list[1] = x + 1; atomic { list[2] = x + 3; } ... } Conflict ? Defend against abort !

7. Two Reasons for Nesting • Code Modularity (sub-routines) • Defend against aborts (emulate partial abort)

8. The Problem • Nesting is too coarse-grained • On abort, return to start of (a nested) txn • To defend, must nest! • Complex implementation : Layers of activation records (read/write sets) • Partial abort by poppIinfg y roeuc ohrdasve a mechanism If you have a mechanism for partial aborts, nesting is unneeded

9. Transactional Boosting (PPoPP’08) • Solve synchronization and recovery without tracking read/write sets and relying on data structure semantics. • Built upon Black box Linearizable base object. • Given Semantics – commutative methods and inverse methods • Relies on commutativity to define and detect conflicts. • Recovery via inverses • Synchronize with abstract locks • Safe alternative to Open Nesting

10. Definitions(Informal) • Two methods X and Y arecommutative, if • Response of X is independent from Y and vice versa • The state of object O after applying X than Y is equal to one after applying Y then X • Method X-1 isinverseof X if object’s state after applying X then X-1 is equal to state before X’s call

11. Simple Example : A Set

12. Outline • Ensure that only commutative methods may be called concurrently during transaction. • If no, to abort the transaction • For every successful method call, to push its inverse into transaction’s local stack • In case of abort, “rewind” inverses stack (in parallel with write set recovery)

13. Abstractlocks • Transactions and objects interact with each other thru an abstract locks • Locks “on object semantic” rather then memory place • Prevents two non-commutative methods to be applied on object during transaction • If can not be acquired (timeout), aborts transaction • The transaction stores all acquired locks. Locks are released by commit or abort

14. Transactional Boosting Concurrent Data Structure

15. Boosting Boosting Log Traditional Log Thread Thread w ◆ ctx0 lock(w) foo-1(w) ◆ ctx1 lock(x) bar-1(x) …. ◆ ctx0 read(list[0]) write(list[1]) ◆ ctx1 write(list[2]) read(list[9]) ... X Y Z

16. The Key Idea Partial Aborts . . . without nested transactions • Simpler syntax: new keyword checkpoint • Definition- A new program location where control may be returned in the event of an abort. • Place a checkpoint anywhere in a transaction (atomic block) • Don’t have to make everything “nested” • Fine-grained rollback • Simpler implementation (no r/w act. records)

17. Syntax • Checkpoints in useful locations • Doesn’t have to be nested Example atomic { ... if ( decision ()) checkpoint; DataStructureOperation(); ... } Example atomic { int x = list[0]; list[1] = x + 1; checkpoint; list[2] = x + 3; ... }

18. Observations • Checkpoints are • simpler • no need to rewrite the block. • nested equivalent would have added layers of depth. • semantically rich locations in the program’s control flow graph. • best suited to operationally meaningful program locations rather than after each write operation.

19. Mechanism To return to a checkpoint, we must: • Capture continuation • Save/restore program counter • Save/restore stack • Save/restore thread-local heap • Mark in the log • Save/restore shared heap • Non local control flow is accomplished with two steps • Continuation storage • Continuation invocation

20. Mechanism Thread A atomic { int x = list[0]; list[1] = x + 1; checkpoint; list[2] = x + 3; int y = list[9]; ... } Example Partial abort full abort ctxi = (pc_A,s_A,h_A)

21. Continuations • Most languages have facilities to capture PC and stack • Prototype implementation built on TL2 which is written is in C • Could also work in Java • getcontext and setcontext – capture the continuation of multiple checkpoints. • setjmp and longjmp for capturing single point in the control flow(stack)

22. Conclusion A • Partially abort a transaction • No nesting needed • Next: Applications.

23. Application: Priority • Preferred threads take priority • How: “high” threads abort “low” threads • May harm low priority throughput • Partially abort low priority threads • Roll back just far enough • Let high priority threads commit

24. Application: Priority Concurrent Data Structure

26. Conditional Sync. List inbound, outbound; AbstractLock inL, outL; Object in = NULL; atomic { with(inL.lock()) { Prepare(inbound); } checkpoint; in = with(inL.lock()) { Dequeue(inbound); } if ( !in.isSpecial() ) retry; with(outL.lock()) { Enqueue(outbound. in); } } retry

27. Conditional Sync. HashTable htA, htB, htC; AbstractLock alA, alB, alC; atomic { Object result = with(alA.lock(key)) { Remove(htA, key);} checkpoint; { with(alB.lock(key)) { Remove(htB, key); } with(alB.lock(key)) { Add(htB, key, result); } } orElse{ with(alC.lock(key)) { Remove(htC, key); } with(alC.lock(key)) { Add(htC, key, result); } } } orElse

28. Implementation(checkpoint and continuation) • Implemented on top of Transactional Boosting implementation in TL2 [9]. • Checkpoints are stored in a runtime computation log. • At each checkpoint, the continuation is captured and appended to the log. • Checkpoints (“Context”) precede operations on shared data structures, which involves acquiring an abstract lock (“Lck”), performing the operation, and then recording the inverse operation (“Inv”) in the log. • When a transaction is aborted, • log is traversed in the reverse direction • As a context is passed it is de-allocated • inverses are invoked to revert data structure operations • and abstract locks are released allowing other threads to acquire them.

29. Runtime Computation log • Diagram of the runtime computation log • captured continuations (“Context”) • abstract locks (“Lck”), • and inverse methods (“Inv”).

30. Experiments • Modified STAMP benchmarks to use Boosting with and without checkpointing. • vacation – A travel reservation system • kmeans – A clustering technique • Ran on 8-way 2.0 GHz Xeon processor

32. Conclusion • Partially abort a transaction • No nesting needed • Applies to read/write TMs • Applies to Transactional boosting

33. Questions????