Transactions are back But are they the same? R. Guerraoui, EPFL

Transactions are backBut are they the same?

R. Guerraoui , EPFL

- Le retour de Martin Guerre -

(Sommersby)

From the New York TimesSan Francisco, May 7, 2004Intel announces a drastic change in its business strategy:« Multicore is THE way to boost performance »

The free ride is over

Every one will need to fork threads

Forking threads is easy

Handling the conflicts is hard

Coarse grained locks => slow

Fine grained locks => errors(Most Java bugs are due to misuse of he word « synchronized »)

Double-ended queue

Enqueue Dequeue

Lock-free computing?

Every lock-free data structure # podc/disc/spaa papers

A concurrency control abstraction that is:

Simple to use Efficient to implement

TransactionsCope with both concurrency and recovery control

accessing object 1; accessing object 2;

Back to the undergraduate level

Begin {

end }

TransactionsConsistency Contract (ACID)

CA-I-D

Historical perspective

Eswaran et al (CACM’76) Database Papadimitriou (JACM’79) Theory Liskov/Sheifler (TOPLAS’82) Language Knight (ICFP’86) Architecture Herlihy/Moss (ISCA’93) Hardware Shavit/Touitou (PODC’95) Software

Simple example (consistency invariant) 0 < x < y

T: x := x+1 ; y:= y+1

Simple example (transaction)

You: « atomicity » (AID) Grand’ma: « consistency » ( C)

Consistency Contract

CA-I-D

A history is atomic if itsrestriction to committed transactions is serializable

The underlying theory (P’79)

A history H of committed transactions is serializable if there is a history S(H) that is (1) equivalent to H(2) sequential (3) legal

This is all fine

But this is not new Why should we care?

Because we want jobs

Transactions are indeed back

But are they really the same? How can we figure that out?

Ask system people

System people know

« Those who know don’t need to think » Iggy Pop

Simple algorithm (DSTM)

To write an object O, a transaction acquires O and aborts “the” transaction that owns O

To read an object, a transaction T takes a snapshot to see if the system hasn’t changed since T’s last reads; else T is aborted

Simple algorithm (DSTM)

Killer write (ownership)

Careful read (validation)

More efficient algorithm

Apologizing versus asking permission

Killer writeOptimistic read: validity check at commit time

Am I smarter than a system guy?

No way

Back to the example

Invariant: 0 < x < yInitially: x := 1; y := 2

Division by zero

T1: x := x+1 ; y:= y+1

T2: z := 1 / (y - x)

T1: x := 3; y:= 6

Infinite loop

T2: a := y; b:= x; repeat b:= b + 1 until a = b

System people care about live transactions

Theoreticians didn’t

We need a theory that talks about ALL transactions

The old theoryA history is atomic if its restriction to committed transactions is serializable

A history H is opaque if for every transaction T in H, there is a serializable history in committed(T,H)

A new theory: Opacity (KG’06)

A new theory is nice but is it useful?

Check with system people

Simple algorithm (DSTM)

Careful read (validation)

Killer write (ownership)

Visible vs Invisible Read

(SXM; RSTM)

Write is mega killer: to write an object, a transaction aborts any live one which has read or written the object

Visible but not so careful read: when a transaction reads an object, it says so

ConjectureEither the read has to be visible or has to be careful

Wrong

Giving up Progress (TL2)

To write an object, a transaction acquires it and writes its timestamp

To read an object, the transaction aborts itself if the object was written by a transaction with a higher timestamp

Theorem (GK’06)

Visible read Vs Validation Vs (solo) Progress

The theorem does not hold for classical atomicity

i.e., the theorem does not hold for database transactions

Solo progress cannot be ensured with disjoint access parallelism

Solo progress cannot be ensured with transparent reads

More theorems (GK’07)

Many more issues

Progress? Real-time?Performance? Hardware support? Linguistic support?

With solo progress, some transactions might never commit

Can we ensure that all transactions eventually commit?

Progress

Theorem (GKK06): Solo progress and eventual global progress are incompatible

When exactly can we ensure eventual global progress (resp. solo progress)?

If a transaction T wants to write an object O owned by another transaction, it calls a contention manager

Various contention management strategies are possible

Progress/Real-Time

System Perspective

Scherer and Scott [CSJP 04] Exponential backoff“Karma”

Transaction with most work accomplished wins

Various priority inheritance schemes …

Some work well, but …Can’t prove anything!

Greedy Contention Manager (GHP’05)

StatePriority (based on start time)Waiting flag (set while waiting)

Wait if other hasHigher priority AND not waiting

Abort other iflower priority OR waiting

Preliminary Result

Compare time to complete transaction schedule forIdeal off-line scheduler

Knows transactions, conflicts, and start times in advance

Greedy contention managerDoes not know anything …

Competitive Ratio

Let s be the number of objects accessed by all transactionsCompare time to commit all transactionsGreedy is O(s)-competitive with the off-line adversaryGHP’05 O(s2)AEST’06 O(s)

Many more issues

Progress? Real-time?Performance? Hardware support? Linguistic support?

Performance

How to evaluate transactional memory implementations?

So far, mainly micro-benchmarks (linked lists, red-black trees)

Benchmarks

STMBench7 (GKV’06)

Dividing STMs by zero

http://www.cs.wisc.edu/trans-memory/biblio/index.html

Sun, Intel, IBM, EU (VELOX)ISCA, OOPSLA, PODC, DISC, POPL, PPoPP, Transact

What about SRDS?

The Topic is VERY HOT

Transactions are conquering the parallel programming world

They look simple and familiar and thus make the

programmer happyTheir implementation is in fact

very tricky and that should make YOU happy

The one slide to remember

Real-timeT1: y := x; commit

T2: x := x+1; commit

T3: y := y+1; commit

Real-time

X

Y

commit

T1 (read(x))

T1 (write(y))

T2 (read-write(x))

commit

T2 (read-write(y))

Recoverability is not enough

commit

T1 (read(x))

T1 (write(y))

T2 (read-write(x))

commit

T2 (read-write(y))

User 1 User 2

Transaction Server

Classical database transactions

Database (disk)

User 1 User 2

Transaction server + database

In-memory transactions

Fast processor

Thread 4Thread 3Thread 2

Processor 3Processor 2Processor 1

Transactional language: shared memory

Thread 1

Shared memory transactions