Formalisms and Verification for Transactional Memories

1
Formalisms and Verification forTransactional
Memories

• Vasu Singh
• EPFL Switzerland

2

• Part 1
• Verification for Pure Transactional Programs
• Part 2
• Formalisms for Mixed Transactional Programs
• (Parametrized Opacity)

3
Pure Transactional Programs

• All operations within transactions
• No non-transactional operations

4
Interaction
Hardware
Pure Transactional Program
Transactional Memory Algorithm
Memory operations may be reordered by the
hardware
5
Relaxed memory models

• For reasons of performance, hardware may
  transform the sequence of instructions of a
  thread
• One uses fences to ensure order with relaxed
  memory models fences have a high performance
  overhead

6
Verification Problem

• Does a given TM algorithm guarantee atomicity
  for every transactional program under a given
  memory model?

7
How do we verify?

• Formalize common memory models
• Capture the behavior of STM algorithms under
  relaxed memory models
• Build a specification (of say, opacity) at
  hardware level atomicity
• Implement a tool to check the correctness of an
  STM algorithm using the spec

8
Relaxed Memory Language

• A new language to write concurrent programs under
  relaxed memory models
• Syntax Statements execute atomically in hardware
• Semantics Parametrized by the memory model M
• We express TM algorithms in RML

9
Homework slide on RM 101
How many possible valuations for r1, r2, r3,
r4? On SC ? On TSO ?
On PSO ? On RMO ?
A 1 B 1 r1 D r3 C A 2
C 1 D 1 r2 B r4 A C 2
10
Homework slide on RM 101
How many possible valuations for r1, r2, r3,
r4? On SC ? 7 On TSO ? 1
more On PSO ? 7 more On RMO ?
1 more
A 1 B 1 r1 D r3 C A 2
C 1 D 1 r2 B r4 A C 2
Manually a few minutes, at least ! RML less
than a second on a dual core 2.8 GHz
11
Our Tool
FOIL
12
Our Tool
A is correct under M
RML description of an STM algorithm A
FOIL
A is correct under M with fences at
Memory Model M
A is not correct under SC
13
Our Tool
RML description of an STM algorithm A
Memory Model M
14
Our Tool
RML description of an STM algorithm A
L(A,M)
Memory Model M
15
Our Tool
Spec
RML description of an STM algorithm A
L(A,M) subset of Spec?
L(A,M)
Memory Model M
16
Our Tool
Spec
A is correct under M
RML description of an STM algorithm A
YES
L(A,M) subset of Spec?
L(A,M)
Memory Model M
17
Our Tool
Spec
A is correct under M
RML description of an STM algorithm A
YES
L(A,M) subset of Spec?
L(A,M)
NO
Memory Model M
L(A,SC) subset of Spec?
18
Our Tool
Spec
A is correct under M
RML description of an STM algorithm A
YES
L(A,M) subset of Spec?
L(A,M)
NO
Memory Model M
L(A,SC) subset of Spec?
A is not correct under SC
NO
19
Our Tool
Spec
A is correct under M
RML description of an STM algorithm A
YES
L(A,M) subset of Spec?
L(A,M)
NO
YES
Add fence to A
Memory Model M
L(A,SC) subset of Spec?
A is not correct under SC
NO
20
Our Tool
Spec
A is correct under M
RML description of an STM algorithm A
YES
L(A,M) subset of Spec?
L(A,M)
NO
YES
Add fence to A
Memory Model M
L(A,SC) subset of Spec?
A is not correct under SC
NO
21
Our Tool
Spec
A is correct under M
RML description of an STM algorithm A
YES
L(A,M) subset of Spec?
L(A,M)
A is correct under M with fences at
YES
NO
NO
YES
Add fence to A
Memory Model M
L(A,SC) subset of Spec?
A is not correct under SC
NO
22
Our experiments

• Wrote DSTM, TL2, and McRT STM in RML without
  fences
• Found the STM algorithms correct under SC and TSO
• FOIL places required fences for correctness under
  further relaxed PSO and RMO
• The set of inserted fences matches those in the
  official implementation for TL2

23
Mixed Transactional Programs
24
Mixed Transactional Programs

• No formal framework
• We try to define one

25
Mixed Transactional Programs
r1 x
atomic x 1 x 2
Hardware
Transactional Memory Algorithm
Mixed Transactional Program
Non transactional interaction
26
A strong correctness property

• Strong atomicity / Strong isolation
• Transactions are isolated from other transactions
  and non-transactional operations

27
A Common Quote

• Strong atomicity is expensive to achieve
• Questions
• What is strong atomicity precisely ?
• How expensive ?

28
Specifying correctness
29
Strong Atomicity

• Precise part
• Transactions isolated from other transactions,
  and also from non-transactional operations
• Ambiguous part
• What is the interaction between non-transactional
  operations?
• Two definitions
• every non-transactional operation executes as a
  transaction (Larus et al.)
• Non-transactional operations execute according to
  a relaxed memory model (Martin et al.)

30
Precise part 1
r1 0
atomic x 1 x 2
r1 x
r1 2
Two possibilities for r1. Allowed by both Larus
and Martin ?
31
Precise part 2
Only possibility by both Larus and Martin r1 1
?
atomic x 1 r1 x
x 2
32
Ambiguous part 1
atomic x 1 y 1
r1 y r2 x
33
Ambiguous part 1
Allowed only by Martin ?
r1 0 r2 0
r2 0 r1 1
r1 0 r2 1
atomic x 1 y 1
r1 y r2 x
r1 1 r2 1
Allowed by both Larus and Martin ?
34
Ambiguous part 2
Can r1 be 42 ? Depends on the memory model ! If
the memory model allows out of thin air values,
r1 can be 42.
atomic x 1
r1 x
x 2
35
Parametrized Opacity
36
Motivation

