inferring synchronization under limited observability

Inferring Synchronization under Limited Observability

Martin Vechev, Eran Yahav, Greta Yorsh

IBM T.J. Watson Research Center

(work in progress)

• Assist the programmer in systematically exploring alternative choices of synchronization– correctness– synchronization cost

Concurrency is Hard.

Inferring Synchronization• Input

– program P – specification S

• Output a program P’– P’ satisfies S– P’ obtained from P by adding synchronization

• Challenge: eliminate invalid interleavings while preserving as many valid ones as possible

Dimensions for Comparing Solutions

• Permissiveness– P1 is more permissive than P2 when P2 P1

• Synchronization Cost– P1 has lower cost than P2 when the running time of

synchronization code in P1 is smaller than that of P2

Observability• Connection between permissiveness and

synchronization cost

• User input: upper bound on synchronization cost• Limits the observations about program state that

can be made by the synchronization code

max perm forbounded cost

permissiveness

cost

max perm

incomparable solutions

Synchronization under Limited Observability

• Input– program P – specification S– cost function and cost bound C

• Output a program P’– P’ satisfies S– P’ obtained from P by adding synchronization

restricted to C

Is it always possible to find P’ s.t. P P’ ? NO!

Maximally Permissive Program• P’ is maximally permissive with respect to C

– P’ satisfies S– P’ obtained from P by adding synchronization

restricted to C– for every P’’ obtained from P by adding

synchronization restricted to C if P’ P’’ then P’’ does not satisfy S

Our Goal• Input

– program P – specification S– observability C

• Output a concurrent program P’– P’ satisfies S– P’ obtained from P by adding synchronization

restricted to C– P’ is maximally permissive with respect to C– synchronization code in P’ must not block indefinitely

• Semaphores • Monitors • Conditional critical region (CCR)• Fine grained (e.g., CAS)• Locks• ....

Synchronization Mechanisms

Conditional Critical Regions• Syntax of CCR

• Declarative• Synchronization code

– can observe the program state – does not modify program state

• How to infer guards for CCRs ?

guard stmt

Limited Observability• Bounded cost of synchronization means

restricted language of guardsLG = { guard | cost(guard) < bound }

• Limits observations about program state thatcan be made by the guards

Example Languages of Guards• EQ(V)

– boolean combination of equalities between variable from V and integer constant

– (x != 1 || z != 0)

• EvenOdd(V)– boolean combinations of predicates even and odd

applied to program expressions over V– e(x) || o(y)

Example

!(y = 2 && z = 1)

• Program

• Specification

• Full observability EQ({ x,y,z })

op1 { 1: x = z + 1 }

op2 { 2: y = x + 1 }

op3 { 3: z = y + 1 }

main {

int x = 0, y = 0, z = 0;

op1 || op2 || op3

}

Example1,2,30,0,0

e,2,31,0,0

1,e,30,1,0

1,2,e0,0,1

e,e,31,2,0

e,2,e1,0,1

e,e,31,1,0

1,e,e0,1,2

e,2,e2,0,1

1,e,e0,1,1

e,e,e1,2,3

e,e,e1,2,1

e,e,e1,1,2

e,e,e3,1,2

e,e,e,2,3,1

e,e,e2,1,1

x=z+1 y=x+1 z=y+1

y=x+1

y=x+1z=y+1

z=y+1

x=z+1

z=y+1

z=y+1

x=z+1

x=z+1

x=z+1

y=x+1

y=x+1

Example

!(y = 2 && z = 1)

op1 { 1: x = z + 1 }

op2 { 2: y = x + 1 }

op3 { 3: (x!=1 || y!=0 || z!=0) z = y + 1 }main {

int x = 0, y = 0, z = 0;

op1 || op2 || op3

}

• Program

• Specification

• Full observability EQ( { x,y,z } )

Example

!(y = 2 && z = 1)

• Program

• Specification

• Limited observability EQ( { x, z } )

op1 { 1: x = z + 1 }

op2 { 2: y = x + 1 }

op3 { 3: z = y + 1 }

main {

int x = 0, y = 0, z = 0;

op1 || op2 || op3

}

