1. Inferring Synchronization under Limited Observability Martin Vechev, Eran Yahav, Greta Yorsh IBM T.J. Watson Research Center (work in progress)

2. Assist the programmer in systematically exploring alternative choices of synchronization – correctness – synchronization cost Concurrency is Hard.

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

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

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

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

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

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

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

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

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

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

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

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

15. 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 } )

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

17. 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 } )

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

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

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

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

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

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

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

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

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

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

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

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

30. Initial Evaluation Prototype – greedy algorithm – transition system constructed using SPIN Examples – Dining philosophers – Asynchronous counters – Race correction

31. Infinite Transition System Finite state abstraction Same algorithm

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

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

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

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

36. Related Work Recovery and predication mechanisms – STM, Isolator, Tolerace Synthesis from temporal specification – controller synthesis Program repair as a game – memoryless maximal winning strategy

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

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

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

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

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