Post on 04-Jan-2016
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 InferCorrect 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 2000
2 errors in < 20 lines of code !
Concurrent Data Structures
Existing Approaches for Concurrent Object Construction
Performance
ManualEffort
Sequential
NaïveSTM
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 <r,m> = 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 Setsbool 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
lessatomic
moreatomic
Generate-Verify
Atomicity Reduction: Steps
Removing redundant atomicity
Reordering
statements
Optimistic concurrency
Add synchronization
meta-data18
s1s2
s3s4
s1s2
s3s4
If (validate) updateelse restart
read
s1s2
s3s4
s2s1
s3s4
s3s4
readupdate
s1s2
s1If (t > 0) s2
s3s4
19
Concurrent Sets: Generate-Check
Schema
Correct Algorithm
DCAS
Sequential
DCAS CAS CASwith 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 correctcompletion 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
- 1 5 9
head tail
pred curr r
pred curr
T1: remove(5) T2: add(7)||
Step 2: Counterexample
23
- 1
5
9
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
key next key next 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 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
- 1 9
head tail
pred curr r
pred curr
T1: remove(5) T2: add(7)||
Fixed Previous Counterexample
add(7) observes pred “5” is marked and restarts
pred curr
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 <r,m> = 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 1 Process 2 Process 3
High Level Setting
33
Process 1 Process 2 Process 3
High Level Setting
34
Process 1 Process 2 Process 3
High Level Setting
35
Process 1 Process 2 Process 3
Challenge
36
Process 1 Process 2 Process 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 1 Process 2 Process 3
CCR Setting
40
Process 1 Process 2 Process 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 1 Process 2 Process 3
s1;s2; s5; s7;
s6; s3;s4;
Process 1 Process 2 Process 3
g1 s1;s2; s5; g2s7;
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 = < 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)
}
}
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,s0,0,0
X Y Z
PC1PC2
PC3
Build Transition Systems,s,s0,0,0
e,s,s1,0,0
s,e,s0,1,0
s,s,e0,0,1
e,e,s1,2,0
e,s,e1,0,1
e,e,s1,1,0
s,e,e0,1,2
e,s,e2,0,1
s,e,e0,1,1
e,e,e1,2,3
e,e,e1,2,1
e,e,e1,1,2
e,e,e3,1,2
e,e,e,2,3,1
e,e,e2,1,1
x=z+1 y=x+1 z=y+1
y=x+1
y=x+1z=y+1
z=y+1
x=z+1
z=y+1
z=y+1
x=z+1
x=z+1
x=z+1
y=x+1
y=x+1
49
Select Transitions to Removes,s,s0,0,0
e,s,s1,0,0
s,e,s0,1,0
s,s,e0,0,1
e,e,s1,2,0
e,s,e1,0,1
e,e,s1,1,0
s,e,e0,1,2
e,s,e2,0,1
s,e,e0,1,1
e,e,e1,2,3
e,e,e1,2,1
e,e,e1,1,2
e,e,e3,1,2
e,e,e,2,3,1
e,e,e2,1,1
x=z+1 y=x+1 z=y+1
y=x+1
y=x+1z=y+1
z=y+1
x=z+1
z=y+1
z=y+1
x=z+1
x=z+1
x=z+1
y=x+1
y=x+1
50
s,s,s0,0,0
e,s,s1,0,0
s,e,s0,1,0
s,s,e0,0,1
e,e,s1,2,0
e,e,s1,1,0
s,e,e0,1,2
e,s,e2,0,1
s,e,e0,1,1
e,e,e1,2,3
e,e,e1,1,2
e,e,e3,1,2
e,e,e,2,3,1
e,e,e2,1,1
x=z+1 y=x+1 z=y+1
y=x+1
z=y+1
x=z+1
z=y+1
z=y+1
x=z+1
x=z+1
x=z+1
y=x+1
y=x+1
51
e,s,e1,0,1
e,e,e1,2,1
y=x+1
z=y+1
Build Transition System
x!=1 || y!=0 || z!=0
x!=1 || y!=0 || z!=0
x!=1 || y!=0 || z!=0
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,s0,0,0
e,s,s1,0,0
s,e,s0,1,0
s,s,e0,0,1
e,e,s1,2,0
e,s,e1,0,1
e,e,s1,1,0
s,e,e0,1,2
e,s,e2,0,1
s,e,e0,1,1
e,e,e1,2,3
e,e,e1,2,1
e,e,e1,1,2
e,e,e3,1,2
e,e,e,2,3,1
e,e,e2,1,1
x=z+1 y=x+1 z=y+1
y=x+1
y=x+1z=y+1
z=y+1
x=z+1
z=y+1
z=y+1
x=z+1
x=z+1
x=z+1
y=x+1
y=x+1
54
Build Transition System
Build Transition Systems,s,s0,0,0
e,s,s1,0,0
s,e,s0,1,0
s,s,e0,0,1
e,e,s1,2,0
e,s,e1,0,1
e,e,s1,1,0
s,e,e0,1,2
e,s,e2,0,1
s,e,e0,1,1
e,e,e1,2,3
e,e,e1,2,1
e,e,e1,1,2
e,e,e3,1,2
e,e,e,2,3,1
e,e,e2,1,1
x=z+1 y=x+1 z=y+1
y=x+1
y=x+1z=y+1
z=y+1
x=z+1
z=y+1
z=y+1
x=z+1
x=z+1
x=z+1
y=x+1
y=x+1
55
Select transition to removes,s,s0,0,0
e,s,s1,0,0
s,e,s0,1,0
s,s,e0,0,1
e,e,s1,2,0
e,s,e1,0,1
e,e,s1,1,0
s,e,e0,1,2
e,s,e2,0,1
s,e,e0,1,1
e,e,e1,2,3
e,e,e1,2,1
e,e,e1,1,2
e,e,e3,1,2
e,e,e,2,3,1
e,e,e2,1,1
x=z+1 y=x+1 z=y+1
y=x+1
y=x+1z=y+1
z=y+1
x=z+1
z=y+1
z=y+1
x=z+1
x=z+1
x=z+1
y=x+1
y=x+1
56
s,s,s0,0,0
e,s,s1,0,0
s,e,s0,1,0
s,s,e0,0,1
e,e,s1,2,0
e,s,e1,0,1
e,e,s1,1,0
s,e,e0,1,2
e,s,e2,0,1
s,e,e0,1,1
e,e,e1,2,3
e,e,e1,2,1
e,e,e1,1,2
e,e,e3,1,2
e,e,e,2,3,1
e,e,e2,1,1
x=z+1 y=x+1 z=y+1
y=x+1
y=x+1z=y+1
z=y+1
x=z+1
z=y+1
z=y+1
x=z+1
x=z+1
x=z+1
y=x+1
y=x+1
57
Select All Equivalent Transitions
• Implementability
s,s,s0,0,0
e,s,s1,0,0
s,e,s0,1,0
s,s,e0,0,1
s,e,e0,1,2
e,s,e2,0,1
s,e,e0,1,1
e,e,e3,1,2
e,e,e,2,3,1
e,e,e2,1,1
x=z+1 y=x+1 z=y+1
y=x+1
x=z+1
z=y+1
x=z+1
x=z+1
x=z+1
y=x+1
y=x+1
58• Stuck states
e,e,s1,2,0
e,s,e1,0,1
e,e,s1,1,0
e,e,e1,2,3
e,e,e1,2,1
e,e,e1,1,2
y=x+1z=y+1 z=y+1x!=1 || z!=0
x!=1 || z!=0 z=y+1
x!=1 || z!=0
x!=1 || z!=0
Build Transition System
s,s,s0,0,0
e,s,s1,0,0
s,e,s0,1,0
s,s,e0,0,1
s,e,e0,1,2
e,s,e2,0,1
s,e,e0,1,1
e,e,e3,1,2
e,e,e,2,3,1
e,e,e2,1,1
x=z+1 y=x+1 z=y+1
y=x+1
x=z+1
z=y+1
x=z+1
x=z+1
x=z+1
y=x+1
y=x+1
59
e,e,s1,2,0
e,s,e1,0,1
e,e,s1,1,0
e,e,e1,2,3
e,e,e1,2,1
e,e,e1,1,2
y=x+1z=y+1 z=y+1x!=1 || z!=0
x!=1 || z!=0 z=y+1
x!=1 || z!=0
x!=1 || z!=0
Select transitions to remove
s,s,s0,0,0
e,s,s1,0,0
s,e,s0,1,0
s,s,e0,0,1
e,e,31,2,0
e,2,e1,0,1
e,e,31,1,0
s,e,e0,1,2
e,s,e2,0,1
s,e,e0,1,1
e,e,e1,2,3
e,e,e1,2,1
e,e,e1,1,2
e,e,e3,1,2
e,e,e,2,3,1
e,e,e2,1,1
x=z+1 y=x+1 z=y+1
y=x+1
y=x+1z=y+1
z=y+1
x=z+1
z=y+1
z=y+1
x=z+1
x=z+1
x=z+1
y=x+1
y=x+1
x!=1 || z!=0
x!=1 || z!=0
x!=1 || z!=0
x!=1 || z!=0
x!=0 || z!=0
x!=0 || z!=0
x!=0 || 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 undecidablegood 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
Recipe1) Abstraction2) Transformers3) 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, -, ?}
x y i
3 1 7 x y i
+ + +
3 2 6
x y i
… 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}
x y i
+ + 0
x y i
3 1 0y = y + 1
x y i
3 2 0
x y i
+ + 0
y = y + 1
+ - 0 + ? 0
+ 0 0 + + 0
+ ? 0 + ? 071
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;
do { y = y - 2; y = y + 3; } while(--i > 0) assert 0 < x + y}
+ ? ?
+ ? ?
x y i
+ ? ?
+ + ?
? ? ?
x y i
+ ? ?
+ ? ?
+ ? ?
73
ConcurrentProgram
Specification Abstraction
Abstract Interpreter
Refine
Counter Example
Change the abstraction to match the program
Automatic Verification with Abstraction
ConcurrentProgram
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() = [A1,A2] [B1,B2]
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
0 2 3
12345
4
6
y2
y1
1
Concrete values
0 2 3
12345
4
6
y2
y1
1
Parity abstraction (even/odd)
avoid(1) = [z++,z++]
= [z++,z++] = true
= 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
0 2 3
12345
4
6
y2
y1
1
parity
0 1 2 3
12345
4
6 parity
x+=z;
x+=z z++; z++;
y1=f(x)y2=xassert y1!= y2
T1
T2
T3
x+=z;
x+=z z++; z++;
y1=f(x)y2=xassert y1!= y2
T1
T2
T3
0 1 2 3
12345
4
6 parity
x+=z;
x+=z z++; z++;
y1=f(x)y2=xassert y1!= y2
T1
T2
T3
But we can also refine the abstraction…
Example: Avoiding Bad Traces
0 2 3
12345
4
6
y2
y1
1
0 1 2 3
12345
4
6
0 1 2 3
12345
4
6
parity
interval
octagon
0 1 2 3
12345
4
6
0 1 2 3
12345
4
6
0 1 2 3
12345
4
6
0 1 2 3
12345
4
6
(a) (b) (c)
(d) (e)
(f) (g)
parity parity
interval
octagon
x+=z;
x+=z z++; z++;
y1=f(x)y2=xassert y1!= y2
T1
T2
T3
x+=z;
x+=z z++; z++;
y1=f(x)y2=xassert y1!= y2
T1
T2
T3
x+=z;
x+=z z++; z++;
y1=f(x)y2=xassert y1!= y2
T1
T2
T3
x+=z;
x+=z z++; z++;
y1=f(x)y2=xassert y1!= y2
T1
T2
T3
x+=z;
x+=z z++; z++;
y1=f(x)y2=xassert y1!= y2
T1
T2
T3
x+=z;
x+=z z++; z++;
y1=f(x)y2=xassert y1!= y2
T1
T2
T3
x+=z;
x+=z z++; z++;
y1=f(x)y2=xassert 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
Program Refine Steps Avoid Steps
Double buffering 1 2
Defragmentation 1 8
3D array update 2 23
Array Removal 1 17
Array Init 1 56
• 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 HindsightO'Hearn P., Rinetzky N., Vechev M., Yahav E., Yorsh G.PODC '10: Symposium on Principles of Distributed Computing
• Abstraction-Guided SynthesisVechev M., Yahav E., Yorsh G.POPL '10: 37th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages
• Experience with Model Checking LinearizabilityVechev M., Yahav E., Yorsh G. SPIN '09: 16th International SPIN Workshop on Model Checking of Software
• Inferring Synchronization Under Limited ObservabilityVechev M., Yahav E., Yorsh G. TACAS '09: 15th International Conference on Tools and Algorithms for the Construction and Analysis of Systems
• Deriving Linearizable Fine-Grained Concurrent ObjectsVechev M., Yahav EPLDI '08: ACM SIGPLAN 2008 Conference on Programming Language Design and Implementation.
• CGCExplorer: A Semi-Automated Search Procedure for Provably Correct Concurrent CollectorsVechev 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 AlgorithmsVechev M., Yahav E., and Bacon D.F. PLDI '06: ACM SIGPLAN 2006 Conference on Programming Language Design and Implementation.
90
http://www.research.ibm.com/paraglide/
Thanks