1. 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

2. 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 composable Correct efficient concurrent programs: Difficult ! 2

3. 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

4. Alpine Verification Meeting 2008 TL2 : An example STM Algorithm 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

5. Alpine Verification Meeting 2008 Example with TL2 Thread 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} (6 Commit Y with version 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

6. 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 6 Alpine Verification Meeting 2008

7. 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 7 Alpine Verification Meeting 2008

8. FORMALISM FOR TM 8

9. 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 9 Alpine Verification Meeting 2008

10. 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 10 Alpine Verification Meeting 2008

11. 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 11 Alpine Verification Meeting 2008

12. 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 12 Alpine Verification Meeting 2008

13. MODEL CHECKING SAFETY 2/17/201613

14. 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 14 Alpine Verification Meeting 2008

15. 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, t2 c, t1 wr, X, t2 a, t2 a, t1 q0 q1 q5 q2 q7 q3 q6 q9 q8 q4 15 Alpine Verification Meeting 2008

16. TM Algorithm for TL2 T1:rs=ws={}, status=T T2: rs=ws={}, status=T T1:rs={X}, ws={}, status=T T2: rs=ws={}, status=T T1:rs=ws={}, status=T T2: rs={X},ws={}, status=T T1:rs={},ws={X}, status=T T2: rs=ws={}, status=T T1:rs={X},ws={}, status=T T2: rs={},ws={X}, status=T T1:rs={X},ws={}, status=T T2: rs={X},ws={}, status=T T1:rs={},ws={X}, status=T T2: rs={X},ws={}, status=T T1:rs={X},ws={}, status=F T2: rs=ws={}, status=T Read X, t1 Write X, t2 Write X, t1 Read X, t2 Read X, t1 Write X, t1 Commit, t2 Read X, t1 16 Alpine Verification Meeting 2008

17. 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 17 Alpine Verification Meeting 2008

18. 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 18 Alpine Verification Meeting 2008

19. 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 19 Alpine Verification Meeting 2008

20. 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! 20 Alpine Verification Meeting 2008

21. 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 21 Alpine Verification Meeting 2008

22. 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 22 Alpine Verification Meeting 2008

23. Step 4: Claim for the general case For n = 1,2,… and k = 1,2,…  Prove safety of the (n,k) TM 23 Alpine Verification Meeting 2008

24. 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 24 Alpine Verification Meeting 2008

25. 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 25 Alpine Verification Meeting 2008

26. 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 26 Alpine Verification Meeting 2008

27. 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 27 Alpine Verification Meeting 2008

28. 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 28 Alpine Verification Meeting 2008

29. So, given a new TM… Check that the TM satisfies the symmetry properties  In case properties not satisfied, find other symmetry properties for some n and k Model the (n,k) TM as a finite state transition system (translate sources of infinite states) Input the transition system to our tool 29 Alpine Verification Meeting 2008

30. 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) 30 Alpine Verification Meeting 2008

31. MODEL CHECKING LIVENESS 31

32. 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 32 Alpine Verification Meeting 2008

33. 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 33 Alpine Verification Meeting 2008

34. 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 34 Alpine Verification Meeting 2008

35. FURTHER WORK Alpine Verification Meeting 2008 35

36. 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 36 Alpine Verification Meeting 2008

37. 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 37 Alpine Verification Meeting 2008

38. 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 38 Alpine Verification Meeting 2008

39. 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 39 Alpine Verification Meeting 2008

40. 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 40 Alpine Verification Meeting 2008

41. Thank you for your attention! Questions? Alpine Verification Meeting 2008 41