PRACTICAL SYNTHESIS OF CONCURRENT SYSTEMS Martin Vechev Eran

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

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

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

Output • 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 9

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

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

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

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

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 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- 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 } bool remove(int key) { Entry *pred, *curr, *r restart: locate(pred, curr, key) k = (curr->key ≠ key) if (k) return false = curr->next, curr, 0 , entry, 0 ) if ( val) goto restart return true } 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 } 14

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

Generator: Domain Specific Search less atomic more atomic

Generate-Verify

Atomicity Reduction: Steps Removing redundant atomicity s 1 s 2 s 3 s 4 Reordering statements s 1 s 2 s 3 s 4 s 2 s 1 s 3 s 4 read Optimistic concurrency Add synchronization meta-data read update s 1 s 2 If (validate) update else restart s 3 s 4 s 1 If (t > 0) s 2 s 3 s 4 18

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

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

Step 2: Generate-Check 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 } ( (pred | curr) (->next)? == (pred | curr) (->next)? ) | true Generate-Check No correct completion found pred->next == curr pred truecurr == Insufficient information to write a validation condition 21

Step 2: Counterexample T 1: remove(5) || T 2: add(7) pred curr tail head - 1 pred 5 9 curr r 22

Step 2: Counterexample T 1: remove(5) T 2: add(7) || curr tail head - 1 9 pred 5 7 How to deal with removed nodes? 23

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

Step 3: Apply Transformation OBJECT key next marked REMOVE = { R 1: k = (curr->key ≠ key) R 2: if (k) return false R 3: curr->marked = true R 4: mp = pred->marked R 5: mc = curr->marked R 6: val= (pred->next == curr) ( mp)? ( mc)? R 7: if ( val) goto restart R 8: r = curr->next R 9: pred->next = r } 25

Step 4: Run Generate-Verify bool remove(int key) { Entry *pred, *curr, *r restart: locate(pred, curr, key) REMOVE return true Generate} Verify REMOVE = { R 1: k = (curr->key ≠ key) R 2: if (k) return false R 3: curr->marked = true R 4: mp = pred->marked R 5: mc = curr->marked R 6: val= (pred->next == curr) ? ( mp) ? ( mc) R 7: if ( val) goto restart R 8: r = curr->next R 9: 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 } 26

Fixed Previous Counterexample T 1: remove(5) pred || T 2: add(7) curr pred curr tail head - 1 pred 5 9 curr r add(7) observes pred “ 5” is marked and restarts 27

Final Result 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 } bool contains(int key) { Entry *pred, *curr locate(pred, curr, key) k = (curr->key == key) if (k) return false return true } 28

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

Verification-Driven Synthesis – 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)

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

High Level Setting Process 1 Process 2 Process 3 32

High Level Setting Process 1 Process 2 Process 3 33

High Level Setting Process 1 Process 2 Process 3 34

High Level Setting Process 1 Process 2 Process 3 35

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

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

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

High Level Setting Process 1 Process 2 Process 3 39

CCR Setting Process 1 Process 2 s 1; s 2; s 5; s 3; s 4; Process 3 s 6; Specification: s 7; • Permissiveness • Cost as a language of CCR guards 40

Maximal Permissiveness • 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: if B C then C does not satisfy S 41

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

This Work Process 1 Process 2 s 1; s 2; s 5; s 3; s 4; Process 3 s 7; s 6; Cost: Specification: Language of Guards Safety, No Stuck States Automatic Inference of Guards Correct and Maximally Permissive Process 1 Process 2 g 1 s 1; s 2; s 5; s 3; s 4; s 6; Process 3 g 2 s 7;

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

Inference Algorithm 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) } } 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 Process 1 Process 2 x=z+1; Process 3 y=x+1; Specification: • ! (y = 2 && z = 1) • No Stuck States z=y+1; Cost: LE( { x, y, z } ) Automatic Inference of Guards

What is in a state PC 1 PC 2 PC 3 s, s, s 0, 0, 0 X Y Z

