Upload
lambert-lucas
View
219
Download
0
Embed Size (px)
Citation preview
VMCAI / POPL 2009Spy Report
Topics of Interest (I)
• Semantics of concurrent programs– Programming languages & abstractions– Transactional memory (TM)– Alternative models• Message passing• Functional programming
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
Topics of Interest (III)
• Other craziness– Type theory– Abstract interpretation– Functional programming– …
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.}
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?
Atomic Blocks
• Solution (advocated by Harris):– Decouple TM from language constructs– At the high level: “strong semantics”
TMLow-level semantics &implementation(optimistic concurrency,lock-based, …)
high-level semantics
atomic blocks,retry, abort, …
programming discipline
Tradeoff
TM
programming discipline
staticseparation
dynamicseparation
violationfreedom
allprograms
“betterconcurrency”
“worseconcurrency”
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?
TM Model
• Over a set {x1,…,xt} of “transactional variables”
• A transaction:a sequence of operationsread(xi), write(xi,v), abort, commit
which return either a value, “ok”, or “abort”
History
Ti Tj
abort/commit
abort/commit
overlap conflict on xi:overlap + read/write orwrite/write to xi
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.
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 xIf hold lock on x, must write to x
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.
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 Lx such that1. Lx behaves like a try-lock,2. 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
3. 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)try-lock(Lx)write(x, v)
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.
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)
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
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 velse
decide read(V1-i)
Never unlocked…Because L is a strong try-lock,one process grabs it evenif both try at the same time.
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
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/threadreceive messages,
read valuessend messages,write values
Assume/Guarantee
assumption guarantee
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.
p0 p1assume
guarantee
assume
guarantee
Layered Proofs
p0 p1 safety property p1
p0 p1liveness property p2
p0 p1
⋮ ⋮termination
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
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.
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 requireprophecyvariables)
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 orinferred automatically
if x == null
if x != null
pop:
return success;
return failure;
Concurrent implementation Abstract (sequential) spec
(4) prove that the result is whatthe spec requires
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
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 controllogic
i can has lock?
yes/wait
instrumented executable
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
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?
Spec#
Spec#
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
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}}}
c1 := 0 ; c2 := 0;
c1 ++ ; c2 := 0;
c2 ++ ;
Invariant: c1 ≤ nInvariant: c2 ≤ mBound ≤ n∙m
Synthesizing Switching Logic
• [Synthesizing Switching Logic Using Constraint Solving, by Tali, Gulwani and Tiwari]
• Example: AC control unit
ON OFF
Goal: maintain temp [t∈ low, thigh]
condition1
condition2
temperature temperature
Synthesizing Switching Logic
Invariant
ControlledInductiveInvariant
?
? ?
Template:a11x2+ a12x2 + … ≤ b1
…Add constraints forcontrollability (∀∃)⇩Use SMT solver tofind a11, a12,…