• Separate the concerns
• Memory model contract for non-tx
• Strong atomicity for tx

37
Intuition

• Opacity for transactions
• Isolation of transactions from non-transactional
  operations
• Non-transactional operations respect the memory
  model

38
How Expensive Complexity Analysis
39
Basically

• We want to know what is so expensive about strong
  atomicity
• Does it require non-transactional operations to
  perform a long sequence of operations ?
• Does it require non-transactional operations to
  wait indefinitely for transactions to finish ?
• Is it impossible to achieve?

40
TM Implementations

• Provides (possibly different) semantics for
  transactional and non-transactional operations
• Example. On tx-write(x,v)
• acquire lock for x, store ltx,vgt, add x to
  writeset
• Maps a history h on operations to a trace on
  low-level hardware instructions

41
Uninstrumented TM

• Let us study these first
• No overhead of non-tx operations
• What can we achieve
• Under what conditions?

42
Classes of memory models

• Four classes based on restriction of reorderings
  -gt
• RR does not allow to reorder two read
  instructions to different variables
• RW does not allow to reorder a read followed by
  a write to a different variable
• WR does not allow to reorder a write followed
  by a read to a different variable
• WW

43
Examples

• SC RR, RW, WR, WW
• PSO RR, RW
• RMO RR_d, RW_d
• Java RW_d, RR_d
• Alpha RW_d

44
NULL memory model

• Every pair of operations can be reordered
• NULL not in RR, RW, WR, WW
• Even the most relaxed memory models enforce an
  order between a load and a dependent store
• NULL memory model is not practical

45
Results

• Parametrized opacity can be obtained with
  uninstrumented TMs only under NULL memory model
• For every non-NULL memory model, it is impossible
  to achieve parametrized opacity without
  instrumentation

46
Proof idea

• Assume the memory model restricts the order of
  two instructions
• Create a counterexample history that is not
  opaque parametrized by this memory model
• Do this for every possible restriction (RR, RW,
  WR, WW)

47

• We also show how to achieve opacity parametrized
  by the NULL memory model without instrumentation

48
What about some instrumentation?
49
Instrumented TM

• Change the semantics of non-transactional
  operations
• Reads are no longer just loads and writes are no
  longer just stores
• Used to make non-tx operations tx aware
• Example
• Non-transactional writes are required to hold the
  lock that is used by transactional writes before
  performing a write

50
Example of instrumented TM Shpeisman et al.,
PLDI 07

• Every object accessed in a transaction has a tx
  record
• A tx record is in one of the states shared,
  exclusive, private, exclusive anonymous
• Tx operations as in common TMs
• Non-tx read check no tx write interferes
• Non-tx write get exclusive access to the tx
  record

51
Example of instrumented TM Shpeisman et al.,
PLDI 07

• Every object accessed in a transaction has a tx
  record
• A tx record is in one of the states shared,
  exclusive, private, exclusive anonymous
• Tx operations as in common TMs
• Non-tx read check no tx write interferes
• Non-tx write get exclusive access to the tx
  record

Expensive !
52
Instrumented TMs

• The instrumented guarantees parametrized opacity
  wrt SC !
• You saw it was expensive a non-tx read or
  write may indefinitely wait for a tx to complete

53
Can we do better?
54
In other words

• Can we provide parametrized opacity for some
  memory models with constant-time instrumentation
  for non-tx accesses ?
• Or even better, can we do just with constant-time
  instrumentation for non-tx writes (uninstrumented
  reads) ?

55
Instrumented TMs

• Let M be a memory model which relaxes read/write
  to read order (e.g. RMO, Java, and Alpha)
• Theorem It is possible to obtain opacity
  parametrized by M with constant time
  instrumentation for writes and no instrumentation
  for reads.

56
Intuition of the construction

• Transactions
• Use a global lock from start and finish
• Use CAS to store the updates to memory on commit
• Non-transactional reads Just a load
• Non-transactional writes
• Maintain a per-process version number (vp)
• Increment vp before every write
• Store the ltvp,valuegt in the variable (this
  ensures that the CAS in the transactions do not
  have the ABA problem)

57
What this tells us?

• Existing TM implementations for strong atomicity
  promise too much they even guarantee ordering
  of non-transactional accesses
• This too much is the reason for poor performance

58
Putting Tims talk in perspective

• Worry about programming language constructs we
  care about relaxed memory models
• Define intuitive correctness properties for
  programmers we formalize strong atomicity
• - Need to define semantics/properties at the
  level of TM implementations to know what can be
  implemented efficiently and what cannot be

59
An Analogy

• Java memory model is weak programmers use
  synchronization to ensure sequentially consistent
  behavior (DRF property)
• Similarly, let opacity parametrized by Java be a
  weak notion. Let explicit synchronization
  guarantee opacity parametrized by SC

60
Putting Tims talk in perspective

• - Let TM implementations not promise everything
  needed for the programmer
• we let a TM implementation guarantee opacity
  with respect to weaker memory models, and let
  program-level synchronization take care of the
  rest
• - we keep the guarantee of transactions strong
  (opacity)

61
Conclusion

• TM implementations should not enforce order of
  non-transactional operations
• Non-transactional operations should still satisfy
  just the contract of the memory model
• We can hope to use these relaxations to make TM
  implementations with strong isolation guarantees
  faster

62
Papers

• Part 1
• STM on Relaxed Memory Models
• with Guerraoui, Henzinger
• Part 2
• Transactions in the Jungle
• with Guerraoui, Henzinger, Kapalka
• Questions ?