Build Transition System s, s, s 0, 0, 0 e, s, s 1, 0, 0 y=x+1 z=y+1 y=x+1 x=z+1 s, e, s 0, 1, 0 s, s, e 0, 0, 1 z=y+1 x=z+1 e, e, s 1, 2, 0 e, s, e 1, 0, 1 z=y+1 e, e, e 1, 2, 3 e, e, s 1, 1, 0 y=x+1 e, e, e 1, 2, 1 s, e, e 0, 1, 2 x=z+1 z=y+1 e, e, e 1, 1, 2 e, s, e 2, 0, 1 e, e, e 3, 1, 2 y=x+1 s, e, e 0, 1, 1 y=x+1 e, e, e, 2, 3, 1 x=z+1 e, e, e 2, 1, 1 49

Select Transitions to Remove s, s, s 0, 0, 0 e, s, s 1, 0, 0 y=x+1 z=y+1 y=x+1 x=z+1 s, e, s 0, 1, 0 s, s, e 0, 0, 1 z=y+1 x=z+1 e, e, s 1, 2, 0 e, s, e 1, 0, 1 z=y+1 e, e, e 1, 2, 3 e, e, s 1, 1, 0 y=x+1 e, e, e 1, 2, 1 s, e, e 0, 1, 2 x=z+1 z=y+1 e, e, e 1, 1, 2 e, s, e 2, 0, 1 e, e, e 3, 1, 2 y=x+1 s, e, e 0, 1, 1 y=x+1 e, e, e, 2, 3, 1 x=z+1 e, e, e 2, 1, 1 50

Build Transition System s, s, s 0, 0, 0 y=x+1 x=z+1 e, s, s 1, 0, 0 y=x+1 x!=1 || y!=0 || z!=0 z=y+1 s, e, s 0, 1, 0 z=y+1 s, s, e 0, 0, 1 x!=1 || y!=0 || z!=0 z=y+1 x=z+1 e, e, s 1, 2, 0 e, s, e 1, 0, 1 x!=1 || y!=0 || z!=0 y=x+1 z=y+1 e, e, e 1, 2, 3 e, e, e 1, 2, 1 e, e, s 1, 1, 0 s, e, e 0, 1, 2 x!=1 || y!=0 || z!=0 z=y+1 e, e, e 1, 1, 2 e, s, e 2, 0, 1 x=z+1 e, e, e 3, 1, 2 Correct and Maximally Permissive y=x+1 s, e, e 0, 1, 1 y=x+1 e, e, e, 2, 3, 1 x=z+1 e, e, e 2, 1, 1 51

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

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

Build Transition System s, s, s 0, 0, 0 e, s, s 1, 0, 0 y=x+1 z=y+1 y=x+1 x=z+1 s, e, s 0, 1, 0 s, s, e 0, 0, 1 z=y+1 x=z+1 e, e, s 1, 2, 0 e, s, e 1, 0, 1 z=y+1 e, e, e 1, 2, 3 e, e, s 1, 1, 0 y=x+1 e, e, e 1, 2, 1 s, e, e 0, 1, 2 x=z+1 z=y+1 e, e, e 1, 1, 2 e, s, e 2, 0, 1 e, e, e 3, 1, 2 y=x+1 s, e, e 0, 1, 1 y=x+1 e, e, e, 2, 3, 1 x=z+1 e, e, e 2, 1, 1 54

Build Transition System s, s, s 0, 0, 0 e, s, s 1, 0, 0 y=x+1 z=y+1 y=x+1 x=z+1 s, e, s 0, 1, 0 s, s, e 0, 0, 1 z=y+1 x=z+1 e, e, s 1, 2, 0 e, s, e 1, 0, 1 z=y+1 e, e, e 1, 2, 3 e, e, s 1, 1, 0 y=x+1 e, e, e 1, 2, 1 s, e, e 0, 1, 2 x=z+1 z=y+1 e, e, e 1, 1, 2 e, s, e 2, 0, 1 e, e, e 3, 1, 2 y=x+1 s, e, e 0, 1, 1 y=x+1 e, e, e, 2, 3, 1 x=z+1 e, e, e 2, 1, 1 55

Select transition to remove s, s, s 0, 0, 0 e, s, s 1, 0, 0 y=x+1 z=y+1 y=x+1 x=z+1 s, e, s 0, 1, 0 s, s, e 0, 0, 1 z=y+1 x=z+1 e, e, s 1, 2, 0 e, s, e 1, 0, 1 z=y+1 e, e, e 1, 2, 3 e, e, s 1, 1, 0 y=x+1 e, e, e 1, 2, 1 s, e, e 0, 1, 2 x=z+1 z=y+1 e, e, e 1, 1, 2 e, s, e 2, 0, 1 e, e, e 3, 1, 2 y=x+1 s, e, e 0, 1, 1 y=x+1 e, e, e, 2, 3, 1 x=z+1 e, e, e 2, 1, 1 56

