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,…