1. VMCAI / POPL 2009 Spy Report

2. Topics of Interest (I) Semantics of concurrent programs – Programming languages & abstractions – Transactional memory (TM) – Alternative models Message passing Functional programming

3. Topics of Interest (II) Verifying concurrent programs – Proving concurrency-related properties “Shared memory safety” No race conditions Various notions of progress (no deadlock, …) Linearizability – Abstractions for shared-memory programs Separation logic Shape-modular analysis

4. Topics of Interest (III) Other craziness – Type theory – Abstract interpretation – Functional programming – …

5. Semantics of Concurrent Programs [Invited Talk: Language Constructs for Transactional Memory, by Tim Harris (MSR)] Convention: “Coarse-grained synchronization is inefficient, fine-grained synchronization is hard” The ideal solution: atomic{ // touch shared memory, etc. }

6. Atomic Blocks Design questions: – What can you do inside an atomic block? Touch all variables / only pre-declared “shared” variables? Commands with side effects? E.g.,atomic { if(..) launch_missile(); } – Strong atomicity / weak atomicity? atomic { if(x == 0) x = 1; } ‖ x = 2; – What happens in case of a rollback?

7. Atomic Blocks Solution (advocated by Harris): – Decouple TM from language constructs – At the high level: “strong semantics” TM Low-level semantics & implementation (optimistic concurrency, lock-based, …) high-level semantics atomic blocks, retry, abort, … programming discipline

8. Tradeoff TM programming discipline static separation dynamic separation violation freedom all programs “better concurrency” “worse concurrency”

9. Progress Semantics for TM [The Semantics of Progress in Lock-Based Transactional Memory. Rachid Guerraoui, Michal Kapalka (EPFL)] What kind of progress guarantees should a TM provide?

10. TM Model Over a set {x 1,…,x t } of “transactional variables” A transaction: a sequence of operations read(x i ), write(x i,v), abort, commit which return either a value, “ok”, or “abort” History TiTi TjTj abort/ commit abort/ commit overlapconflict on x i : overlap + read/write or write/write to x i

11. Strong Progressiveness If T i aborts then either – T i called abort, or – Some other transaction conflicts with T i. plus, If a set of transactions conflict only on one variable, at least one must succeed.

12. Proving Strong Progressiveness Must reason about all histories – Unbounded length – Unbounded number of transactional variables Restrict attention to “lock-based TMs” (TL2, TinySTM, RSTM, McRT-STM,…) Use “virtual locks” to reason about conflicts – Writing to x = “grabbing a lock on x” – Abort must be justified in terms of locks – Don’t care about safety, only liveness! If writing to x, must hold lock on x If hold lock on x, must write to x

13. Connection to Try-locks Try-lock object: – try-lock → “yes” / “no” (non-blocking) – unlock → “yes” Safety: mutual exclusion Strong try-lock: If several processes compete for the lock, one succeeds.

14. Verifying Strong Progressiveness A strong try-lock extension of a history E: – For every variable x introduce a try-lock L x – Add try-lock, unlock operations on L x such that 1.L x behaves like a try-lock, 2.If p i executes try-lock(L x ) or holds L x at time t in E’, then at time t in E, p i executes a transaction that writes to x; and 3.If T k is aborted, then either – There is some L x such that every try-lock(L x ) in T k fails, or – T k invokes read(x) such some other process holds L x while T k executes and before T k acquires L x (if ever) try-lock(L x )write(x, v)

15. Verifying Strong Progressiveness Reduction Theorem: For any TM implementation M, if every history of M has a strong try-lock extension, then M is strongly progressive.

16. Characterizing Strong Progressiveness How easy is strong progressiveness to implement? Theorem: a strongly progressive TM has consensus number 2. Implications: – Cannot be implemented using read/write registers – Can be implemented using test&set / queue (does not require, e.g., CAS)

17. Strongly-Progressive TM has CN 2 Phase 1: strongly-progressive TM ≡ strong try-locks Phase 2: consensus number of strong try-locks ≥ 2 – 2-process consensus can be solved using try-locks Phase 3: consensus number of strong try-locks ≤ 2 – try-locks can be implemented from test&set

18. Solving consensus using try-locks (L : a strong try-lock ; V 0,V 1 : registers) process p i executes: write(V i, v) locked ← try-lock(L) if(locked) decide v else decide read(V 1-i ) Never unlocked… Because L is a strong try-lock, one process grabs it even if both try at the same time.

19. Weak Progressiveness What can be done using read/write registers? Strong progressiveness: – If T i aborts, then T i conflicts with some other transaction; and – If a set of transactions conflict on only one variable, at least one must succeed. Weakly-progressive TM can be implemented from registers. Weak

20. Proving Liveness in Concurrent Programs [Proving that Non-Blocking Algorithms Don’t Block, by Gotsman, Cook, Parkinson and Vafeiadis.] Typical approach for verifying concurrent programs: process/ thread receive messages, read values send messages, write values Assume/Guarantee assumption guarantee

21. Circular A/G Set P of symmetric processes: “assuming P / { p i } satisfy A, p i guarantees A” ⇒ A holds (under no assumptions). Sound for safety properties But not for liveness properties. p0p0 p1p1 assume guarantee assume guarantee

22. Layered Proofs p0p0 p1p1 safety property p 1 p0p0 p1p1 liveness property p 2 p0p0 p1p1 ⋮⋮ termination

23. Intermediate Properties Often sufficient: (safety) Λ “operations x,y,z are not called infinitely often” ⇒ automated search procedure Can prove: – Wait-freedom – Lock-freedom – Obstruction-freedom

24. Proving Linearizability [Shape-Value Abstraction for Verifying Linearizability, by Victor Vafeiadis.] Linearizability: – Every operation has a linearization point between invocation and response – The resulting sequential history is legal.

25. Proving Linearizability Find linearization points in the code – Not necessarily a single point per operation – Not necessarily in the code for the operation… If more than one, choice must be deterministic Prove that they are linearization points if x == null if x != null (disclaimer: may require prophecy variables)

26. Proving Linearizability Prove that they are linearization points: (1)embed abstract spec (2)prove every LP is reached at most once (3)prove every LP is reached in every terminating exec. Given by user or inferred automatically if x == null if x != null pop: return success; return failure; Concurrent implementationAbstract (sequential) spec (4)prove that the result is what the spec requires

27. Inferring LPs Heuristics: – Restrict to points in the code of the operation – Restrict to accesses of shared memory – Restrict to writes to shared memory Unsuitable for… – Effect-free methods (e.g., find) – Algorithms with helping

28. Deadlock Avoidance [The Theory of Deadlock Avoidance via Discrete Control, by Lafortune, Kelly, Kudlur and Mahlke] Deadlock-freedom can be hard to prove … so why not prevent deadlock? program control logic i can has lock? yes/wait instrumented executable

29. Software Verification Hardware is verified by model-checking In software we have to deal with… – Infinite state space (e.g., integer variables) – The heap, pointers, aliasing – Recursion – Unbounded concurrency, shared memory

30. Software Verification Ruling approaches: – Use static analysis to restrict possible values of variables – Reduce to some “easy” representation and do model- checking Abstract into a finite model Use PDA to model recursion and function calls – Hoare-style proofs {precondition} … {postcondition} Translate to first-order logic formula and send to theorem prover / SMT solver E.g., {x > 0} y := x { y > 0 } ⇩ (x = 0) Λ (y = x) Λ (y <= 0) SAT?

31. Spec#

32. Software Verification Today’s state of the art can in many cases: – Verify Hoare triplets {p} S {q} – Verify termination By automatic inference of ranking functions – Infer invariants (abstract interpretation+widening) – Infer weakest pre/postconditions

33. SPEED [SPEED: Precise and Efficient Static Estimation of Program Computational Complexity, by Gulwani, Mehra, and Chilimbi] Example: function f(n) {x := 0; y := 0; while(x++ <= n) { while(y++ <= m) { // foo}}} c 1 := 0 ; c 2 := 0; c 1 ++ ; c 2 := 0; c 2 ++ ; Invariant: c 1 ≤ n Invariant: c 2 ≤ m Bound ≤ n ∙ m

34. Synthesizing Switching Logic [Synthesizing Switching Logic Using Constraint Solving, by Tali, Gulwani and Tiwari] Example: AC control unit ONOFF Goal: maintain temp ∈ [t low, t high ] condition 1 condition 2 temperature

35. Synthesizing Switching Logic Invariant Controlled Inductive Invariant ? ? ? Template: a 11 x 2 + a 12 x 2 + … ≤ b 1 … Add constraints for controllability ( ∀∃) ⇩ Use SMT solver to find a 11, a 12,…