Select All Equivalent Transitions s, s, s 0, 0, 0 e, s, s 1, 0, 0 y=x+1 z=y+1 y=x+1 x=z+1 s, e, s 0, 1, 0 s, s, e 0, 0, 1 z=y+1 x=z+1 e, e, s 1, 2, 0 e, s, e 1, 0, 1 z=y+1 e, e, e 1, 2, 3 e, e, s 1, 1, 0 y=x+1 e, e, e 1, 2, 1 s, e, e 0, 1, 2 x=z+1 z=y+1 e, e, e 1, 1, 2 • Implementability e, s, e 2, 0, 1 e, e, e 3, 1, 2 y=x+1 s, e, e 0, 1, 1 y=x+1 e, e, e, 2, 3, 1 x=z+1 e, e, e 2, 1, 1 57

Build Transition System s, s, s 0, 0, 0 y=x+1 x=z+1 e, s, s 1, 0, 0 y=x+1 x!=1 || z!=0 z=y+1 s, e, s 0, 1, 0 s, s, e 0, 0, 1 x!=1 || z!=0 z=y+1 x=z+1 e, e, s 1, 2, 0 x!=1 || z!=0 z=y+1 e, e, e 1, 2, 3 e, s, e 1, 0, 1 e, e, s 1, 1, 0 y=x+1 e, e, e 1, 2, 1 • Stuck states s, e, e 0, 1, 2 x=z+1 z=y+1 e, e, e 1, 1, 2 e, s, e 2, 0, 1 e, e, e 3, 1, 2 y=x+1 s, e, e 0, 1, 1 y=x+1 e, e, e, 2, 3, 1 x=z+1 e, e, e 2, 1, 1 58

Select transitions to remove s, s, s 0, 0, 0 y=x+1 x=z+1 e, s, s 1, 0, 0 y=x+1 x!=1 || z!=0 z=y+1 s, e, s 0, 1, 0 s, s, e 0, 0, 1 x!=1 || z!=0 z=y+1 x=z+1 e, e, s 1, 2, 0 x!=1 || z!=0 z=y+1 e, e, e 1, 2, 3 e, s, e 1, 0, 1 e, e, s 1, 1, 0 y=x+1 e, e, e 1, 2, 1 s, e, e 0, 1, 2 x=z+1 z=y+1 e, e, e 1, 1, 2 e, s, e 2, 0, 1 e, e, e 3, 1, 2 y=x+1 s, e, e 0, 1, 1 y=x+1 e, e, e, 2, 3, 1 x=z+1 e, e, e 2, 1, 1 59

Build Transition System s, s, s 0, 0, 0 x!=0 || z!=0 x=z+1 y=x+1 e, s, s 1, 0, 0 y=x+1 e, e, 3 1, 2, 0 x!=1 || z!=0 z=y+1 e, e, e 1, 2, 3 s, e, s 0, 1, 0 x!=1 || z!=0 z=y+1 e, 2, e 1, 0, 1 y=x+1 e, e, e 1, 2, 1 x!=1 || z!=0 z=y+1 x!=0 || z!=0 x=z+1 e, e, 3 1, 1, 0 x!=1 || z!=0 z=y+1 e, e, e 1, 1, 2 s, s, e 0, 0, 1 x!=1 || z!=0 z=y+1 s, e, e 0, 1, 2 x!=0 || z!=0 x=z+1 e, e, e 3, 1, 2 Correct and Maximally Permissive x!=0|| z!=0 x=z+1 e, s, e 2, 0, 1 y=x+1 s, e, e 0, 1, 1 y=x+1 e, e, e, 2, 3, 1 x!=0 || z!=0 x=z+1 e, e, e 2, 1, 1 60

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

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

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

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

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

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

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

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

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

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

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

Trace Avoidance: avoid( ) • Atomicity predicate [ st 1 , st 2 ] disables a context switch • avoid( ) – disjunction of all possible atomicity predicates that would prevent : Thread A A 1 A 2 Thread B B 1 B 2 A 1 B 1 A 2 B 2 avoid( ) = [A 1, A 2] [B , B ]

