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

2. - Le retour de Martin Guerre - (Sommersby)

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

5. The free ride is over
Every one will need to fork threads

6. Forking threads is easy
Handling their conflicts is hard

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

8. Lock-free computing?
Every lock-free data structure
# podc/disc/spaa papers

9. How can we simply state that a certain code needs to appear atomic without using a big lock?

10. Consistency Contract (ACID)
Transactions
Consistency Contract (ACID) C
A-I-D

11. 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

12. Simple example
(consistency invariant)
0 < x < y

13. Simple example
(transaction)
T: x := x+1 ; y:= y+1

14. Consistency Contract You: « atomicity » (AID)
Grand’ma: « consistency » ( C)
Consistency Contract C
A-I-D

15. The underlying theory (P’79)
A history H is atomic if
the restriction of H to its committed transactions is serializable

16. 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

17. This is all fine
But this is not new
Why should we care?
Because we want jobs

18. Transactions are indeed back
But are they really the same?
How can we figure that out?

19. Ask system people System people know
« Those who know don’t need to think » Iggy Pop

20. Simple algorithm (DSTM)
To write an object O, a transaction acquires O and aborts the transaction that owned O before
To read an object, a transaction T takes a snapshot to see if the system has changed since T’s last reads; else T is aborted

21. Simple algorithm (DSTM)
Killer write (ownership)
Careful read (validation)

22. More efficient algorithm Apologizing versus asking permission
Killer write
Optimistic read
Validity check at commit time

23. Am I smarter than a system guy?
No way

24. Back to the simple example
Invariant: 0 < x < y
Initially: x := 1; y := 2

25. Division by zero
T1: x := x+1 ; y:= y+1
T2: z := 1 / (y - x)

26. Infinite loop T3: a := y; b:= x; repeat b:= b + 1 until a = b
T1: x := 3; y:= 6
T3: a := y; b:= x;
repeat b:= b + 1 until a = b

27. System people care about live transactions
The theoreticians didn’t

28. The old theory We need a theory that talks about ALL transactions
A history is atomic if its restriction to committed transactions is serializable
We need a theory that talks about ALL transactions

29. A new theory: Opacity (KG’06)
A history H is opaque if for every transaction T in H, there is a serializable history in committed(T,H)

30. So what?
Ask system people

31. Simple algorithm (DSTM)
Careful read (validation)
Killer write (ownership)

32. Visible vs Invisible Read (SXM; RSTM)
Visible but not so careful read: when a transaction reads an object, it says so
Write is mega killer: to write an object, a transaction aborts any live one which has read or written the object

33. Conjecture
Either the read has to be visible or has to careful
Wrong

34. Giving up Progress (TL2)
To write an object, a transaction acquires it and writes its timestamp
To read an object O, the transaction aborts itself if O was written by a transaction with a higher timestamp

35. Conjecture
Visible read Vs
Validation
Progress

36. Theorem (GK06):
progress with invisible reads
requires Omega(k) steps

37. Theorem
Visible read Vs
Validation
Progress

38. The theorem does not hold
for classical atomicity
i.e., the theorem does not hold
for database transactions

39. More … Theorem (GK07): progress cannot be ensured with
disjoint access parallelism

40. Transparent read? (DSTM)
To read an object, a transaction T takes a snapshot to see if the system is still in the same state; else T is aborted (or wait)

41. Yet another theorem
Theorem (GK07):
progress cannot be ensured
with transparent reads

42. So far, progress applied to solo transactions (i.e. solo progress)
Some might never commit
Can we ensure that all
transactions eventually commit?

43. Yet another theorem:
Theorem (GKK06):
Solo progress and eventual
progress are incompatible

44. Contention management
If a transaction T wants to write an object O owned by another transaction, call a contention manager (various strategies)

45. System Perspective Scherer and Scott [CSJP 04] Some work well, but …
Exponential backoff
“Karma”
Transaction with most work accomplished wins
Various priority inheritance schemes …
Some work well, but …
Can’t prove anything!

46. Greedy Contention Manager
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

47. 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 …

48. 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(s2)
AEST’06 O(s)

49. Many many open problems
What programming language? LS’83, GCLR’93, KG’03,…
What hardware support? K’86, HM’93,..
What software implementation? ST’95, HMLS’03, RFF’06,..
What benchmark? KGV’06,..
What theory? …
What algorithms? …

50. The Topic is VERY HOT
Sun, Intel, IBM, EU (VELOX)
ISCA, OOPSLA, PODC, DISC, POPL, Transact
What about SPAA and Euro-Par?

51. Transactions are conquering the parallel programming world
The one slide to remember
Transactions are conquering the parallel programming world
They look simple and familiar and thus make the programmer happy
They are in fact very sophisticated and thus should make YOU happy

56. Classical database transactions
User 1
User 2
Transaction Server
Database (disk)

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

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