PRACTICAL SYNTHESIS OF CONCURRENT SYSTEMS Martin Vechev Eran Yahav Greta Yorsh IBM T.J. Watson Research Center

2 Plan Motivation Case Study: Concurrent Data Structures Hoare’s CCR Finite State Abstract Interpretation Based Synthesis Memory Fences (Optional)

Concurrency is Important

Concurrency is Hard “…I develop Mozilla full time all day, and i get this lockup maybe once a day…”

Concurrency is Hard “…For nearly two weeks I thought the above solution was correct, until I started to try to prove its correctness...it turned out to be wrong… So there I was. Fooled again.” -- Edsger W. Dijkstra

Problem Manually Finding Correct and Efficient Synchronization 6

Our Approach Automatically Infer Correct and Efficient Synchronization 7

Input 8 Believable starting point – Intuitive to a programmer, e.g. sequential program Specification should be easy to write – Reusability: e.g. sequential consistency Some quantitative notion of efficiency – E.g. Fewer locks

9 Output should be a program – Synchronization implemented in the language Output program(s) should be correct – With respect to the specification (checked or verified) Output program(s) should be optimal – With respect to efficiency Output

10 Plan Motivation Case Study: Concurrent Data Structures Hoare’s CCR Finite State Abstract Interpretation Based Synthesis Memory Fences (Optional)

Concurrent Data Structures Applications (typically) have to share data Need to synchronize Concurrent data structures are critical for performance – Used in various language runtimes, kernels, etc Coarse Locks are often a bad idea – Single thread holding lock can stop global system progress – Coarse-grained locking leads to contention – Fine-grained locking tricky to get right (deadlocks) 11