Example T 1 T 2 1: x += z 2: x += z 1: z++ 2: z++ T 3 1: y 1 = f(x) 2: y 2 = x 3: assert(y 1 != y 2) 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 y 1 6 5 4 3 2 1 0 1 2 3 4 y 2 Concrete values 0 1 2 3 4 y 2 Parity abstraction (even/odd)

Example: Avoiding Bad Traces = true while(true) { Traces={ | ( P ) and S } if (Traces is empty) return implement(P, ) select Traces if (? ) { = avoid( ) } else { = refine( , ) } } avoid( 1) = [z++, z++] = true [z++, z++]

Example: Avoiding Bad Traces = true while(true) { Traces={ | ( P ) and S } if (Traces is empty) return implement(P, ) select Traces if (? ) { = avoid( ) } else { = refine( , ) } } avoid( 2) =[x+=z, x+=z] = [z++, z++]

Example: Avoiding Bad Traces = true while(true) { Traces={ | ( P ) and S } if (Traces is empty) return implement(P, ) select Traces if (? ) { = avoid( ) } else { = refine( , ) } } = [z++, z++] [x+=z, x+=z] T 1 1: x += z 2: x += z T 2 1: z++ 2: z++ T 3 1: y 1 = f(x) 2: y 2 = x 3: assert(y 1 != y 2)

Example: Avoiding Bad Traces parity T 1 x+=z; x+=z T 2 z++; T 3 y 1=f(x) y 2=x assert y 1!= y 2 y 1 6 5 4 3 2 1 0 1 2 3 4 y 2 parity T 1 x+=z; x+=z z++; T 2 z++; T 3 y 1=f(x) y 2=x assert y 1!= y 2 6 5 4 3 2 1 parity T 1 x+=z; x+=z T 2 z++; T 3 y 1=f(x) y 2=x assert y 1!= y 2 0 1 2 3 4 6 5 4 3 2 1 0 1 2 3 4 But we can also refine the abstraction…

parity T 1 x+=z; x+=z T 2 z++; T 3 y 1=f(x) y 2=x assert y 1!= y 2 y 1 6 5 4 3 2 1 0 1 2 3 4 (a) interval T 1 x+=z; x+=z T 2 z++; T 3 y 1=f(x) y 2=x assert y 1!= y 2 6 5 4 3 2 1 octagon T 1 x+=z; x+=z T 2 z++; T 3 y 1=f(x) y 2=x assert y 1!= y 2 interval T 1 x+=z; x+=z T 2 z++; T 3 y 1=f(x) y 2=x assert y 1!= y 2 0 1 2 3 4 (g) T 1 x+=z; x+=z T 2 z++; (c) 6 5 4 3 2 1 0 1 2 3 4 octagon T 1 x+=z; x+=z T 2 z++; parity T 3 y 1=f(x) y 2=x assert y 1!= y 2 0 1 2 3 4 (e) 6 5 4 3 2 1 (b) T 3 y 1=f(x) y 2=x assert y 1!= y 2 0 1 2 3 4 (d) (f) y 2 parity 6 5 4 3 2 1 0 1 2 3 4

Choosing a solution • Interval abstraction for our example: ([x+=z, x+=z] ∨ [z++, z++]) ∧ ([y 1=f(x), y 2=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

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

Examples • Simplified versions of – Double buffering – Defragmentation – … Program Refine Steps Avoid Steps Double buffering 1 2 Defragmentation 1 8 3 D array update 2 23 Array Removal 1 17 Array Init 1 56

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

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

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 Abstraction-Guided Synthesis Vechev M. , Yahav E. , Yorsh G. POPL '10: 37 th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages Experience with Model Checking Linearizability Vechev M. , Yahav E. , Yorsh G. SPIN '09: 16 th International SPIN Workshop on Model Checking of Software Inferring Synchronization Under Limited Observability Vechev M. , Yahav E. , Yorsh G. TACAS '09: 15 th International Conference on Tools and Algorithms for the Construction and Analysis of Systems Deriving Linearizable Fine-Grained Concurrent Objects Vechev M. , Yahav E PLDI '08: ACM SIGPLAN 2008 Conference on Programming Language Design and Implementation. 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. 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. http: //www. research. ibm. com/paraglide/ 90

Thanks