Alpine Verification Meeting 2008 Model Checking Transactional Memories Vasu Singh (Joint work with Rachid Guerraoui, Tom Henzinger, Barbara Jobstmann)

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


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


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


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


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



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


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


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


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



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


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


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


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


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


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


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!


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


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


Step 4: Claim for the general case For n = 1,2,… and k = 1,2,…

Prove safety of the (n,k) TM


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


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


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


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


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


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)



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


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


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


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


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


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


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


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


Thank you for your attention!

Questions?

Alpine Verification Meeting 2008 41

Documents

Alpine Verification Meeting 2008 Model Checking Transactional Memories Vasu Singh (Joint work with Rachid Guerraoui, Tom Henzinger, Barbara Jobstmann)