val popRight() { while (true) { rh = RightHat; lh = LeftHat; if (rh->R == rh) return "empty"; if (rh == lh) { if (DCAS(&RightHat, &LeftHat, rh, lh, Dummy, Dummy)) return rh->V; } else { rhL = rh->L; if (DCAS(&RightHat, &rh->L, rh, rhL, rhL, rh)) { result = rh->V; rh->R = Dummy; return result; }}} “Even better DCAS-based concurrent deques”, DISC errors in < 20 lines of code ! Concurrent Data Structures

Existing Approaches for Concurrent Object Construction Performance Manual Effort Sequential Naïve STM Fine-grained STM Expert Design This Work Goal 13

14 bool add(int key) { Entry *pred,*curr,*entry restart: locate(pred,curr,key) k = (curr->key == key) if (k) return false entry = new Entry() entry->next = curr val=CAS(&pred- >next,  curr,0 ,  entry,0  ) if (  val) goto restart return true } bool remove(int key) { Entry *pred,*curr,*r restart: locate(pred,curr,key) k = (curr->key ≠ key) if (k) return false = curr->next lval=CAS(&curr->next,  r,m ,  r,1  ) if (  lval) goto restart pval=CAS(&pred- >next,  curr,0 ,  r,0  ) if (  pval) goto restart return true } Sequential to Highly Concurrent Sets bool add(int key){ atomic Entry *pred,*curr,*entry locate(pred,curr,key); k = (curr->key == key) if (k) return false entry = new Entry() entry->next = curr pred->next = entry return true } bool remove(int key){ atomic Entry *pred,*curr,*r locate(pred,curr,key) k = (curr->key ≠ key) if (k) return false r = curr->next pred->next = r return true }

Generate - Verify Generator Verifier Schema Specification Abstraction Program Yes/No, Counterexample Set Of Optimal Programs

Generator: Domain Specific Search less atomic more atomic

Generate-Verify

Atomicity Reduction: Steps Removing redundant atomicity Reordering statements Optimistic concurrency Add synchronization meta-data 18 s1 s2 s3 s4 s1 s2 s3 s4 If (validate) update else restart read s1 s2 s3 s4 s2 s1 s3 s4 s3 s4 read update s1 s2 s1 If (t > 0) s2 s3 s4

19 Concurrent Sets: Generate-Check Schema Correct Algorithm DCAS Sequential DCAS CAS with LOCKS Priority Queue Stack CAS/DCAS … … Michael (PODC’02) Heller et al. (OPODIS’05) Trieber Stack Existing Algorithm New Algorithm

locate(pred,curr,key) 20 Step 1: Optimistic Concurrency [Kung & Robinson’81] bool remove(int key){ Entry *pred,*curr,*r atomic locate(pred,curr,key) k = (curr->key ≠ key) if (k) return false r = curr->next pred->next = r return true } bool remove(int key){ Entry *pred,*curr,*r restart: Read atomic if ( validate ) { Update } goto restart } k = (curr->key ≠ key) if (k) return false r = curr->next pred->next = r return true Update Read

Step 2: Generate-Check 21 Generate-Check No correct completion found Insufficient information to write a validation condition bool remove(int key){ Entry *pred,*curr,*r locate(pred,curr,key) atomic if (validate) { k = (curr->key ≠ key) if (k) return false r = curr->next pred->next = r return true } goto restart } truepred->next == currpred == curr ( (pred | curr) (->next)? == (pred | curr) (->next)? ) | true

Step 2: Counterexample 22 -- 159  head tail predcurr r predcurr T1: remove(5) T2: add(7) ||

Step 2: Counterexample 23 -- 159  head tail pred curr T1: remove(5) T2: add(7) || 7 How to deal with removed nodes?

Dealing with Removed Nodes? Observability (Meta-Data) Synchronization Time 24

25 Step 3: Apply Transformation keynextkeynext marked REMOVE = { R1: k = (curr->key ≠ key) R2: if (k) return false R3: curr->marked = true R4: mp =  pred->marked R5: mc =  curr->marked R6: val= (pred->next == curr) (  mp)? (  mc)? R7: if (  val) goto restart R8: r = curr->next R9: pred->next = r } OBJECT

Step 4: Run Generate-Verify 26 bool remove(int key) { Entry *pred,*curr,*r restart: locate(pred,curr,key) REMOVE return true } REMOVE = { R1: k = (curr->key ≠ key) R2: if (k) return false R3: curr->marked = true R4: mp =  pred->marked R5: mc =  curr->marked R6: val= (pred->next == curr) ? (  mp) ? (  mc) R7: if (  val) goto restart R8: r = curr->next R9: pred->next = r } bool remove(int key) { Entry *pred,*curr,*r restart: locate(pred,curr,key) REMOVE return true } REMOVE = { k = (curr->key ≠ key) if (k) return false curr->marked = true r = curr->next atomic mp =  pred->marked val=(pred->next==curr)  mp if (  val) goto restart pred->next = r } Generate- Verify

27 -- 19  head tail predcurr r predcurr T1: remove(5) T2: add(7) || Fixed Previous Counterexample add(7) observes pred “5” is marked and restarts predcurr 5

28 bool add(int key) { Entry *pred,*curr,*entry restart: locate(pred,curr,key) k = (curr->key == key) if (k) return false entry = new Entry() entry->next = curr val=CAS(&pred->next,  curr,0 ,  entry,0  ) if (  val) goto restart return true } bool remove(int key) { Entry *pred,*curr,*r restart: locate(pred,curr,key) k = (curr->key ≠ key) if (k) return false = curr->next lval=CAS(&curr->next,  r,m ,  r,1  ) if (  lval) goto restart pval=CAS(&pred->next,  curr,0 ,  r,0  ) if (  pval) goto restart return true } Final Result bool contains(int key) { Entry *pred,*curr locate(pred,curr,key) k = (curr->key == key) if (k) return false return true }

Lessons Generate-Verify Shortcomings – Generate can produce programs that cannot be verified – Verifier doing redundant work Expressing insights as syntactic templates is cumbersome Concurrency inherently tied to Space

– Enable automatic verification to do inference Verification: no longer only a yes/no answer – Input: A (possibly incorrect) concurrent program – Output: A set of programs (possibly empty set) Verification-Driven Synthesis

31 Plan Motivation Case Study: Concurrent Data Structures Hoare’s CCR Finite State Abstract Interpretation Based Synthesis Memory Fences (Optional)

High Level Setting 32 Process 1Process 2Process 3

High Level Setting 33 Process 1Process 2Process 3

High Level Setting 34 Process 1Process 2Process 3

High Level Setting 35 Process 1Process 2Process 3

Challenge 36 Process 1Process 2Process 3 How to synchronize processes in order to achieve correctness and good performance ?

Semaphores Monitors Conditional critical region (CCR) Fine grained (e.g., CAS) Atomics.... Synchronization Primitives 37

Conditional Critical Regions Syntax of CCR Synchronization code – guard can observe the program state – guard does not modify program state guard  stmt 38

High Level Setting 39 Process 1Process 2Process 3

CCR Setting 40 Process 1Process 2Process 3 s1;s2; s5; s7; s6; s3;s4; Specification:  Permissiveness Cost as a language of CCR guards

Given a language LG, specification S and program A, program B is maximally permissive, if: – B satisfies S – B is obtained from A by adding guards from LG – Cannot obtain a program C that is correct and more permissive than B from A via LG: 41 Maximal Permissiveness if  B    C  then C does not satisfy S

Two Algorithms to infer CCR guards – Greedy – Exhaustive Guarantee maximal permissiveness – Greedy: under some conditions – Exhaustive: always Implementation in SPIN – prototype, examples Contributions

This Work Safety, No Stuck States Specification: Language of Guards Cost: Automatic Inference of Guards Process 1Process 2Process 3 s1;s2; s5; s7; s6; s3;s4; Process 1Process 2Process 3 g1  s1;s2; s5; g2  s7; s6; s3;s4; Correct and Maximally Permissive

Inference Algorithm Construct transition system of input program and specification Remove a (minimal) set of transitions such that the result satisfies the specification Implement resulting transition system as program by strengthening guards of CCRs in the program 44

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) } Inference Algorithm 45

