Transactions are back But are they the same R' Guerraoui , EPFL

1
Transactions are backBut are they the
same?R. Guerraoui , EPFL
2
- Le retour de Martin Guerre - (Sommersby)
3
(No Transcript)
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 gt slow Fine grained locks
gt 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
Transactions
Consistency Contract (ACID)
C
A-I-D
11
Historical perspective

• Eswaran et al (CACM76) Database
• Papadimitriou (JACM79) Theory
• Liskov/Sheifler (TOPLAS82) Language
• Knight (ICFP86) Architecture
• Herlihy/Moss (ISCA93) Hardware
• Shavit/Touitou (PODC95) Software

12

• Simple example
• (consistency invariant)

0 lt x lt y
13
Simple example (transaction)

• T x x1 y y1

14
You  atomicity  (AID) Grandma
 consistency  ( C)
Consistency Contract
C
A-I-D
15
The underlying theory (P79)
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 dont 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
  Ts last reads else T is aborted

21
Simple algorithm (DSTM)

• Killer write (ownership)
• Careful read (validation)

22
More efficient algorithmApologizing 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 lt x lt y Initially x
1 y 2
25
Division by zero

• T1 x x1 y y1

• T2 z 1 / (y - x)

26
Infinite loop

• 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 didnt
28
The old theory 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 (KG06)
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
Vs Progress
36
Theorem (GK06) progress with invisible
reads requires Omega(k) steps
37
Theorem Visible read Vs Validation
Vs 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
• Exponential backoff
• Karma
• Transaction with most work accomplished wins
• Various priority inheritance schemes
• Some work well, but
• Cant 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
• GHP05 O(s2)
• AEST06 O(s)

49
Many many open problems

• What programming language? LS83, GCLR93,
  KG03,
• What hardware support? K86, HM93,..
• What software implementation? ST95, HMLS03,
  RFF06,..
• What benchmark? KGV06,..
• What theory?
• What algorithms?

50
The Topic is VERY HOT

• http//www.cs.wisc.edu/trans-memory/biblio/index.h
  tml
• 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
They look simple and familiar and thus make the
programmer happy
They are in fact very sophisticated and thus
should make YOU happy
52
(No Transcript)
53
(No Transcript)
54
(No Transcript)
55
(No Transcript)
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 4
Thread 3
Thread 2
Thread 1
Transactional language shared memory
Processor 3
Processor 2
Processor 1