Vmcai popl 2009 spy report
Sponsored Links
This presentation is the property of its rightful owner.
1 / 35

VMCAI / POPL 2009 Spy Report PowerPoint PPT Presentation


  • 56 Views
  • Uploaded on
  • Presentation posted in: General

VMCAI / POPL 2009 Spy 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

Download Presentation

VMCAI / POPL 2009 Spy Report

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


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”

high-level semantics

atomic blocks,

retry, abort, …

programming discipline

Low-level semantics &

implementation

(optimistic concurrency,

lock-based, …)

TM


Tradeoff

all

programs

violation

freedom

dynamic

separation

static

separation

programming discipline

TM

“worse

concurrency”

“better

concurrency”


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?


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


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 x

If 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 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)


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


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:

Assume/Guarantee

process/

thread

receive messages,

read values

send messages,

write values

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.

assume

p0

p1

guarantee

guarantee

assume


Layered Proofs

p0

p1

safety property p1

p0

p1

liveness 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

(disclaimer:

may require

prophecy

variables)

if x == null

if x != null


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


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?

instrumented executable

program

control

logic

i can has lock?

yes/wait


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}}}

Invariant: c1≤ n

Invariant: c2≤ m

Bound ≤ n∙m

c1 := 0 ; c2 := 0;

c1 ++ ; c2 := 0;

c2 ++ ;


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


Synthesizing Switching Logic

?

Invariant

?

?

Controlled

Inductive

Invariant

Template:

a11x2+ a12x2 + … ≤ b1

Add constraints for

controllability (∀∃)

Use SMT solver to

find a11, a12,…


  • Login