Example Language: Observability Obs: Variables that can be read by CCR guards LE(Obs): language of boolean combinations of equalities between variables in Obs and constants Example: Obs: {x, y, z} Guard Expression in LE(Obs): (x!=1 || y!=0 || z!=0) 46

Example: Full Observability ! (y = 2 && z = 1) No Stuck States Specification: LE( { x, y, z } ) Cost: Automatic Inference of Guards z=y+1; Process 1 x=z+1; y=x+1; Process 2 Process 3

What is in a state s,s,s 0,0,0 X Y Z PC1 PC2 PC3

Build Transition System s,s,s 0,0,0 e,s,s 1,0,0 s,e,s 0,1,0 s,s,e 0,0,1 e,e,s 1,2,0 e,s,e 1,0,1 e,e,s 1,1,0 s,e,e 0,1,2 e,s,e 2,0,1 s,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 49

Select Transitions to Remove s,s,s 0,0,0 e,s,s 1,0,0 s,e,s 0,1,0 s,s,e 0,0,1 e,e,s 1,2,0 e,s,e 1,0,1 e,e,s 1,1,0 s,e,e 0,1,2 e,s,e 2,0,1 s,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 50

s,s,s 0,0,0 e,s,s 1,0,0 s,e,s 0,1,0 s,s,e 0,0,1 e,e,s 1,2,0 e,e,s 1,1,0 s,e,e 0,1,2 e,s,e 2,0,1 s,e,e 0,1,1 e,e,e 1,2,3 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 51 e,s,e 1,0,1 e,e,e 1,2,1 y=x+1 z=y+1 Build Transition System x!=1 || y!=0 || z!=0  Correct and Maximally Permissive

Example: Full Observability ! (y = 2 && z = 1) No Stuck States Specification: LE( { x, y, z } ) Cost: Automatic Inference of Guards z=y+1; Process 1 x=z+1; y=x+1; Process 2 Process 3 (x!=1 || y!=0 || z!=0)  z=y+1; Process 1 x=z+1; y=x+1; Process 2 Process 3

Example: Limited Observability ! (y = 2 && z = 1) No Stuck States Specification: LE( { x,, z } ) Cost: Automatic Inference of Guards z=y+1; Process 1 x=z+1; y=x+1; Process 2 Process 3

