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

- Le retour de Martin Guerre - (Sommersby)

From the New York Times San Francisco, May 7, 2004 Intel 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

Transactions Cope with both concurrency and recovery control

accessing object 1; accessing object 2; Back to the undergraduate level Begin { end }

Transactions Consistency Contract (ACID) C A-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 C A-I-D

A history is atomic if its restriction 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 write Optimistic read: validity check at commit time

Am I smarter than a system guy? No way

Back to the example Invariant: 0 < x < y Initially: 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 theory A 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

Conjecture Either 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) State Priority (based on start time) Waiting flag (set while waiting) Wait if other has Higher priority AND not waiting Abort other if lower priority OR waiting

Preliminary Result Compare time to complete transaction schedule for Ideal off-line scheduler Knows transactions, conflicts, and start times in advance Greedy contention manager Does not know anything …

Competitive Ratio Let s be the number of objects accessed by all transactions Compare time to commit all transactions Greedy is O(s)-competitive with the off-line adversary GHP’05 O(s 2 ) 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

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 happy Their implementation is in fact very tricky and that should make YOU happy The one slide to remember

Real-time T1: 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 1User 2 Transaction Server Classical database transactions Database (disk)

User 1User 2 Transaction server + database In-memory transactions Fast processor

Thread 4Thread 3 Thread 2 Processor 3Processor 2Processor 1 Transactional language: shared memory Thread 1 Shared memory transactions