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

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




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


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


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




Memory Fences

(Optional)

High Level Setting

32

Process 1 Process 2 Process 3

High Level Setting

33


High Level Setting

34


High Level Setting

35


Challenge

36


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


CCR Setting

40


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


s1;s2; s5; s7;

s6; s3;s4;


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:


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


Specification:

LE( { x, y, z } )

Cost:


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


Specification:

LE( { x, , z } )

Cost:


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


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


Correct and Maximally Permissive

Example: Limited Observability


(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


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




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



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



: 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



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



+ + ?

+ + ?

? ? ?

x y i

+ + ?

+ + ?

+ + ?

+ + ?

+ + ?

+ + ?

72

Incompleteness


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]






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]






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++;


T1

T2

T3

0 1 2 3

12345

4

6 parity

x+=z;

x+=z z++; z++;


T1

T2

T3

But we can also refine the abstraction…


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++;


T1

T2

T3

x+=z;

x+=z z++; z++;


T1

T2

T3

x+=z;

x+=z z++; z++;


T1

T2

T3

x+=z;

x+=z z++; z++;


T1

T2

T3

x+=z;

x+=z z++; z++;


T1

T2

T3

x+=z;

x+=z z++; z++;


T1

T2

T3

x+=z;

x+=z z++; z++;


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




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/

http://www.podc.org/podc2010/

http://www.cse.psu.edu/popl/10/

http://ti.arc.nasa.gov/event/spin09/

http://www.embedded.rwth-aachen.de/tacas2009/

http://ties.ucsd.edu/PLDI/

http://ties.ucsd.edu/PLDI/

http://research.microsoft.com/conferences/pldi06/

Thanks

Documents

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