Verification of Atomicity in Lock Free Programs

18
SAV Course 2007 Verification of Atomicity in Lock Free Programs Presented by: Vasu Singh Paper by: L. Wang and S. Stoller (PPoPP 2005)

description

Verification of Atomicity in Lock Free Programs. Presented by: Vasu Singh Paper by: L. Wang and S. Stoller (PPoPP 2005). Background. Verification in concurrent programs Atomicity Lock free programs. Verifying concurrent programs. - PowerPoint PPT Presentation

Transcript of Verification of Atomicity in Lock Free Programs

Page 1: Verification of Atomicity in Lock Free Programs

SAV Course 2007

Verification of Atomicity in Lock Free Programs

Presented by: Vasu Singh

Paper by: L. Wang and S. Stoller (PPoPP 2005)

Page 2: Verification of Atomicity in Lock Free Programs

SAV Course 2007

Background

• Verification in concurrent programs

• Atomicity

• Lock free programs

Page 3: Verification of Atomicity in Lock Free Programs

SAV Course 2007

Verifying concurrent programs

• Most of the verification techniques in concurrent programming focus on checking race freedom, the property that no variable is accessed by two threads at the same time, where one of the accesses is a write.

• Tools to check data races: Java Pathfinder, Calvin, Spec#, FeaVer, SLAM (Zing) and many more…

Page 4: Verification of Atomicity in Lock Free Programs

SAV Course 2007

Race freedom: a proper correctness property?

• Answer is No!• Well understood by this example:int deposit(int x){ int withdraw(int x){ d1: local b = balance; w1: local b = balance; d2: synchronize(g){ w2: synchronize(g){ d3: balance = b+x; w3: balance = b-x;}} }}Consider the following program (when initially balance =

10).deposit(10); withdraw(10);We consider the execution-> d1, d2, w1, d3, w2, w3.We get the result: balance = 0!

Page 5: Verification of Atomicity in Lock Free Programs

SAV Course 2007

What went wrong?

The deposit() and withdraw() procedures were supposed to execute atomically.

Race freedom cannot ensure atomicity! We say that a procedure is atomic if any

interaction between steps of that procedure and steps of other threads does not change the program’s overall behavior. Similar to notion of serializability for databases.

Page 6: Verification of Atomicity in Lock Free Programs

SAV Course 2007

When is an expression atomic?

• We use Lipton’s theory of reduction.• Based on commuting non-interfering operations

in an execution to obtain an equivalent serial execution.

• An action is right/left mover, if whenever it appears immediately before/after an action from a different thread, the two actions can be swapped without changing the resulting state.

• An expression is reducible if it contains zero or more right movers, followed by atmost one atomic step (that need not commute with other threads), followed by zero or more left movers.

Page 7: Verification of Atomicity in Lock Free Programs

SAV Course 2007

Example of reduction

• acquire(m); x=1; y=2; release(m);• If all threads access variables x and y only when

holding lock on m, the above expression is reducible.

acq(m) x=1Z y=2 Z

Z

rel(m)

Z acq(m) x=1 y=2 rel(m)

Page 8: Verification of Atomicity in Lock Free Programs

SAV Course 2007

Atomicity for loops

• Example:loop(){ if (x=0) {x:=1; y:=2; z:= 3; break;}}• Reduction cannot prove atomicity of this loop. • A loop is pure if it does not change the state

under normal termination.Good thing: We can replace this pure loop by:assume (x=0); x:=1; y:=2; z:=3;Called the exception variant of the loop.

Page 9: Verification of Atomicity in Lock Free Programs

SAV Course 2007

Lock free programs

• With multicore technology, thrust of concurrent programs is towards lock free programs (or non blocking programs).

• Lock freedom guarantees liveness – Some thread always makes progress irrespective of what other threads do.

• Primitives like LL/SC/VL (Load Linked/Store Conditional/VaLidate), or CAS (Compare And Swap) instead of conventional locks.

• Benefits: Better performance, no deadlocks (but still livelocks).