Example

!(y = 2 && z = 1)

op1 { 1: (x != 0 || z != 0) x = z + 1 }

op2 { 2: y = x + 1 }

op3 { 3: (x != 1 || z != 0) z = y + 1 }main {

int x = 0, y = 0, z = 0;

op1 || op2 || op3

}

• Program

• Specification

• Limited observability EQ( { x, z } )

Example1,2,30,0,0

e,2,31,0,0

1,e,30,1,0

1,2,e0,0,1

e,e,31,2,0

e,2,e1,0,1

e,e,31,1,0

1,e,e0,1,2

e,2,e2,0,1

1,e,e0,1,1

e,e,e1,2,3

e,e,e1,2,1

e,e,e1,1,2

e,e,e3,1,2

e,e,e,2,3,1

e,e,e2,1,1

x=z+1 y=x+1 z=y+1

y=x+1

y=x+1z=y+1

z=y+1

x=z+1

z=y+1

z=y+1

x=z+1

x=z+1

x=z+1

y=x+1

y=x+1

x!=1 || z!=0

x!=1 || z!=0

x!=1 || z!=0

x!=1 || z!=0

x!=0 || z!=0

x!=0 || z!=0

x!=0 || z!=0

x!=0 || z!=0

x!=1 || z!=0

x!=0|| z!=0

Our Approach

• Construct transition system of P and S

• Remove a (minimal) set of transitions such that the result satisfies S

• Implement resulting transition system as program by strengthening guards of CCRs in P

Removing Transitions

• Which transitions to remove? – bad-transitions transitions on a path to doomed state– cut-transitions transitions from non-doomed to

doomed state

• In what order to remove transitions?

GREEDY(P : Program) : Program {

R = ∅while (true) {

ts = < States , Transitions \ R, Init >

if valid(ts) return implement(P,R)

B = cut-transitions(ts)

if B = abort “cannot find valid synchronization”∅ select a transition t B∈ R = R ∪ equiv(t)

}

}

Algorithm

Example

!(y = 2 && z = 1)

• Program

• Specification

• Limited observability EQ( { x, z } )

op1 { 1: x = z + 1 }

op2 { 2: y = x + 1 }

op3 { 3: z = y + 1 }

main {

int x = 0, y = 0, z = 0;

op1 || op2 || op3

}

Example1,2,30,0,0

e,2,31,0,0

1,e,30,1,0

1,2,e0,0,1

e,e,31,2,0

e,2,e1,0,1

e,e,31,1,0

1,e,e0,1,2

e,2,e2,0,1

1,e,e0,1,1

e,e,e1,2,3

e,e,e1,2,1

e,e,e1,1,2

e,e,e3,1,2

e,e,e,2,3,1

e,e,e2,1,1

x=z+1 y=x+1 z=y+1

y=x+1

y=x+1z=y+1

z=y+1

x=z+1

z=y+1

z=y+1

x=z+1

x=z+1

x=z+1

y=x+1

y=x+1

Side Effects• Transitions associated with the same CCR are

controlled by the same guard• Strengthening guard associated with transition t1

has side-effect – if no guard can distinguish between source(t1) and

sourc(t2) due to limited observability – transition system without t1 but with t2 is

not implementable

• Side effect may create new doomed states!

Step 01,2,30,0,0

e,2,31,0,0

1,e,30,1,0

1,2,e0,0,1

e,e,31,2,0

e,2,e1,0,1

e,e,31,1,0

1,e,e0,1,2

e,2,e2,0,1

1,e,e0,1,1

e,e,e1,2,3

e,e,e1,2,1

e,e,e1,1,2

e,e,e3,1,2

e,e,e,2,3,1

e,e,e2,1,1

x=z+1 y=x+1 z=y+1

y=x+1

y=x+1z=y+1

z=y+1

x=z+1

z=y+1

z=y+1

x=z+1

x=z+1

x=z+1

y=x+1

y=x+1

Step 11,2,30,0,0

e,2,31,0,0

1,e,30,1,0

1,2,e0,0,1

e,e,31,2,0

e,2,e1,0,1

