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 drastic 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 the 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
Double-ended queue
Enqueue
Dequeue
9
Lock-free computing?

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

10
A concurrency control abstraction that
is Simple to use Efficient to implement
11
Transactions
Cope with both concurrency and recovery control
12
Back to the undergraduate level
Begin

• accessing object 1
• accessing object 2

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

15

• Simple example
• (consistency invariant)

0 lt x lt y
16
Simple example (transaction)

• T x x1 y y1

17
You  atomicity  (AID) Grandma
 consistency  ( C)
Consistency Contract
C
A-I-D
18
The underlying theory (P79)
A history is atomic if its restriction to
committed transactions is serializable
19
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
20
This is all fine
But this is not new
Why should we care?
Because we want jobs
21
Transactions are indeed back But are they
really the same?
How can we figure that out?
22
Ask system people
System people know
 Those who know dont need to think  Iggy Pop
23
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 hasnt changed
  since Ts last reads else T is aborted

24
Simple algorithm (DSTM)

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

25
More efficient algorithmApologizing versus
asking permission

• Killer write
• Optimistic read validity check at commit time

26
Am I smarter than a system guy?
No way
27

• Back to the example

Invariant 0 lt x lt y Initially x
1 y 2
28
Division by zero

• T1 x x1 y y1

• T2 z 1 / (y - x)

29
Infinite loop

• T1 x 3 y 6

• T2 a y b x
• repeat b b 1 until a b

30
System people care about live transactions
Theoreticians didnt
31
The old theory A history is
atomic if its restriction to committed
transactions is serializable
We need a theory that talks about ALL
transactions
32
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)
33
A new theory is nice but is it useful?
Check with system people
34
Simple algorithm (DSTM)

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

35
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

36
Conjecture Either the read has to be
visible or has to be careful
Wrong
37
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

38
Theorem (GK06) Visible read
Vs Validation Vs (solo) Progress
39
The theorem does not hold for classical atomicity
i.e., the theorem does not hold for database
transactions
40
More theorems (GK07)
Solo progress cannot be ensured with disjoint
access parallelism Solo progress cannot be
ensured with transparent reads
41
Many more issues

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

42
Progress
With solo progress, some transactions might never
commit
Can we ensure that all transactions eventually
commit?
43
Theorem (GKK06) Solo progress and
eventual global progress are incompatible
When exactly can we ensure eventual global
progress (resp. solo progress)?
44
Progress/Real-Time

• 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

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 (GHP05)

• 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 more issues

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

50
Performance

• How to evaluate transactional memory
  implementations?
• So far, mainly micro-benchmarks (linked lists,
  red-black trees)

51
Benchmarks

• STMBench7 (GKV06)

• Dividing STMs by zero

52
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, PPoPP, Transact
• What about SRDS?

53
Transactions are conquering the parallel
programming world
The one slide to remember
They look simple and familiar and thus make the
programmer happy
Their implementation is in fact very tricky and
that should make YOU happy
54
(No Transcript)
55
(No Transcript)
56
(No Transcript)
57
(No Transcript)
58
Real-time

• T1 y x commit
• T2 x x1 commit
• T3 y y1 commit

59
Real-time
T2 (read-write(x))
T1 (read(x))
X
T1 (write(y))
Y
T2 (read-write(y))
commit
commit
60
Recoverability is not enough
T1 (read(x))
T2 (read-write(x))
T1 (write(y))
T2 (read-write(y))
commit
commit
61
Classical database transactions
User 1
User 2
Transaction Server
Database (disk)
62
In-memory transactions
User 1
User 2
Transaction server database
Fast processor
63
Shared memory transactions
Thread 4
Thread 3
Thread 2
Thread 1
Transactional language shared memory
Processor 3
Processor 2
Processor 1