• Problem: Proving that lock free programs are indeed correct. Atomicity seems to be the correct criterion.

Page 10: Verification of Atomicity in Lock Free Programs

SAV Course 2007

LL/SC/VL

• LL(addr) returns the content of the given memory address.

• SC(addr, val) checks whether any other thread has written to the address addr after the most recent LL by the current thread, if not, the value val is written into addr

• VL(addr) returns true if and only if no other thread has written to addr after most recent LL(addr)

Page 11: Verification of Atomicity in Lock Free Programs

SAV Course 2007

Some theorems

• Local actions are both movers.

• Lock acquires are right movers.

• Lock releases are left movers.

• Successful SC or VL is a left mover.

• An LL matching to a successful SC or VL is a right mover. (Follows from the fact that if SC or VL is successful, then no other threads interferes in between).

Page 12: Verification of Atomicity in Lock Free Programs

SAV Course 2007

Non blocking FIFO queue using LL/SC/VL

void enq(int value){ local node = new Node(); node.value = value; node.next = null; loop{ local t = LL(Tail) in local next = LL(t.next) in if (!VL(Tail)) continue; if (next != null){ SC(Tail,next); continue; } if (SC(t.next, node)){ SC(Tail, node); return; } }}

• Enqueue value into the FIFO queue• Create a new local node• Place value in the new created node• Set next of node to null• Try adding node to list within a loop• Store address of current Tail in t• Store next of t in next• Restart if Tail changed since stored.• Check if next of Tail points to null?• If no, move Tail one ahead• Restart loop

• Try to place our node at end of list• Try to update Tail• Done!

Page 13: Verification of Atomicity in Lock Free Programs

SAV Course 2007

How to prove that enq() is atomic?

• First, purify the loops in the method.• This is a manual step.• Create enq2() and updateTail(). • updateTail() handles all updates to Tail.

enq2() has only pure loops. • The modified procedure can simulate all

behaviors of original procedure• We focus on the purified form of enq(),

that is, enq2().

Page 14: Verification of Atomicity in Lock Free Programs

SAV Course 2007

Modified procedure enq2()void enq2(int value){ local node = new Node(); node.value = value; node.next = null; loop{ local t = LL(Tail) in local next = LL(t.next) in if (!VL(Tail)) continue; if (next != null){ continue; } if (SC(t.next, node)){ return; } }}

void enq2(int value){ local node = new Node(); node.value = value; node.next = null; local t = LL(Tail) in local next = LL(t.next) in assume(VL(Tail)); assume(next = null); assume(SC(t.next, node); return; }

Page 15: Verification of Atomicity in Lock Free Programs

SAV Course 2007

Atomicity Inference

• Step 1: Identify all local actions and lock actions.

• Step 2: If all updates are through SC, mark the successful SC and VL as left movers, and matching LL is right mover.

• This makes procedure enq2() atomic.

Page 16: Verification of Atomicity in Lock Free Programs

SAV Course 2007

Motivation for this project

• Existing atomicity verifiers need manual intervention, and are very specific to the algorithm at hand.

• We wish to develop assume-guarantee reasoning to check for atomicity of expressions.

• Reason about when is an expression atomic?

• Define weaker notion of atomicity.

Page 17: Verification of Atomicity in Lock Free Programs

SAV Course 2007

Motivating examples

ly := y;assume (ly>0);y = 0; is atomic withy = 2;Conventional definition of atomicity cannot prove this.Consider the trace: ly:=y; assume(ly>0); y=2; y=0;We need to formalize a weaker notion of atomicity. All thatmatters is the final state.

Page 18: Verification of Atomicity in Lock Free Programs

SAV Course 2007

Conclusion

• Lock free algorithms pose a challenge to existing verification techniques.

• Atomicity is an important correctness criterion for lock free algorithms.

• A very nascent stage of research: notion of correctness very strong.

• Proposal to weaken the notions of correctness and provide an assume-guarantee approach to reason about atomicity.