authors eric koskinen maurice herlihy brown university presented by – nagashri setty

Post on 14-Jan-2016

22 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

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 Presentation

TRANSCRIPT

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????

top related