s,s,s 0,0,0 e,s,s 1,0,0 s,e,s 0,1,0 s,s,e 0,0,1 e,e,s 1,2,0 e,s,e 1,0,1 e,e,s 1,1,0 s,e,e 0,1,2 e,s,e 2,0,1 s,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 54 Build Transition System

s,s,s 0,0,0 e,s,s 1,0,0 s,e,s 0,1,0 s,s,e 0,0,1 e,e,s 1,2,0 e,s,e 1,0,1 e,e,s 1,1,0 s,e,e 0,1,2 e,s,e 2,0,1 s,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 55

Select transition to remove s,s,s 0,0,0 e,s,s 1,0,0 s,e,s 0,1,0 s,s,e 0,0,1 e,e,s 1,2,0 e,s,e 1,0,1 e,e,s 1,1,0 s,e,e 0,1,2 e,s,e 2,0,1 s,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 56

s,s,s 0,0,0 e,s,s 1,0,0 s,e,s 0,1,0 s,s,e 0,0,1 e,e,s 1,2,0 e,s,e 1,0,1 e,e,s 1,1,0 s,e,e 0,1,2 e,s,e 2,0,1 s,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 57 Select All Equivalent Transitions Implementability

s,s,s 0,0,0 e,s,s 1,0,0 s,e,s 0,1,0 s,s,e 0,0,1 s,e,e 0,1,2 e,s,e 2,0,1 s,e,e 0,1,1 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 x=z+1 z=y+1 x=z+1 y=x+1 58 Stuck states e,e,s 1,2,0 e,s,e 1,0,1 e,e,s 1,1,0 e,e,e 1,2,3 e,e,e 1,2,1 e,e,e 1,1,2 y=x+1 z=y+1 x!=1 || z!=0  z=y+1 x!=1 || z!=0  Build Transition System

s,s,s 0,0,0 e,s,s 1,0,0 s,e,s 0,1,0 s,s,e 0,0,1 s,e,e 0,1,2 e,s,e 2,0,1 s,e,e 0,1,1 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 x=z+1 z=y+1 x=z+1 y=x+1 59 e,e,s 1,2,0 e,s,e 1,0,1 e,e,s 1,1,0 e,e,e 1,2,3 e,e,e 1,2,1 e,e,e 1,1,2 y=x+1 z=y+1 x!=1 || z!=0  z=y+1 x!=1 || z!=0  Select transitions to remove

s,s,s 0,0,0 e,s,s 1,0,0 s,e,s 0,1,0 s,s,e 0,0,1 e,e,3 1,2,0 e,2,e 1,0,1 e,e,3 1,1,0 s,e,e 0,1,2 e,s,e 2,0,1 s,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  60 Build Transition System Correct and Maximally Permissive

Example: Limited Observability Automatic Inference of Guards (x!=1 || z!=0)  z=y+1; Process 1 (x!=0 || z!=0)  x=z+1; y=x+1; Process 2 Process 3 z=y+1; Process 1 x=z+1; y=x+1; Process 2 Process 3 ! (y = 2 && z = 1) No Stuck States Specification: LE( { x,, z } ) Cost:

Inference Algorithms Greedy algorithm – Resulting program satisfies the specification – No side-effects guarantees maximal permissiveness – Experience: maximally permissive with side-effects – Polynomial Exhaustive algorithm – Resulting program satisfies the specification – Maximally permissive – Exponential 62

Implementation Prototype – Greedy algorithm – Using SPIN Examples – Dining philosophers – Asynchronous counters – Race correction 63

Summary Algorithms for CCR guard inference – Greedy (polynomial) and Exhaustive (exponential) – Produce maximally permissive programs – Parametric on User-specified Cost – Deals with side effects and implementability 64

Future Work Conditions for maximal permissiveness of greedy Infer other synchronization mechanisms – meta-data, atomic sections, non-blocking Abstraction for stuck states 65

66 Plan Motivation Case Study: Concurrent Data Structures Hoare’s CCR Finite State Abstract Interpretation Based Synthesis Memory Fences (Optional)

