Verification of Atomicity in Lock Free Programs

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

Background • Verification in concurrent programs • Atomicity • 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… 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! 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. 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. 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) Z x=1 Z y=2 rel(m) Z Z acq(m) x=1 y=2 rel(m) 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. 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. 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) 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). SAV Course 2007

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! Non blocking FIFO queue using LL/SC/VL 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(). SAV Course 2007

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; } } } Modified procedure enq2() 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; } 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. 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. SAV Course 2007

Motivating examples ly := y; assume (ly>0); y = 0; is atomic with y = 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 that matters is the final state. 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. SAV Course 2007

Verification of Atomicity in Lock Free Programs