VMCAI / POPL 2009 Spy Report

1. VMCAI / POPL 2009Spy 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” high-level semantics atomic blocks, retry, abort, … programming discipline Low-level semantics & implementation (optimistic concurrency, lock-based, …) TM

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

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

10. TM Model • Over a set {x1,…,xt} of “transactional variables” • A transaction: a sequence of operations read(xi),write(xi,v), abort, commit which return either a value, “ok”, or “abort” overlap conflict on xi: overlap + read/write or write/write to xi Ti Tj History abort/ commit abort/ commit

11. Strong Progressiveness • If Ti aborts then either • Ti called abort, or • Some other transaction conflicts with Ti. 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 Lx • Add try-lock, unlock operations on Lxsuch that • Lx behaves like a try-lock, • If pi executes try-lock(Lx) or holds Lx at time t in E’, then at time t in E, pi executes a transaction that writes to x; and • If Tk is aborted, then either • There is some Lx such that every try-lock(Lx) in Tk fails, or • Tk invokes read(x) such some other process holds Lx while Tk executes and before Tk acquires Lx (if ever) write(x, v) try-lock(Lx)

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 ; V0,V1 : registers) process pi executes: write(Vi, v) locked← try-lock(L) if(locked) decide v else decide read(V1-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 Ti aborts, then Ti 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: Assume/Guarantee process/ thread receive messages, read values send messages, write values assumption guarantee

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

22. Layered Proofs p0 p1 safety property p1 p0 p1 liveness property p2 ⋮ ⋮ p0 p1 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 (disclaimer: may require prophecy variables) if x == null if x != null

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

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? instrumented executable program control logic i can has lock? yes/wait

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# 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 }}} Invariant: c1≤ n Invariant: c2≤ m Bound ≤ n∙m c1 := 0 ; c2 := 0; c1 ++ ; c2 := 0; c2 ++ ;

34. Synthesizing Switching Logic • [Synthesizing Switching Logic Using Constraint Solving, by Tali, Gulwani and Tiwari] • Example: AC control unit Goal: maintain temp ∈ [tlow, thigh] condition1 ON OFF condition2 temperature temperature

35. Synthesizing Switching Logic ? Invariant ? ? Controlled Inductive Invariant Template: a11x2+ a12x2 + … ≤ b1 … Add constraints for controllability (∀∃) ⇩ Use SMT solver to find a11, a12,…