Crash Course on Abstract Interpretation Verify that property holds on all executions Challenge: programs with unbounded state  bad news: problem is undecidable good news: can use over-approximation – Consider a superset of possible executions – sound: a yes is a yes! – incomplete: a no is a maybe … 67

Verification Challenge main(int i) { int x=3,y=1; do { y = y + 1; } while(--i > 0) assert 0 < x + y } Determine what states can arise during any execution Challenge: set of states is unbounded 68

Abstract Interpretation Recipe 1)Abstraction 2)Transformers 3)Exploration main(int i) { int x=3,y=1; do { y = y + 1; } while(--i > 0) assert 0 < x + y } Challenge: set of states is unbounded Solution: compute a bounded representation of (a superset) of program states Determine what states can arise during any execution 69

1) Abstraction concrete state abstract state main(int i) { int x=3,y=1; do { y = y + 1; } while(--i > 0) assert 0 < x + y }  : Var  Z  # : Var  {+, 0, -, ?} xyi 31 7 xyi xyi … 70

2) Transformers concrete transformer abstract transformer main(int i) { int x=3,y=1; do { y = y + 1; } while(--i > 0) assert 0 < x + y } xyi ++ 0 xyi 31 0 y = y + 1 xyi 32 0 xyi ? ? 0 +? 0 71

3) Exploration ++ ? ++ ? xyi main(int i) { int x=3,y=1; do { y = y + 1; } while(--i > 0) assert 0 < x + y } ++ ? ++ ? ?? ? xyi ++ ? ++ ? ++ ? ++ ? ++ ? ++ ? 72

Incompleteness  main(int i) { int x=3,y=1; do { y = y - 2; y = y + 3; } while(--i > 0) assert 0 < x + y } +? ? +? ? xyi +? ? ++ ? ?? ? xyi +? ? +? ? +? ? 73

Concurrent Program Specification Abstraction Abstract Interpreter  Refine Counter Example Change the abstraction to match the program  Automatic Verification with Abstraction

Concurrent Program Specification Abstraction Abstract Interpreter  Refine Counter Example Restrict the program to match the abstraction   Avoid Counter Example Program Automatic Construction with Abstraction

