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 for bounded 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 guards LG = { guard | cost(guard) < bound } Limits observations about program state that can 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 }

Example 1,2,3 0,0,0 e,2,3 1,0,0 1,e,3 0,1,0 1,2,e 0,0,1 e,e,3 1,2,0 e,2,e 1,0,1 e,e,3 1,1,0 1,e,e 0,1,2 e,2,e 2,0,1 1,e,e 0,1,1 e,e,e 1,2,3 e,e,e 1,2,1 e,e,e 1,1,2 e,e,e 3,1,2 e,e,e, 2,3,1 e,e,e 2,1,1 x=z+1 y=x+1 z=y+1 y=x+1 z=y+1 x=z+1 z=y+1 x=z+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 } )

Example 1,2,3 0,0,0 e,2,3 1,0,0 1,e,3 0,1,0 1,2,e 0,0,1 e,e,3 1,2,0 e,2,e 1,0,1 e,e,3 1,1,0 1,e,e 0,1,2 e,2,e 2,0,1 1,e,e 0,1,1 e,e,e 1,2,3 e,e,e 1,2,1 e,e,e 1,1,2 e,e,e 3,1,2 e,e,e, 2,3,1 e,e,e 2,1,1 x=z+1 y=x+1 z=y+1 y=x+1 z=y+1 x=z+1 z=y+1 x=z+1 y=x+1 x!=1 || 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 = 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 }

Example 1,2,3 0,0,0 e,2,3 1,0,0 1,e,3 0,1,0 1,2,e 0,0,1 e,e,3 1,2,0 e,2,e 1,0,1 e,e,3 1,1,0 1,e,e 0,1,2 e,2,e 2,0,1 1,e,e 0,1,1 e,e,e 1,2,3 e,e,e 1,2,1 e,e,e 1,1,2 e,e,e 3,1,2 e,e,e, 2,3,1 e,e,e 2,1,1 x=z+1 y=x+1 z=y+1 y=x+1 z=y+1 x=z+1 z=y+1 x=z+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 0 1,2,3 0,0,0 e,2,3 1,0,0 1,e,3 0,1,0 1,2,e 0,0,1 e,e,3 1,2,0 e,2,e 1,0,1 e,e,3 1,1,0 1,e,e 0,1,2 e,2,e 2,0,1 1,e,e 0,1,1 e,e,e 1,2,3 e,e,e 1,2,1 e,e,e 1,1,2 e,e,e 3,1,2 e,e,e, 2,3,1 e,e,e 2,1,1 x=z+1 y=x+1 z=y+1 y=x+1 z=y+1 x=z+1 z=y+1 x=z+1 y=x+1

Step 1 1,2,3 0,0,0 e,2,3 1,0,0 1,e,3 0,1,0 1,2,e 0,0,1 e,e,3 1,2,0 e,2,e 1,0,1 e,e,3 1,1,0 1,e,e 0,1,2 e,2,e 2,0,1 1,e,e 0,1,1 e,e,e 1,2,3 e,e,e 1,2,1 e,e,e 1,1,2 e,e,e 3,1,2 e,e,e, 2,3,1 e,e,e 2,1,1 x=z+1 y=x+1 z=y+1 y=x+1 z=y+1 x=z+1 z=y+1 x=z+1 y=x+1 x!=1 || z!=0 

Step 2 1,2,3 0,0,0 e,2,3 1,0,0 1,e,3 0,1,0 1,2,e 0,0,1 e,e,3 1,2,0 e,2,e 1,0,1 e,e,3 1,1,0 1,e,e 0,1,2 e,2,e 2,0,1 1,e,e 0,1,1 e,e,e 1,2,3 e,e,e 1,2,1 e,e,e 1,1,2 e,e,e 3,1,2 e,e,e, 2,3,1 e,e,e 2,1,1 x=z+1 y=x+1 z=y+1 y=x+1 z=y+1 x=z+1 z=y+1 x=z+1 y=x+1 x!=1 || z!=0  x!=0 || z!=0  x!=1 || z!=0  x!=0|| z!=0 

GREEDY(P : Program) : Program { R = ∅ while (true) { ts = 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

Problem on Graphs Input – graph G = (V,E) – initial nodes Init  V – equivalence relation   E  E E’ is admissible iff – E’ is closed under  – every node reachable from Init using only edges in E’ has at least one outgoing edge in E’ Search problem: find admissible E’ such that for every E’’ if E’  E’’ then E’’ is not admissible Decision problem: given k, is there a solution E’ to the search problem and |E’| = k Complexity: NP-hard, coNP-hard, in  2

Reduction from 3SAT i=1 m    (l i1  l i2  l i3 ) l ij  { x 1,..., x n, x 1,..., x n } xixi xixi xixi xixi a a choose exactly one of xi, xi l i1 l i3 l i2 l i1 l i3 l i2 aaa choose exactly one of li1,li2,li3

Example l 11 l 13 l 12 x2x2   (x 1  x 2  x 3 )  (x 1  x 4  x 3 ) x3x3 x1x1 l 21 l 23 l 22 x4x4 x3x3 x1x1 Construction b c c b a a

Reduction from 3SAT Build problem of decision problem from gadgets – (G=(E,V), Init, , k) NP-hard – k = 2n + 2m + m + 2 –  is sat iff (G, Init, , k) is YES coNP-hard – k = 2n + 2m + 2 –  is not sat iff (G, Init, , k) is YES