Presentation is loading. Please wait.

Presentation is loading. Please wait.

Authors Eric Koskinen Maurice Herlihy Brown University Presented by – Nagashri Setty Checkpoints and Continuations instead of Nested Transactions (SPAA’08)

Similar presentations


Presentation on theme: "Authors Eric Koskinen Maurice Herlihy Brown University Presented by – Nagashri Setty Checkpoints and Continuations instead of Nested Transactions (SPAA’08)"— Presentation transcript:

1 Authors Eric Koskinen Maurice Herlihy Brown University Presented by – Nagashri Setty Checkpoints and Continuations instead of Nested Transactions (SPAA’08)

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 Object swap(HashTable ht, int key, Object newVal) { atomic { Object r = HashTable Remove(ht,key); HashTable Insert ( ht, key, newVal); return r ; } atomic { Object x = swap(htA, key, y); HashTable.Insert(htB, key, x); } Nesting for Modularity!

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  Two methods X and Y are commutative, 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 is inverse of X if object’s state after applying X then X -1 is equal to state before X’s call Definitions (Informal)

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  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 Abstract locks

14 Transactional Boosting Concurrent Data Structure

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

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 atomic { int x = list[0]; list[1] = x + 1; checkpoint; list[2] = x + 3; int y = list[9];... } Example ctx i = ( pc _ A, s _ A, h _ A ) Thread A Partial abort full abort

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

25

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”). ContextLck(56)Inv(…)ContextLck(56)Inv(…)ContextLck(56)

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

31

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

33 Questions????


Download ppt "Authors Eric Koskinen Maurice Herlihy Brown University Presented by – Nagashri Setty Checkpoints and Continuations instead of Nested Transactions (SPAA’08)"

Similar presentations


Ads by Google