1 Eran Yahav Technion Joint work with Martin Vechev (ETH), Greta Yorsh (ARM), Michael Kuperstein (Technion), Veselin Raychev (ETH)

Slides:



Advertisements
Similar presentations
Bounded Model Checking of Concurrent Data Types on Relaxed Memory Models: A Case Study Sebastian Burckhardt Rajeev Alur Milo M. K. Martin Department of.
Advertisements

Modular and Verified Automatic Program Repair Francesco Logozzo, Thomas Ball RiSE - Microsoft Research Redmond.
Introduction to Formal Methods for SW and HW Development 09: SAT Based Abstraction/Refinement in Model-Checking Roberto Sebastiani Based on work and slides.
Greta YorshEran YahavMartin Vechev IBM Research. { ……………… …… …………………. ……………………. ………………………… } P1() Challenge: Correct and Efficient Synchronization { ……………………………
Greta YorshEran YahavMartin Vechev IBM Research. { ……………… …… …………………. ……………………. ………………………… } T1() Challenge: Correct and Efficient Synchronization { ……………………………
SAT Based Abstraction/Refinement in Model-Checking Based on work by E. Clarke, A. Gupta, J. Kukula, O. Strichman (CAV’02)
Knowledge Based Synthesis of Control for Distributed Systems Doron Peled.
A Program Transformation For Faster Goal-Directed Search Akash Lal, Shaz Qadeer Microsoft Research.
Abstraction and Modular Reasoning for the Verification of Software Corina Pasareanu NASA Ames Research Center.
Reduction, abstraction, and atomicity: How much can we prove about concurrent programs using them? Serdar Tasiran Koç University Istanbul, Turkey Tayfun.
“FENDER” AUTOMATIC MEMORY FENCE INFERENCE Presented by Michael Kuperstein, Technion Joint work with Martin Vechev and Eran Yahav, IBM Research 1.
Paraglide Martin Vechev Eran Yahav Martin Vechev Eran Yahav.
Inferring Disjunctive Postconditions Corneliu Popeea and Wei-Ngan Chin School of Computing National University of Singapore - ASIAN
5.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts with Java – 8 th Edition Chapter 5: CPU Scheduling.
Enforcing Sequential Consistency in SPMD Programs with Arrays Wei Chen Arvind Krishnamurthy Katherine Yelick.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13.
PARTIAL-COHERENCE ABSTRACTIONS FOR RELAXED MEMORY MODELS Presented by Michael Kuperstein, Technion Joint work with Martin Vechev, IBM Research and Eran.
The Software Model Checker BLAST by Dirk Beyer, Thomas A. Henzinger, Ranjit Jhala and Rupak Majumdar Presented by Yunho Kim Provable Software Lab, KAIST.
Asynchronous Assertions Eddie Aftandilian and Sam Guyer Tufts University Martin Vechev ETH Zurich and IBM Research Eran Yahav Technion.
Lecture 02 – Structural Operational Semantics (SOS) Eran Yahav 1.
Martin Vechev IBM Research Michael Kuperstein Technion Eran Yahav Technion (FMCAD’10, PLDI’11) 1.
Martin Vechev IBM Research Michael Kuperstein Technion Eran Yahav Technion (FMCAD’10, PLDI’11) 1.
Inferring Synchronization under Limited Observability Martin Vechev Eran Yahav Greta Yorsh IBM T.J. Watson Research Center.
1 Lecture 09 – Synthesis of Synchronization Eran Yahav.
On the Relationship Between Concurrent Separation Logic and Assume-Guarantee Reasoning Xinyu Feng Yale University Joint work with Rodrigo Ferreira and.
Programming Language Semantics Mooly SagivEran Yahav Schrirber 317Open space html://
Semantics with Applications Mooly Sagiv Schrirber html:// Textbooks:Winskel The.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 4: SMT-based Bounded Model Checking of Concurrent Software.
Maria-Cristina Marinescu Martin Rinard Laboratory for Computer Science Massachusetts Institute of Technology A Synthesis Algorithm for Modular Design of.
Thread-modular Abstraction Refinement Thomas A. Henzinger, et al. CAV 2003 Seonggun Kim KAIST CS750b.
1 Thread Synchronization: Too Much Milk. 2 Implementing Critical Sections in Software Hard The following example will demonstrate the difficulty of providing.
15-740/ Oct. 17, 2012 Stefan Muller.  Problem: Software is buggy!  More specific problem: Want to make sure software doesn’t have bad property.
Testing and Verifying Atomicity of Composed Concurrent Operations Ohad Shacham Tel Aviv University Nathan Bronson Stanford University Alex Aiken Stanford.
Chapter 25 Formal Methods Formal methods Specify program using math Develop program using math Prove program matches specification using.
Race Checking by Context Inference Tom Henzinger Ranjit Jhala Rupak Majumdar UC Berkeley.
Martin Vechev Eran Yahav Greta Yorsh IBM T.J. Watson Research Center.
COMP 111 Threads and concurrency Sept 28, Tufts University Computer Science2 Who is this guy? I am not Prof. Couch Obvious? Sam Guyer New assistant.
Lazy Abstraction Jinseong Jeon ARCS, KAIST CS750b, KAIST2/26 References Lazy Abstraction –Thomas A. Henzinger et al., POPL ’02 Software verification.
Inferring Synchronization under Limited Observability Martin Vechev, Eran Yahav, Greta Yorsh IBM T.J. Watson Research Center (work in progress)
CS Data Structures I Chapter 2 Principles of Programming & Software Engineering.
Shared Memory Consistency Models. SMP systems support shared memory abstraction: all processors see the whole memory and can perform memory operations.
Memory Consistency Models. Outline Review of multi-threaded program execution on uniprocessor Need for memory consistency models Sequential consistency.
Symbolic Execution with Abstract Subsumption Checking Saswat Anand College of Computing, Georgia Institute of Technology Corina Păsăreanu QSS, NASA Ames.
Semantics In Text: Chapter 3.
Pattern-based Synthesis of Synchronization for the C++ Memory Model Yuri Meshman, Noam Rinetzky, Eran Yahav 1.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
CIS 842: Specification and Verification of Reactive Systems Lecture INTRO-Examples: Simple BIR-Lite Examples Copyright 2004, Matt Dwyer, John Hatcliff,
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
Theory-Aided Model Checking of Concurrent Transition Systems Guy Katz, Clark Barrett, David Harel New York University Weizmann Institute of Science.
/ PSWLAB Thread Modular Model Checking by Cormac Flanagan and Shaz Qadeer (published in Spin’03) Hong,Shin Thread Modular Model.
Presented by: Belgi Amir Seminar in Distributed Algorithms Designing correct concurrent algorithms Spring 2013.
Abstractions for Relaxed Memory Models Andrei Dan, Yuri Meshman, Martin Vechev, Eran Yahav 1.
Program Analysis and Verification
Simplifying Linearizability Proofs Using Reduction and Abstraction Serdar Tasiran Koc University, Istanbul, Turkey Tayfun Elmas, Ali Sezgin, Omer Subasi.
Principles of Programming & Software Engineering
Lecture 20: Consistency Models, TM
SDN Network Updates Minimum updates within a single switch
Memory Consistency Models
Memory Consistency Models
Amir Kamil and Katherine Yelick
Abstraction-Guided Synthesis
Over-Approximating Boolean Programs with Unbounded Thread Creation
Lecture 22: Consistency Models, TM
Background and Motivation
Synthesis of Memory Fences via Refinement Propagation
Amir Kamil and Katherine Yelick
Lecture: Consistency Models, TM
BLAST: A Software Verification Tool for C programs
Abstraction-Guided Synthesis of synchronization
Presentation transcript:

1 Eran Yahav Technion Joint work with Martin Vechev (ETH), Greta Yorsh (ARM), Michael Kuperstein (Technion), Veselin Raychev (ETH)

Verification with Abstraction 2 P   S ?

Now what? 3 P   S P   ’ S Refine the abstraction P   S Clarke,Grumberg, Jha, Lu, Veith. Counterexample-Guided Abstraction Refinement. CAV’2000 Ball, Majumdar, Millstein, Rajamani. Automatic Predicate Abstraction of C Programs. PLDI'01 …

4 P   S P   S’ Relax the specification (but to what?) Alternatively… Cousot, Cousot, Fahndrich, and Logozzo. Automatic Inference of Necessary Preconditions. VMCAI’13 Henzinger, Kirsch, Payer, Sezgin, Sokolova. Quantitative relaxation of concurrent data structures. POPL’13

5 P’   S Change the program Alternatively… P   S Logozzo, Ball. Modular and Verified Automatic Program Repair, OOPSLA'12 …

Focus on Program Modification  Given a program P, specification S, and an abstraction  such that P   S  Find a modified program P’ such that P’   S  Hard in general  Some hope  Equivalent programs  e.g., semantic preserving compiler transformations  Restricted programs  Changing a program to add new legal behaviors is hard  Removing behaviors potentially easier  Program restriction natural in concurrent programs  Reducing permitted schedules 6

Restriction of Concurrent Programs  Restrict permitted schedules by adding synchronization  Atomic sections  Barriers  Memory fences  Conditional critical region (CCR) .... 7

Example: Correct and Efficient Synchronization with Atomic Sections  Boids simulation  Craig Reynolds,"Flocks, herds and schools: A distributed behavioral model.", SIGGRAPH '87  Sequential implementation by Paul Richmond (U. of Sheffield)Paul Richmond 8 … Global state contains shared array of Boid locations N Boids

Boid Task 9 … Read locations of other boids … Update my location Specification (for now): guarantee conflict-freedom Conflict: two threads are enabled to access the same memory location and (at least) one of these accesses is a write Boid task pid=2 pid=2 … Read locations of other boids … Update my location Boid task pid=3

Boids Simulation 10 atomic … Generate initial locations Spawn N Boid Tasks While (true) { Read locations of all boids Render boids } atomic While (true) { Read locations of other boids Compute new location Update my location } Main taskBoid task Shared Memory (Global State) Locations of N Boids

Challenge  Find minimal synchronization that makes the program satisfy the specification  Avoid all bad schedules while permitting as many good schedules as possible  Assumption: we can prove that serial executions satisfy the specification  Interested in bad behaviors due to concurrency  Handle infinite-state programs 11

Abstraction-Guided Synthesis of Synchronization  Synthesis of synchronization via abstract interpretation  Compute over-approximation of all possible program executions  Add minimal synchronization to avoid (over-approximation of) bad schedules  Interplay between abstraction and synchronization  Finer abstraction may enable finer synchronization  Coarse synchronization may allow coarser abstraction 12

Change the abstraction to match the program A Standard Approach: Abstraction Refinement Program P Specification S Abstract counter example Abstraction  Abstraction Refinement  Abstract counter example Verify Valid 13

Program P Abstract counter example Abstraction Refinement Change the program to match the abstraction   Verify Abstraction-Guided Synthesis [VYY-POPL’10] Program Restriction Implement P’ Abstract counter example 14 Specification S Abstraction 

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

Avoid and Implement  Desired output – program satisfying the spec  Constraint has to be implementable in the program  Implementation mechanism guides the choice of constraint language  Implementation mechanisms  Atomic sections [POPL’10]  Conditional critical regions (CCRs) [TACAS’09]  Memory fences (for relaxed memory models) [FMCAD’10 + PLDI’11]  Barriers  … 16

Avoiding a schedule with atomic sections  Adding atomicity constraints  Atomicity predicate [l1,l2] –statements at l1 and l2 must execute together atomically  avoid(  )  A disjunction of all possible atomicity predicates that would prevent   Captures all ways to avoid  using atomic sections 17 avoid(  ) =  { [label(  i ),label(  j )] | 0  i i + 1. tid(  i ) = tid(  j ) s.t.  k.i < k < j, tid(  i )  tid(  k ) }

Avoid with atomicity constraints 18 1,1 2,1 3,1 A1 A2 2,2 B1 1,2 B1 2,33,2 B1 3,3 B2 A2 A1 1,3 B2 A2B2 A1 Thread A 1: A1 2: A2 Thread B 1: B1 2: B2  = A 1 B 1 A 2 B 2 avoid(  ) = [A 1,A 2 ]  [B 1,B 2 ]

Avoiding the good with the bad   = avoid(  )  Enforcing  avoids any abstract trace  ’ such that  ’    Potentially avoiding “good traces” as well 19 A1B1A2A3 11 11 A1B1A2A3 22 22 avoid(  1) = [A1,A2]

Simple Example  Initially x = z = 0  Every single statement is atomic 20 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 } atomic

Example: Concrete Values y2 y1 1 Concrete values 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 } x += z; x += z; z++;z++;y1=f(x);y2=x;assert  y1=5,y2=0 z++; x+=z; y1=f(x); z++; x+=z; y2=x;assert  y1=3,y2=3 … 21

