Post on 18-Jan-2018
description
Alpine Verification Meeting 2008
Model Checking Transactional Memories
Vasu Singh (Joint work with Rachid Guerraoui,
Tom Henzinger, Barbara Jobstmann)EPFL Switzerland
Appears in PLDI 2008
1
Alpine Verification Meeting 2008
Writing Parallel Programs Locks ? Coarse-grained locks – Scalability, performance? Fine-grained locks – Prone to concurrency bugs. Vulnerability – thread-failures, delays, deadlocks. Non-blocking wait-free objects ? Atomic Read-Modify-Write operations – CAS Too difficult to use: Implementing atomic queues
using CAS is a publishable result! Not scalable or composableCorrect efficient concurrent programs:
Difficult !2
Alpine Verification Meeting 2008
Transactional Memory [Herlihy93] Inspired by transactions in database concurrency What is a transaction ? A finite sequence of memory reads and writes executed
by a single thread, “atomically”. Run transactions in parallel, do all the book-
keeping to ensure safety Benefits to the programmer- Ease of writing correct parallel programs- Good parallel performance- No deadlocks- Fault tolerance
BeginTx
Read X
Read Y
…
Write Z
Write X
CommitTx
3
Alpine Verification Meeting 2008
TL2 : An example STMAlgorithm idea: Every thread maintains its read and
write set Global clock: records the version
numbers Conflict detection with the version
numbers Locks: with the guarantee of no
deadlocks!
4
Alpine Verification Meeting 2008
Example with TL2Thread 1: begin tx (0)lx := txRead X (2) ly := lx + 1 (2)txWrite(Y, ly) (4)Commit (6)
Thread 2: begin tx (1)ly := txRead Y (3)lx := ly + 1 (3)txWrite(X, lx) (5)Commit (7)
rver = 15 (0) rs = {X} (2)ws = {Y} (4)lock {Y} (6)wver = 16 (6)Validate {X} (6Commit Y withversion 16 (6)
rver = 15 (1) rs = {Y} (3)ws = {X} (5)lock {X} (7)wver = 17 (7)Validate {Y} (7)Transaction aborts
Global version = 15
Global version = 17
On a read: add the variable to the read set
On a write: add the variable to the write set
On a commit: lock write set, inc global counter, validate read set : if successful then commit else abort
5
When is a TM correct ? Flexibility to the programmer translates
to strict requirements on the implementation
A TM is correct for a property if it always guarantees that property for any number of threads and variables
A lot of work on TM, but relatively little on formalizing TM and verifying their correctness
6Alpine Verification Meeting 2008
Our work Formalism for correctness in TM Model checking TM for safety
Modeling TM with n threads and k variables Reducing infinite state problem to finite
state Automatically proving safety Generalizing result to arbitrary n and k
Model checking TM for liveness
7Alpine Verification Meeting 2008
Alpine Verification Meeting 2008
FORMALISM FOR TM
8
Transactions and Conflicts Statements: reads, writes, commit, abort Transaction: Reads and writes of variables
followed by commit (committing transaction) or abort (aborting transaction)
Word: An interleaved sequence of transactions of different threads
Conflict: Two statements conflict if One is a read of variable X and other is a commit
of a transaction that writes to X Both are commits of transactions that write to X
9Alpine Verification Meeting 2008
Safety property: Strict serializability There is a serialization for the
committing transactions such that order of conflicts is preserved
Order of non-overlapping transactions remains the same
Note: preserving order of conflicts allows us to completely ignore values of variables
10Alpine Verification Meeting 2008
Safety property: Strict serializability
There is a serialization for the committing transactions such that order of conflicts is preserved
Order of non-overlapping transactions remains the same.
Example word: (rd X t1), (rd Y t2), (wr X t2), (commit t2), (commit t1) =>
Can be serialized to :(rd X t1), (commit t1), (rd Y t2), (wr X t2), (commit t2).
conflict
11Alpine Verification Meeting 2008
Safety property: Opacity Strict serializability + There exists a serialization for all
transactions: also aborting & unfinished transactions More relevant in TM: avoid exceptions, infinite loops
(read v1 t1), (write v1 t2), (write v2 t2), (commit t2), (read v2 t1)Strictly serializable but not opaque
temp1 := Read v1 // (reads 0)
temp2 := Read v2 // (reads 10)while (temp1 != temp2){print ‘stuck!’}commit
Write (v1, 10)Write (v2, 10)commit
12Alpine Verification Meeting 2008
Alpine Verification Meeting 2008
MODEL CHECKING SAFETY
05/04/23 1313
Step 1: (n,k) TM As a first step, we restrict the TM to n
threads and k variables
We call this TM as the (n,k) TM
14Alpine Verification Meeting 2008
Modeling (n,k) TM as a TM Algorithm A transition system with:
Alphabet: (read/write of one of k variables, or commit or abort) of one of n threads + TM specific commands
States: every state records the state of all n threads
Transition relation: the protocol of the TM
Language: All words allowed by the TM algorithm
A TM produces the words in the language of its TM algorithm
rd, X, t2
rd, X, t1
c, t2c, t1
wr, X, t2
a, t2
a, t1
q0
q1
q5
q2
q7
q3
q6
q9
q8
q4
15Alpine Verification Meeting 2008
TM Algorithm for TL2T1:rs=ws={}, status=TT2: rs=ws={}, status=T
T1:rs={X}, ws={}, status=TT2: rs=ws={}, status=T
T1:rs=ws={}, status=TT2: rs={X},ws={}, status=T
T1:rs={},ws={X}, status=TT2: rs=ws={}, status=T
T1:rs={X},ws={}, status=TT2: rs={},ws={X}, status=T
T1:rs={X},ws={}, status=TT2: rs={X},ws={}, status=T
T1:rs={},ws={X}, status=TT2: rs={X},ws={}, status=T
T1:rs={X},ws={}, status=FT2: rs=ws={}, status=T
Read X, t1
Write X, t2
Write X, t1
Read X, t2
Read X, t2Read X, t1
Write X, t1
Commit, t2
Read X, t1
16Alpine Verification Meeting 2008
Key challenge: Infinite state space TMs use version numbers, timestamps
etc. for concurrency control A direct model would lead to infinite
state space How we get finite states:
Observation: These variables are used in a restricted manner in TMs, e.g. for comparison
Idea: Model only the effect of timestamps etc. in TM algorithms
17Alpine Verification Meeting 2008
Infinite -> finite states TMs have to work in a distributed
shared memory world: threads inform others by writing sequence
numbers or timestamps threads read timestamps of other threads to
know what they did We, as verifiers, may work in a
centralized world: Model thread interaction as setting/resetting
boolean flags for each other
18Alpine Verification Meeting 2008
Step 2: Safety property as a TM Algorithm A reference TM Algorithm: A
nondeterministic transition system whose language is the set of all words that are safe for a property
We build reference TM algorithms for strict serializability and opacity
Challenge: Language of the reference TM algorithm is exactly the set of words that are safe for the property
19Alpine Verification Meeting 2008
Step 3: A (n,k) TM is safe iff … The language of the TM algorithm for
the (n,k) TM is a subset of the language of the reference algorithm for the corresponding safety property.
Language inclusion problem!
20Alpine Verification Meeting 2008
Checking language inclusion To check whether A is a subset of B
Determinize B if B is nondeterministic Check that A does not intersect
complement of B Determinizing B infeasible if B is huge Sufficient condition: Existence of a
simulation relation A is simulated by B if every move that can
be played on A can also be played on B
21Alpine Verification Meeting 2008
Our automatic tool Given two TM algorithms A and B, our tool
first finds whether A is simulated by B If there is a simulation relation, the tool reports
that the language of A is included in the language of B
If there is no simulation relation, the tool tries to find a counterexample in L(B)\L(A): existence of a simulation relation is not a necessary condition for language inclusion if B is nondeterministic
Sound but incomplete
22Alpine Verification Meeting 2008
Step 4: Claim for the general case For n = 1,2,… and k = 1,2,…
Prove safety of the (n,k) TM
23Alpine Verification Meeting 2008
Symmetry of TMs TMs have some nice symmetry properties! Examples:
the TM protocol treats every thread as equal conflicts on different variables do not affect
each other aborting transactions do not affect committing
transactions Note: Properties break when threads are
prioritized, e.g. by contention managers
24Alpine Verification Meeting 2008
The reduction theorem For a symmetric TM, if (2,2) TM is safe for
strict serializability, then for any n and k, the (n,k) TM is safe for strict serializability
Similar theorem for opacity Symmetry properties hold for all TMs we
considered: DSTM, TL2, two phase locking What we get: It is enough to prove the
language inclusion for (2,2) TM
25Alpine Verification Meeting 2008
What we prove about safety We formally prove the following results:
Two phase locking, DSTM, TL2 are safe for opacity for any number of threads and variables
Optimistic concurrency control (a protocol for database transactions) is safe for strict serializability for any number of threads and variables, but unsafe for opacity
26Alpine Verification Meeting 2008
Some numbers… (2,2) DSTM: 850 states (2,2) TL2: 4500 states (2,2) reference for strict ser.: 12350
states (2,2) reference for opacity: 9400 states
27Alpine Verification Meeting 2008
Recap: How we proved safety Model a TM with fixed number of threads
and variables as a finite state transition system (translate sources of infinite state)
Capture the correctness criteria as finite state transition systems
Automatically verify safety for the (n,k) TM
Use symmetry of TMs to generalize the claim
28Alpine Verification Meeting 2008
An ambiguity we found TL2 uses two operations during commit:
validate all variables in the read set, and check that all variables in the read set are
unlocked Order of these operations ambiguous from
the specification Reversing order of these operations makes
(2,2) TL2 unsafe Implemented to occur atomically (therefore
not buggy)
30Alpine Verification Meeting 2008
Alpine Verification Meeting 2008
MODEL CHECKING LIVENESS
31
Liveness properties Utopia: Every thread commits infinitely often
(wait-freedom) Wait-freedom cannot be guaranteed in TM in
an asynchronous system Two weaker notions:
Lock freedom: commits occur infinitely often (no matter which thread commits)
Obstruction freedom: if a thread takes an infinite number of steps in isolation, it commits infinitely often
Wait freedom => Lock freedom => Obstruction freedom
32Alpine Verification Meeting 2008
A similar recipe for liveness Model (n,k) TM as a finite state transition
system Check automatically liveness of (n,k) TM Appeal to symmetry of TM
33Alpine Verification Meeting 2008
What we prove about liveness We formally prove the following results:
DSTM is obstruction free for any number of threads and variables
TL2, Two phase locking, Optimistic concurrency control are not obstruction free
None of these TMs are lock free or wait free
34Alpine Verification Meeting 2008
FURTHER WORK
Alpine Verification Meeting 2008 35
Making the procedure complete Incompleteness due to nondeterministic
references: Simple and intuitive. Explore all possible
serialization points of transactions Lot of redundancy. Many equivalent behaviors.
We build smaller deterministic references: Speed up model checking by ten times Give a sound and complete procedure Correctness not so intuitive: proved using an
antichain based tool
36Alpine Verification Meeting 2008
Handling Contention Managers Build a universal contention manager
(UCM) which chooses one of the possible decisions nondeterministically
Plug the TM with UCM and prove correctness
Correctness of TM with UCM => correctness of TM with any contention manager
DSTM, TL2 plugged with UCM satisfy symmetry properties
37Alpine Verification Meeting 2008
Conclusion Modeling transactional memories and
verifying safety and liveness First automatically prove the property
for a restricted case, then exploit inherent symmetry in TM to generalize the result
Works for most of the published TMs: we prove that DSTM and TL2 satisfy opacity with any contention manager
38Alpine Verification Meeting 2008
Drawbacks (Challenges!) Model does not handle when threads
help each other
Automating the check whether a TM algorithm satisfies reduction properties (Current work)
Automatically obtaining a finite state system from the TM description: use bisimulation to prove equivalence
39Alpine Verification Meeting 2008
General challenges: Level 1 (no agreed formalism) :
Getting non-transactional code in picture: strong vs weak atomicity
Handling nested transactions: open vs closed Level 2 (from algorithms to
implementations) : Taking model checking to the lowest level of
atomicity Handling relaxed memory models with TM
40Alpine Verification Meeting 2008
Thank you for your attention!
Questions?
Alpine Verification Meeting 2008 41