Reduction, abstraction, and atomicity: How much can we prove about concurrent programs using them? Serdar Tasiran Koç University Istanbul, Turkey Tayfun Elmas Shaz Qadeer Ali Sezgin Koç University Microsoft Research Koç University Istanbul, Turkey Redmond, WA Istanbul, Turkey

Outline QED proof system (Cartoon illustration) QED overview Half-baked part: Backward reasoning in time Prophecy variables, “tressa” annotations 2 2

3 Example: increment acquire (lock); t1 := x; t1:= t1 + 1; x := t1; release (lock); x := 0; || assert (x == 2); acquire (lock); t2 := x; t2 := t2 + 1; x := t2; release (lock); 3

4 Proof with “fine grain” actions A: x=0, L0: acquire(l); x=0, held(l,A)> L1: t1 := x; x=0, held(l,A), t1=x> L2: t1 := t1 + 1; x=0, held(l,A), t1=x+1> L3: x := t1; x=1, held(l,A)> L4: release(l) x=1, B: x=0, L0: acquire(l); x=0, held(l,B)> L1: t2 := x; x=0, held(l,B), t2=x> L2: t2 := t2 + 1; x=0, held(l,B), t2=x+1> L3: x := t2; x=1, held(l,B)> L4: release(l) x=1, || 4

5 QED Proof of Increment (Cartoon 1) inc (): acquire (lock); t1 := x; t1 := t1 + 1; x := t1; release(lock); Right mover Both mover B B Left mover inc (): acquire (lock); t1 := x; t1 := t1 + 1; x := t1; release(lock); inc (): x := x + 1; REDUCE-SEQUENTIAL 5

6 QED Proof of “increment” (Cartoon 2) Main: x := 0; inc() || inc() assert (x == 2) Main: x := 0; x := x + 1 || x := x + 1 assert (x == 2) B B INLINE-CALL REDUCE-PARALLEL Main: x := 0; x := x + 1; assert (x == 2) 6

The QED approach Soundness theorem: Starting from a state s i in I n P 1 has an assertion violation  P n has an assertion violation P 1 can go to final state s f  P n can go to final state s f or has an assertion violation. Difficult to prove Fine-grain concurrency Annotations at every interleaving point Easy to prove Larger atomic blocks Local, sequential analysis within atomic blocks 7 (P 1, I 1 ) ...  (P i, I i ) ...  (P n, I n ) ProgramInvariant 7

Outline QED idea QED overview Half-baked part: Backward reasoning in time Prophecy variables, “tressa” annotations 8 8

Programs Syntax: Gated action 9 S ::= assume e | assert e | x := e | havoc x | S ; S | if (e) then S else S | while (e) do S | proc(a, out b) | S || S | [ S ] Syntax in code examples: Semantics: A collection of threads and a global store Non-deterministically pick a thread and execute one atomic step Failed assert makes the thread and program go wrong A distinguished state “error” Failed assume blocks the executing thread

10 Gated actions x = x + 1; Transition: Two-store relation Gate: Assertion on pre-state 10

11 Gated actions – examples assert (x != 0); y = y / x; x = x + 1; assert (x != 0); y = y / x; assume (x != 0); y = y / x; Transition: Two-store relation Gate: Assertion on pre-state 11

12 Verifying the program Proof succeeds when all executions of starting from states in satisfy all assertions. Sufficient condition: For all actions in the program, Actions “large enough” to establish assertions within themselves x := 0; x := x + 1; assert (x == 2) 12

Rule 1: Strengthen invariant I,PI’,P I’  I All statements in P must preserve I’. 13

Rule 2: Abstract program I,PI,P’ P’ : Atomic statement [ S ] in P replaced with [ S’ ] Atomic statement [S’] abstracts statement [S] 14

15 Abstracting Actions  If for all : error s1s1 s1s1 1. If then s1s1 2. If then s2s2 s1s1 s2s2 or error s1s1 s1s1      –Going wrong more often is sound for assertion checking abstracted by 15

16 Flavors of Abstraction if (x == 1) y := y + 1; if ( * ) y := y + 1; Adding non-determinism Adding assertions t := x; havoc t; assume x != t; skip; assert (lock_owner == tid); x := t + 1; 16

Rule 3: Reduce program [ S1; S2] [ S1 ] ; [ S2 ] [ S1 ] || [ S2 ] I,PI,P’ 17

