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

VMCAI / POPL 2009 Spy Report PowerPoint PPT Presentation


  • 49 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 2009 spy report

VMCAI / POPL 2009Spy Report


Topics of interest i

Topics of Interest (I)

  • Semantics of concurrent programs

    • Programming languages & abstractions

    • Transactional memory (TM)

    • Alternative models

      • Message passing

      • Functional programming


Topics of interest ii

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

Topics of Interest (III)

  • Other craziness

    • Type theory

    • Abstract interpretation

    • Functional programming


Semantics of concurrent programs

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

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 blocks1

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

Tradeoff

all

programs

violation

freedom

dynamic

separation

static

separation

programming discipline

TM

“worse

concurrency”

“better

concurrency”


Progress semantics for tm

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

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

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

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

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

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 progressiveness1

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

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

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

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

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

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

Layered Proofs

p0

p1

safety property p1

p0

p1

liveness property p2

p0

p1

termination


Intermediate properties

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

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 linearizability1

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 linearizability2

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

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

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

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 verification1

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?


Vmcai popl 2009 spy report

Spec#

Spec#


Software verification2

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

  • [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

  • [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 logic1

Synthesizing Switching Logic

?

Invariant

?

?

Controlled

Inductive

Invariant

Template:

a11x2+ a12x2 + … ≤ b1

Add constraints for

controllability (∀∃)

Use SMT solver to

find a11, a12,…


  • Login