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
Top Related