authors eric koskinen maurice herlihy brown university presented by – nagashri setty
DESCRIPTION
Checkpoints and Continuations instead of Nested Transactions (SPAA’08). Authors Eric Koskinen Maurice Herlihy Brown University Presented by – Nagashri Setty. Overview. Pros and Cons - Nested transaction Transactional Boosting Mechanism for Partially aborting transactions Examples - PowerPoint PPT PresentationTRANSCRIPT
Authors
Eric KoskinenMaurice HerlihyBrown University
Presented by – Nagashri Setty
Checkpoints and Continuationsinstead ofNested Transactions (SPAA’08)
Overview
Pros and Cons - Nested transaction Transactional Boosting Mechanism for Partially aborting
transactions Examples Conclusion
Partial Aborts
Early TMs aborted entire transactions Useful to partially abort
Performance: resolve conflict, without unnecessary rollback
Semantic constructs: conditional and orelse synchronization, priority
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 ...
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!
Example 2
global int list[10];atomic {
int x = list[0];list[1] = x + 1;atomic {
list[2] = x + 3;}
...}
Conflict ?
Defend against abort !
Two Reasons for Nesting
Code Modularity (sub-routines) Defend against aborts (emulate partial
abort)
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
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
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)
Simple Example : A Set
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)
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
Transactional Boosting
Concurrent Data Structure
BoostingTraditional Log
◆ ctx0read(list[0])write(list[1])
◆ ctx1write(list[2])read(list[9])...
Thread
Boosting Log
◆ ctx0lock(w)foo-1(w)
◆ ctx1lock(x)bar-1(x)….
Threadw
Y
Z
X
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)
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; ...}
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.
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
Mechanism
atomic {int x = list[0];list[1] = x + 1;checkpoint;list[2] = x + 3;int y = list[9];...
}
Example
ctxi = (pc_A,s_A,h_A)
Thread A
Partial abort full
abort
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)
Conclusion A
Partially abort a transaction No nesting needed
Next: Applications.
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
Application: Priority
Concurrent Data Structure
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
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
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.
Runtime Computation log
Diagram of the runtime computation log captured continuations (“Context”) abstract locks (“Lck”), and inverse methods (“Inv”).
Context Lck(56) Inv(…) Context Lck(56) Inv(…) Context Lck(56)
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
Conclusion
Partially abort a transaction No nesting needed Applies to read/write TMs Applies to Transactional boosting
Questions????