S1S1 S2S2 S3S3 acquirey S1S1 T2T2 S3S3 y S1S1 T2T2 S3S3 releasex S1S1 S2S2 S3S3 x Right and left movers (Lipton 1975) 18

19 Static mover check Right mover: Commutes to the right of any other action run by a different thread Static right-mover check for  : For every action  in program: (run by different thread)     19

20 Static mover check Static right-mover check between  and  : Simple cases –Mover check passes:  and  access different variables  and  disable each other –Fails:  writes to a variable and  reads it  and  both write to a variable, writes do not commute   20

21 Reduction  ;  ;  ...   1   2 ...   n   ;  ...  right-mover: For each execution: Exist equivalent executions:...     1   2 ...   n      1     2 ...   n      1   2 ...     n   ...  ;  21

22 Static mover check: a subtlety Static right-mover check between  and  : Consider such that No execution reaching s 1 executes  followed by  Do not need to do mover check for state pairs starting with s 1   s1s1 error s1s1  22

23 Increment: Proof by reduction acquire (lock); t1 := x; t1 := t1 + 1; x := t1; release(lock); R B B B L acquire (lock); t1 := x; t1 := t1 + 1; x := t1; release(lock); REDUCE-SEQUENTIAL 23

24 Static mover check fails: Apparent conflict acquire (lock); t1 := x; t1 := t1 + 1; x := t1; release(lock); acquire (lock); t2 := x; t2 := t2 + 1; x := t2; release(lock); Static mover check is local, fails! Individual actions do not locally contain the information: “Whenever this action executes, this thread holds the lock” Annotate action with local assertion: Express belief about non-interference 24

25 Auxiliary variable: Which thread holds the lock? inc (): acquire (lock); t1 = x; t1 = t1 + 1 x = t1; release(lock); inc (): acquire (lock); a := tid; t2 = x; t2 = t2 + 1 x = t2; release(lock); a := 0; AUX-ANNOTATE New invariant: (lock == true)  (a != 0) Auxiliary variable a is a history variable Summarizes relevant part of execution history 25

26 Annotating Actions with Assertions acquire (lock); a := tid; assert a == tid; t1 = x; t1 = t1+ 1 assert a == tid; x = t1; assert a == tid; release(lock); a := 0; acquire (lock); a := tid; t1= x; t1 = t1 + 1 x = t1; release(lock); a := 0; ABSTRACT Invariant: (lock == true)  (a != 0) Assertions indicate belief about non interference Annotate actions locally with global information about execution 26

History Variable Annotations Make Static Mover Check Pass 27 Thread 1 acquire (lock); a := tid1; assert a == tid1; t1 := x; t1 := t1 + 1 assert a == tid1; x := t1; assert a == tid1; release(lock); a := 0; R B B B L Thread 2 acquire (lock); a := tid2; assert a == tid2; t2 := x; t2 := t2 + 1 assert a == tid2; x := t2; assert a == tid2; release(lock); a := 0; assert a == tid1; x := t1; and assert a == tid2; x := t2; commute α  β β  α Because both α  β and β  α result in assertion violations. 27

28 Borrowing and paying back assertions inc (): acquire (lock); a := tid; assert a == tid; t1 = x; t1 = t1 + 1 assert a == tid; x = t1; assert a == tid; release(lock); a := 0; inc (): acquire (lock); a := tid; assert a == tid; t1 = x; t1 = t1 + 1 assert a == tid; x = t1; assert a == tid; release(lock); a := 0; REDUCE-SEQUENTIAL, DISCHARGE ASSERTIONS R B B B L Discharges the assertions Invariant: (lock == true)  (a != 0) 28

29 : Example: Ruling out apparent interference assert !possiblyInList[t1]; t1.next := n1; assert possiblyInList[p2]; n2 := p2.next; possiblyInList[t] : False when a newly created node assigned to t. Set to true when p.next := t for some p. Remains true afterwards. assert possiblyInList[p2]; n2 := p2.next; assert !possiblyInList[t1]; t1.next := n1;   p2 and t1 refer to the same node: LHS and RHS lead to assertion violations. Otherwise, no conflict. 29