AGS Algorithm – High Level  = true while(true) { Traces = {  |   (  P       ) and   S} if (Traces is empty) return implement(P,  ) select   Traces if (?) {  =   avoid(  ) } else {  = refine( ,  ) } Input: Program P, Specification S, Abstraction  Output: Program P’ satisfying S under 

Trace Avoidance: avoid(  ) :: Thread A A1 A2 Thread B B1 B2 Atomicity predicate [ st1, st2 ] disables a context switch avoid(  ) – disjunction of all possible atomicity predicates that would prevent  A1 A2 B1 B2 avoid(  ) = [A 1,A 2 ]  [B 1,B 2 ]

Example T1 1: x += z 2: x += z T2 1: z++ 2: z++ T3 1: y1 = f(x) 2: y2 = x 3: assert(y1 != y2) f(x) { if (x == 1) return 3 else if (x == 2) return 6 else return 5 } How to place synchronization to achieve correctness and performance?

Example: Parity Abstraction y2 y1 1 Concrete values y2 y1 1 Parity abstraction (even/odd)

avoid(  1 ) = [z++,z++]  = [z++,z++]  = true while(true) { Traces={  |  (  P       ) and   S } if (Traces is empty) return implement(P,  ) select   Traces if (?) {  =   avoid(  ) } else {  = refine( ,  ) } Example: Avoiding Bad Traces

avoid(  2 ) =[x+=z,x+=z]  = [z++,z++]  = [z++,z++]  [x+=z,x+=z]  = true while(true) { Traces={  |  (  P       ) and   S } if (Traces is empty) return implement(P,  ) select   Traces if (?) {  =   avoid(  ) } else {  = refine( ,  ) } Example: Avoiding Bad Traces

T1 1: x += z 2: x += z T2 1: z++ 2: z++ T3 1: y1 = f(x) 2: y2 = x 3: assert(y1 != y2)  = [z++,z++]  [x+=z,x+=z]  = true while(true) { Traces={  |  (  P       ) and   S } if (Traces is empty) return implement(P,  ) select   Traces if (?) {  =   avoid(  ) } else {  = refine( ,  ) } Example: Avoiding Bad Traces

y2 y1 1 parity  x+=z; x+=z z++; y1=f(x) y2=x assert y1!= y2 T1 T2 T3 x+=z; x+=z z++; y1=f(x) y2=x assert y1!= y2 T1 T2 T parity x+=z; x+=z z++; y1=f(x) y2=x assert y1!= y2 T1 T2 T3 But we can also refine the abstraction… Example: Avoiding Bad Traces

y2 y parity interval octagon     (a)(b) (c) (d)(e) (f)(g) parity interval octagon x+=z; x+=z z++; y1=f(x) y2=x assert y1!= y2 T1 T2 T3 x+=z; x+=z z++; y1=f(x) y2=x assert y1!= y2 T1 T2 T3 x+=z; x+=z z++; y1=f(x) y2=x assert y1!= y2 T1 T2 T3 x+=z; x+=z z++; y1=f(x) y2=x assert y1!= y2 T1 T2 T3 x+=z; x+=z z++; y1=f(x) y2=x assert y1!= y2 T1 T2 T3 x+=z; x+=z z++; y1=f(x) y2=x assert y1!= y2 T1 T2 T3 x+=z; x+=z z++; y1=f(x) y2=x assert y1!= y2 T1 T2 T3

Choosing a solution Interval abstraction for our example: ([x+=z,x+=z] ∨ [z++,z++]) ∧ ([y1=f(x),y2=x] ∨ [x+=z,x+=z] ∨ [z++,z++]) Minimal satisfying assignments –  1 = [z++, z++] –  2 = [x+=z, x+=z] Different Quantitative Notions: – Example: preference to solutions with fewer write operations inside atomic sections

 Separation between scheduling constraints in  and how they are realized  Can realize in program via atomic sections  Can realize in scheduler via benevolent scheduler Implementation

Examples ProgramRefine StepsAvoid Steps Double buffering12 Defragmentation18 3D array update223 Array Removal117 Array Init156 Simplified versions of – Double buffering – Defragmentation – …

Future Work Add more powerful abstractions – E.g. Heap, Polyhedra Synthesize more complex synchronization – Infer practical concurrent algorithms

89 Plan Motivation Case Study: Concurrent Data Structures Hoare’s CCR Finite State Abstract Interpretation Based Synthesis Memory Fences (Optional)

Results Partial-Coherence Abstractions for Weak Memory Models Kuperstein M., Vechev M., Yahav E. Submitted Automatic Inference of Memory Fences Kuperstein M., Vechev M., Yahav E. Submitted Verifying Linearizability with Hindsight O'Hearn P., Rinetzky N., Vechev M., Yahav E., Yorsh G. PODC '10: Symposium on Principles of Distributed Computing PODC '10 Abstraction-Guided Synthesis Vechev M., Yahav E., Yorsh G. POPL '10: 37th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages POPL '10 Experience with Model Checking Linearizability Vechev M., Yahav E., Yorsh G. SPIN '09: 16th International SPIN Workshop on Model Checking of Software SPIN '09 Inferring Synchronization Under Limited Observability Vechev M., Yahav E., Yorsh G. TACAS '09: 15th International Conference on Tools and Algorithms for the Construction and Analysis of Systems TACAS '09 Deriving Linearizable Fine-Grained Concurrent Objects Vechev M., Yahav E PLDI '08: ACM SIGPLAN 2008 Conference on Programming Language Design and Implementation. PLDI '08 CGCExplorer: A Semi-Automated Search Procedure for Provably Correct Concurrent Collectors Vechev M., Yahav E., Bacon D.F., and Rinetzky N. PLDI '07: ACM SIGPLAN 2007 Conference on Programming Language Design and Implementation. PLDI '07 Correctness-Preserving Derivation of Concurrent Garbage Collection Algorithms Vechev M., Yahav E., and Bacon D.F. PLDI '06: ACM SIGPLAN 2006 Conference on Programming Language Design and Implementation. PLDI '

Thanks