e,e,31,1,0

1,e,e0,1,2

e,2,e2,0,1

1,e,e0,1,1

e,e,e1,2,3

e,e,e1,2,1

e,e,e1,1,2

e,e,e3,1,2

e,e,e,2,3,1

e,e,e2,1,1

x=z+1 y=x+1 z=y+1

y=x+1

y=x+1z=y+1

z=y+1

x=z+1

z=y+1

z=y+1

x=z+1

x=z+1

x=z+1

y=x+1

y=x+1

x!=1 || z!=0

x!=1 || z!=0

x!=1 || z!=0

x!=1 || z!=0

x!=1 || z!=0

Step 21,2,30,0,0

e,2,31,0,0

1,e,30,1,0

1,2,e0,0,1

e,e,31,2,0

e,2,e1,0,1

e,e,31,1,0

1,e,e0,1,2

e,2,e2,0,1

1,e,e0,1,1

e,e,e1,2,3

e,e,e1,2,1

e,e,e1,1,2

e,e,e3,1,2

e,e,e,2,3,1

e,e,e2,1,1

x=z+1 y=x+1 z=y+1

y=x+1

y=x+1z=y+1

z=y+1

x=z+1

z=y+1

z=y+1

x=z+1

x=z+1

x=z+1

y=x+1

y=x+1

x!=1 || z!=0

x!=1 || z!=0

x!=1 || z!=0

x!=1 || z!=0

x!=0 || z!=0

x!=0 || z!=0

x!=0 || z!=0

x!=0 || z!=0

x!=1 || z!=0

x!=0|| z!=0

GREEDY(P : Program) : Program {

R = ∅while (true) {

ts = < States , Transitions \ R, Init >

if valid(ts) return implement(P,R)

B = cut-transitions(ts)

if B = abort “cannot find valid synchronization”∅ select a transition t B∈ R = R ∪ equiv(t)

}

}

Algorithm

Algorithms• Greedy algorithm

– removes cut-transitions– result satisfies spec (or abort)– if there are no side-effects

then the result is maximally permissive – can be extended to be maximally permissive– polynomial

• Exhaustive algorithm– removes bad-transitions– result satisfies spec (or abort)– (all) maximally permissive – exponential

Initial Evaluation• Prototype

– greedy algorithm– transition system constructed using SPIN

• Examples – Dining philosophers – Asynchronous counters– Race correction

Infinite Transition System

• Finite state abstraction • Same algorithm

Example

pc2 == 6 even(x+y)

op1 { 1: x = x + 1 2: y = y + 1 3: goto 1}

• Program

• Specification

EvenOdd(x,y)

main { x = 0, y =0; op1 || op2}

op2 { 4: x = x - 1 5: y = y - 1 6: goto 4}

• Limited observability

Example

op1 { 1: odd(x+y) x = x + 1 2: y = y + 1 3: goto 1}

• Program op2 { 4: x = x - 1 5: odd(x+y) y = y - 1 6: goto 4}

Result satisfies the spec but might block

pc2 == 6 even(x+y)

• Specification

EvenOdd(x,y)

• Limited observability

Inferring Guards under Abstraction

• Conservatively eliminate potentially stuck states– cannot guarantee maximally permissive

• Refine when state becomes potentially stuck– terminates if there is a finite bisimulation quotient

• Specialized abstractions for stuckness– related to abstractions for termination

Summary• Greedy and exhaustive algorithms for inferring

guards of CCRs– maximally permissive programs– limited observability– side effects– implementability– observational equivalence– characterizing observable states– minimize synchronization cost

Related Work• Recovery and predication mechanisms

– STM, Isolator, Tolerace

• Synthesis from temporal specification– controller synthesis

• Program repair as a game– memoryless maximal winning strategy

Ongoing and Future Work• Greedy algorithm based on domination• Conditions for maximal permissiveness• Minimize synchronization cost for given observability

• Complexity of guard inference (NP-hard,coNP-hard,2)

• Abstraction for stuck states• Temporal safety and liveness properties

• Infer other synchronization mechanisms– meta-data, atomic sections, non-blocking