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
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. 2. - PowerPoint PPT Presentation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Reduction, abstraction, and atomicity:
How much can we prove about concurrent programs using them?
Serdar TasiranKoç University
Istanbul, Turkey
Tayfun Elmas Shaz Qadeer Ali Sezgin Koç University Microsoft Research Koç University
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;
x := x + 1;
assert (x == 2)
12
Rule 1: Strengthen invariant
I,P I’,P
I’ I
• All statements in P must preserve I’.
13
Rule 2: Abstract program
I,P I,P’
• P’ : Atomic statement [ S ] in P replaced with [ S’ ]
• Atomic statement [S’] abstracts statement [S]
14
15
Abstracting Actions
If for all :
errors1 errors11. If then
s12. If thens2 s1 s2
or errors1
s1
– 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;x := t + 1;
16
Rule 3: Reduce program
[ S1; S2]
[ S1 ; S2 ]
[ S1 ] ; [ S2 ]
[ S1 ] || [ S2 ]
I,P I,P’
17
S1 S2 S3acquire y
S1 T2 S3acquirey
S1 T2 S3release x
S1 S2 S3releasex
Right and left movers (Lipton 1975)18
19
Static mover check
• Right mover: Commutes to the right of any other actionrun 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 s1 executes followed by
• Do not need to do mover check for state pairs starting with s1
s1 errors1
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
Dischargesthe 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.