Example: Parity Abstraction y2 y1 1 Concrete values 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 } x += z; x += z; z++;z++;y1=f(x);y2=x;assert  y1=Odd,y2=Even y2 y1 1 Parity abstraction (even/odd) 22 abstract y1,y2 using parity abstraction (x,z remain concrete)

Example: Avoiding Bad Interleavings avoid(  1 ) = [z++,z++]  = [z++,z++]  = true while(true) { BadTraces={  |  (  P       ) and   S } if (BadTraces is empty) return implement(P,  ) select   BadTraces if (?) {  =   avoid(  ) } else {  = refine( ,  ) } 23 z++ T1 x+=z T3 y1=f(x) y2=x Showing only states leading to bad states

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

Example: Avoiding Bad Interleavings 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] 25  = true while(true) { BadTraces={  |  (  P       ) and   S } if (BadTraces is empty) return implement(P,  ) select   BadTraces if (?) {  =   avoid(  ) } else {  = refine( ,  ) }

y2 y1 1 parity  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 T3 x+=z; x+=z z++; y1=f(x) y2=x assert y1!= y2 T1 T2 T3 Example: Avoiding Bad Interleavings But we can also change the abstraction… 26

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 27

Multiple Solutions  Interval abstraction for our example produces the atomicity constraint: ([x+=z,x+=z] ∨ [z++,z++]) ∧ ([y1=f(x),y2=x] ∨ [x+=z,x+=z] ∨ [z++,z++])  Performance: smallest atomic sections  Minimal satisfying assignments   1 = [z++,z++]   2 = [x+=z,x+=z] 28

Input: Program P, Specification S, Abstraction  Output: Program P’ satisfying S under  ’  = true while(true) { BadTraces = {  |   (  P       ) and   S } if (BadTraces is empty) return implement(P,  ) select   BadTraces if (?) {  = avoid(  ) if (   false)  =    else abort } else {  ’ = refine( ,  ) if (  ’   )  =  ’ else abort } Choosing between abstraction refinement and program restriction - not always possible to refine/avoid - may try and backtrack AGS Algorithm – More Details Forward Abstract Interpretation, taking  into account for pruning infeasible interleavings Backward exploration of invalid interleavings using  to prune infeasible interleavings. Order of selection matters Implements the constraint in the program – can be tricky due to syntax of the language 29

Implementability  No program transformations (e.g., loop unrolling)  Memoryless strategy T1 1: while(*) { 2: x++ 3: x++ 4: } T2 1: assert (x != 1)  Separation between schedule constraints and how they are realized  Can realize in program: atomic sections, locks,…  Can realize in scheduler: benevolent scheduler 30

Program P Abstract counter example Abstraction Refinement   Verify Abstraction-Guided Synthesis Program Restriction Implement P’ Abstract counter example 31 Specification S Abstraction 

AGS instances AvoidImplementation Mechanism Abstraction Space (examples) Reference Context switchAtomic sectionsNumerical abstractions[POPL’10] Inter-thread ordering Synchronization barriers Numerical abstractions[in progress] Intra-thread ordering Memory fencesPartial-Coherence abstractions for store buffers [FMCAD’10] [PLDI’11] [PLDI’12] TransitionConditional critical regions (CCRs) Observability[TACAS’09] … 32

Inter-thread Ordering  Focus: programs where threads access mostly disjoint parts of memory  Deterministic programming, GPUs, …  Enforce ordering between operations across threads 33 Abstractioncombines points-to information with numerical information to track potentially conflicting memory accesses AvoidEnforce order between conflicting transitions of different threads A1 < B1  B1 < A1 Implementsignal/wait and barriers NuancesThread-modular synthesis

Example 34 A 1: x=0 2: y=0 B 1: x=1 2: if (x==0) y=1 x=0;y=0;x=1;if(x==0) y=1  (x=1,y=0) x=1; x=0;if(x==0) y=1; y=0  (x=0,y=0) Would like to enforce an order for every pair of conflicting accesses

Compute Stable Invariants 35 1,0,0 2,0,0 3,0,0 x=0 y=0 1,0,0 2,1,0 3,0,0 x=1 If(x==0) y=1 A 1: x=0 2: y=0 B 1: x=1 2: if (x==0) y=1 1,0,0 2,{0,1},{0,1} 3,{0,1},{0,1} x=0 y=0 1,0,0 2,{0,1},0 3,{0,1},{0,1} x=1 If(x==0) y=1 (Mine, Static analysis of run-time errors in embedded critical parallel C programs. ESOP’11)

Identify Conflicts  Pair matching states, check for conflicts  Transitions t1, t2 are conflicting when tid(t1)  tid(t2), src(t1)=src(t2) and accessed(t1)  written(t2)   or accessed(t2)  written(t1)    Restrict order of statements from different threads 36 1,0,0 2,{0,1},{0,1} 3,{0,1},{0,1} A1: x=0 A2: y=0 1,0,0 2,{0,1},0 3,{0,1},{0,1} B1: x=1 B2: If(x==0) y=1 1|1,0,0 t1 A1: x=0 t2 B1: x=1 written(t1) = { x } accessed(t1)= { x } written(t2) = { x } accessed(t2)= { x } resolve(t1,t2) = A1 < B1  B1 < A1

Realizing the Solutions 37 NumSatisfied TermsReduced Terms 1A1<B1, A1<B2, A2<B2A1<B1, A2<B2 2B1<A1, A1<B2, A2<B2B1<A1, A2<B2 5A1<B1, A1<B2, B2<A2A1<B1, B2<A2 A1: x=0 A2: y=0 B1: x=1 B2: if (x==0) y=1 2 spawn { o1.wait(); A1: x=0 A2: y=0 o2.signal() } spawn { B1: x=1 o1.signal() o2.wait() B2: if (x==0) y=1 }  = (A1 < B1  B1 < A1)  (A1 < B2  B2 < A1)  (A2 < B2  B2 < A2) Eliminated deadlocking/redundant solutions

In reality… 1 void update(double[] B, double[] C) { 2 spawn { 3 for (int i=1;i <=n; i++) { 4 int ci = 2*i; 5 double t1 = C[ci]; {R:({AC},{2 ≤ ci ≤ 2*n})} 6 B[i] = t1; {W:({AB},{1 ≤ i ≤ n})} 7 } 8 } 9 spawn { 10 for (int j=n;j <=2*n; j++) { 11 int cj = 2*j+1; 12 double t2 = C[cj]; {R:({AC},{2*n+1 ≤ cj ≤ 4*n+1})} 13 B[j] = t2; {W:({AB},{n ≤ j ≤ 2*n})} 14 } 15 } 16} 38

39 … B C … 4*n+1 2*n0 0 2*i … n i,j … 2*j+1 pc(1) = 6, pc(2) = 13 … B C … 4*n+1 2*n 0 0 … n j … 2*j+1 pc(2) = 13 … B C … 4*n+1 2*n0 0 i 2*i … n … pc(1) = 6 B C{ 2*n+1 <= idx <= 4*n+1 } { n <= idx <= 2*n } pc(2) = 13 B C { 2 <= idx <= 2*n } { 1 <= idx <= n } pc(1) = 6 2 spawn { … 6 B[i] = t1; { W:({AB},{1 ≤ i ≤ n})} … } 9 spawn { … 13 B[j] = t2; {W:({AB},{n ≤ j ≤ 2*n})} … } Concrete Cartesian Abstract Numerical

Experimental Results 40 ProgramDescriptionLOCOctagonPolyhedra CRYPTIDEA encryption249  MOLDYNMolecular dynamics simulation579  SORSuccessive over-relaxation119  LUFACTLU Factorization265  SERIESFourier coefficient analysis228  SPARSESparse matrix multiplication93 

Intra-Thread Ordering  Relaxed ordering due to relaxed memory models  Enforce ordering between operations of the same thread 41 AbstractionNew family of abstract memory models (partial-coherence abstraction) AvoidOrdering constraints A1 < A2 – a fence is required on all paths between A1 to A2 ImplementMemory fence NuancesSynthesizer works on state-based semantics

Store Buffers 42 … A Main Memory … B … … X Y X Y Processor B B 1 : R2 = Y B 2 : R1 = X Processor A A 1 : X = 1 A 2 : Y = 1

Abstract Memory Models - Requirements  Bounded over-approximation of potentially unbounded buffers  Intra-process coherence: a process should see the most recent value it wrote  Preserve fence semantics  Partial inter-process coherence: preserve as much order information as feasible (bounded)  Enable strong flushes 43

Partial Coherence Abstractions 44 … A Main Memory … B … … X Y X Y A Main Memory B X X Y Recent value Bounded length k Unordered elements Y Allows precise fence semantics Allows precise loads from buffer Keeps the analysis precise for “normal” programs Fallback for soundness

Avoidable Transitions 45  Constraint language  Must be syntactically enforceable with fences  Determines which transitions are avoidable P 2 : (D) LOAD R1 = X P 1 : (D) LOAD R1 = X P1:P1: P2:P2: 123 ABC X X P1:P1: P2:P2: 123 ABC X X P1:P1: P2:P2: 123 ABC X X P1:P1: P2:P2: 123 ABC X X Unavoidable [A < D]  [B < D]  [C < D]

Implement: Memory Fences 46 Processor B B 1 : R2 = Y fence(“load-load”) B 2 : R1 = X Processor A A 1 : X = 1 fence(“store-store”) A 2 : Y = 1 A1 < A2  B1 < B2  Not always that simple  Transitive dependencies  Control structure, loops

Inference Results 47  Mostly mutual exclusion primitives  Different variations of the abstraction ProgramPD k=0 PD k=1 PD k=2 FD k=0 FD k=1 Sense0   Pet0  Dek0  Lam0  T/O Fast0  T/O Fast1a   Fast1b    Fast1c   T/O

Back to Boids  With synchronization barriers  Numerical abstractions for tracking array indices  Establishing conflict-freedom of array accesses that may happen in parallel  Computing forces can be done in parallel  Different Boids write to disjoint parts of the array 48

Boids Simulation 49 … Generate initial locations Spawn N Boid Tasks While (true) { Wait on display-barrier Read locations of all boids Render boids } While (true) { Read locations of other boids Wait on message-barrier Compute new location Update my location Wait on display-barrier } Main taskBoid task Shared Memory (Global State) Locations of N Boids

Program P specification S Abstract counter example Abstraction  Abstraction Refinement Change the specification to match the abstraction   Verify General Setting Revisited Program Restriction Implement P’ Abstract counter example S’ Spec Weakening  50

Summary  An algorithm for Abstraction-Guided Synthesis  Synthesize efficient and correct synchronization  Handles infinite-state systems based on abstract interpretation  Refine the abstraction and/or restrict program behavior  Interplay between abstraction and synchronization  Instances  Atomic sections  Barriers  Memory fences  Useful in practice for systematic exploration of design spaces 51

Invited Questions 1. What about other synchronization mechanisms? 2. Title says “abstraction-guided synthesis” but you only talked about synthesis of synchronization, is there anything for sequential programs? 3. Why not start from the most constrained program and work downwards (relaxing constraints)? 4. Can’t you solve the problem purely by brute force search of all atomic section / fence / barrier placements? 5. Why are you enumerating traces? Can’t you compute your solution via state-based semantics? 6. Why use only a single CEX at a time? Could use information about the whole (abstract) transition system? 7. How is this related to supervisor synthesis? Games? 8. You add synchronization, can’t you crate deadlocks? 9. Is there any sense in doing something like AGS dynamically? 10. Don’t you always want to use the most refined abstraction and generate synchronization only using that? 52