Increment with CAS 30 t1 := x; s1 := CAS(x,t1,t1+1); t2 := x; s2 := CAS(x,t2,t2+1); || havoc t1; s1 := CAS(x,t1,t1+1); [ if (*) { s1:=false; } else { x:=x+1; s1:= true; } ] 30

QED-verified examples Fine-grained locking Linked-list with hand-over-hand locking [Herlihy-Shavit 08] Two-lock queue [Michael-Scott 96] Non-blocking algorithms Bakery [Lamport 74] Non-blocking stack [Treiber 86] Obstruction-free deque [Herlihy et al. 03] Non-blocking stack [Michael 04] Writer mode of non-blocking readers/writer lock [Krieger et al. 93] Non-blocking queue [Michael-Scott 96] Synchronous queue [Scherer-Lea-Scott 06] 31

Outline QED proof system QED overview Half-baked part: Backward reasoning in time Prophecy variables, “tressa” annotations 32

33 Static Reduction Proofs and the Future –Challenge in some QED proofs Different reduction proof needed for different execution futures –Example: Optimistic concurrency Proceed assuming non-interference Abort, undo and/or retry if interference detected ➡ Prophecy variables and backwards reasoning in QED

Example: Funny Set procedure Insert(x: data) returns success: bool; { havoc i; assume 0<=i<n; // Start from arbitrary // array slot cnt := 0; success := false; while ( cnt<n && !success) { if (q[i]==-1) { q[i] := x; success := true; } else if (q[i]== x) { success := true; } else { i := (i+1) mod n; cnt := cnt+1; } } 34

Set Lookup procedure Lookup(x: data) returns found: bool; { found := false; i := 0; while (i<n && !found) { found := (q[i] == x); i := i+1; } return found; } 35

Set Lookup procedure Lookup(x: data) returns found: bool; { [ found := false; i := 0; ] while (*) { [ assume(i<n && !found); found := (q[i] == x); i := i+1; ] } [ return found;] } 36 chk(i,x):

Case 1: Lookup returns false chk(0,x) chk(1,x) chk(2,x)... chk(k-1,x)... chk(n-1,x) 37 chk(i,x): no x in slot q[i] Intuition: chk(i,x) should be a left mover for all i. q[i]:= x may come after chk(i,x) So, chk(i,x) not a right mover. No q[i]:= x can come before chk(i,x) Looks like a left mover.

Case 2: Lookup returns true chk(0,x) chk(1,x) chk(2,x)... chk(k-1,x) q[k] := x chk(k,x) 38 chk(k,x): Slot q[i] has x Cannot be a left-mover Does not commute to the left of q[i]:= x Is a right mover (no deletes) Need all earlier chk(i,x) to be right movers. Dilemma: What is the mover type of chk(i,x) ?

Code Duplication procedure Lookup(x: data) returns found: bool; { [ found := false; i := 0; ] while (*) { chkL(i,x);// Left // mover } assume !found; [ return found;] } 39 { [ found := false; i := 0; ] while (*) { chkR(i,x);// Right // mover } assume found; [ return found;] } ☐

Failing Lookup: chk(i,x) 40 assume(q[i]==-1); q[i]:= y; found := (q[i] == x); is not simulated by then From an initial state with q[i] == -1 and y == x –LHS yields found == true –RHS yields found == false chkL(i,x): is not a left mover. –Annotate chkL to say “I am part of a failing execution of Lookup.” found := (q[i] == x); assume(q[i]==-1); q[i]:= y; chk(i,x)

Failing Lookup: chk(i,x) { [ found := false; i := 0; ] while (*) { chkL(i,x);// Left // mover } assume !found; [ return found;] } 41 –We would like to say “This copy of the action only occurs in executions in which found is false.” –[chk(i,x); assert !found;] does not work. –Cannot discharge assertion. –Prefix of execution does not guarantee !found.

tressa: Temporal dual of assert { [ found := false; i := 0; ] while (*) { chkL(i,x);// Left // mover } assume !found; [ return found;] } 42 Postfix of execution justifies !found Code split has produced artificial executions that block when they get to assume !found Annotate chkL(i,x) to say: “Unless !found is true, this is an artificial execution that blocks before Lookup returns.” [ chkL(i,x); tressa(!found);]

tressa (pictorial) semantics Tressa violation in this execution fragment if  (s) is false. 43 …… [ … tressa  ] All future events  refers to have happened. s …

Abstraction and Mover Checks with tressa’s [assert a 1 ; τ 1 ; tressa p 1 ] [assert a 2 ; τ 2 ; tressa p 2 ] Preserve assert violations: a 2 a 1 Preserve tressa violations: p 2 p 1 Forward simulate or replace with assert violation: τ 1 (s,s’) τ 2 (s,s’) ∨ a 2 (s) Backward simulate or replace with tressa violation: τ 1 (s,s’) τ 2 (s,s’) ∨ p 2 (s’) Does α commute to the right of β ? α  β β  α 44

Failing Lookup { [ found := false; i := 0; ] while (*) { chkL(i,x);// Left // mover } assume !found; [ return found;] } 45 { [ found := false; i := 0; ] while (*) { [ chkL(i,x); tressa(!found);] } assume !found; [ return found;] }

Failing Lookup 46 q[i]:= y; found :=(q[i] == x); tressa !found q[i]:= y; simulated by then found :=(q[i] == x); tressa !found In mover checks, can ignore scenarios where, on the LHS the tressa is violated Only worry about (s1,s3) if s3 satisfies !found –Then x != y –Simulation holds! s1 s2 q[i]:= y; found :=(q[i] == x); tressa !found s3

Discharging tressa’s: Backwards Reasoning 47 while (*) { [ chkL(i,x); tressa(!found);] } assume !found; found := \Exists i: 0<=i<n && q[i]==x; tressa(!found); assume !found; tressa’s discharged by backwards reasoning within an atomic block.

Discharging tressa’s: Backwards Reasoning assume ’s are like assignments in the reverse direction in time: [havoc x; x := 2;] A set of transitions (x, x’) where x is arbitrary and x’ is 2. [assume x == 2; havoc x;] A set of transitions (x, x’) where x’ is arbitrary and x is 2. Denoted x =: 2 “Reverse assignment” 48

49 Prophecy Variables acquire (lock); p =: 0 t = x; t = t + 1 x = t; release(lock); p =: tid; acquire (lock); p =: 0 t = x; tressa p == tid; t = t + 1 x = t; tressa p == tid; release(lock); p =: tid; R B B B L

50 Prophecy variables and tressas acquire (lock); p =: 0; t = x; tressa p == tid; t = t + 1 x = t; tressa p == tid; release(lock); p =: tid; acquire (lock); p =: 0 t = x; tressa p == tid; t = t + 1 x = t; tressa p == tid; release(lock); p =: tid; R B B B L

Prophecy Variables Prophecy variable: Auxiliary variable, encodes future non-determinism –Allows actions to refer to future locally –Can use in annotations, abstraction. Different reduction proofs for different futures Concurrent systems: Non-determinism due to thread interleaving 51 p = R, G or B

Prophecy Variable Introduction: Soundness 52 –Annotating action α(s,s’) with prophecy variable p α(s,s’) becomes β(s,p, s’,p’) –Must satisfy p’. p. β(s,p, s’,p’) (History variables: h. h’. β(s,h, s’,h’) ) Backwards assignment satisfies this –Soundness: Every state of every execution can be annotated with a value of p. τ

tressas as partial specifications ReadPair(a: int, b: int) returns (s: bool, da: Obj, db: Obj) { var va: int, vb: int; [va := m[a].v; da := m[a].d; ] [vb := m[b].v; db := m[b].d; ] s := true; tressa ( exit(s) ==> da == m[a].d && db == m[b].d) ); [ if (va < m[a].v) { s:= false; } ] [ if (vb < m[b].v) { s:= false; } ] } // exit(s) =: s when procedure returns. procedure Write(a: int, d: Obj) { [ m[a].d := d; m[a].v := m[a].v+1; ] } 53

tressas + prophecy variables + abstraction ReadPair(a: int, b: int) returns (s: bool, da: Obj, db: Obj) { var va: int, vb: int; [va := m[a].v; da := m[a].d; if (exit(s)) havoc va, da; tressa ( exit(s) ==> va == m[a].v ); ] [vb := m[b].v; db := m[b].d; if (exit(s)) havoc vb, db; tressa ( exit(s) ==> vb == m[b].v ); ] s := true; [ if (va < m[a].v) { s:= false; } ] [ if (vb < m[b].v) { s:= false; } ] } // exit(s) =: s when procedure returns. 54