- By
**reuel** - Follow User

- 76 Views
- Uploaded on

Download Presentation
## PowerPoint Slideshow about ' VMCAI / POPL 2009 Spy Report' - reuel

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

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

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

Download Presentation

Connecting to Server..