Verifying Concurrent Objects under Fair Scheduling Hongjin Liang University of Science and Technology of China (USTC) Joint work with Xinyu Feng

… push(7); x = pop(); … push(6); … Client code C How to prove O’s correctness (safety + liveness) Concurrent object O java.util.concurrent void push(int v) { … } … int pop() { … } under fair scheduling ?

Fair scheduling Every active thread gets eventually executed Why? Real-world setting is often fair, e.g. round-robin sched. Lock-based objects are correct only under fair sched.

Need to assume fair scheduling for correctness of lock-based objects Safety: linearizability Liveness: starvation-freedom / deadlock-freedom e.g. every (or some) thread trying to acquire the lock will eventually succeed inc() { local r; … // code to acquire lock L r := cnt; cnt := r + 1; // critical section … // code to release lock L } under fair scheduling T holds lock L none of other threads may get lock L unfair

Challenge in verifying lock-based objects Object impl takes advantage of fairness assumption complicated interdependencies among threads T’ releases the lock T’ is holding the lock fair sched T gets the lock ? Progress of T can rely on other threads’ helps which fairness ensures to happen.

Challenge: with fairness, progress of T can rely on other threads’ helps look out for circular reasoning (usually unsound in liveness proofs) x := 1; while (y = 1) {}; x := 0; y := 1; while (x = 1) {}; y := 0; T1T2 deadlock cycle

Our work Program logic for starvation-free objects ensure linearizability & starvation-freedom (SF) together e.g. counter with ticket lock, lock-coupling list, … [Ongoing] verifying deadlock-free objects unified with our logic for starvation-free objects fairness plays a more complicated role e.g. objects with TAS lock, lazy list (even with ticket lock), …

SF example: counter with ticket lock inc() { local i, r; i := getAndInc( next ); while( i != owner ) {} ; // acquire lock r := cnt; cnt := r + 1; // critical section owner := i + 1; // release lock } the next available ticket currently being served

SF example: counter with ticket lock inc() { local i, r; i := getAndInc( next ); while( i != owner ) {} ; // acquire lock r := cnt; cnt := r + 1; // critical section owner := i + 1; // release lock } 0123 T1: request lock T2: request lock T1: release lock T3: request lock owner next It’s SF, because: critical section is straight-line code threads waiting for the lock line up (num of threads ahead of T not increase)

No circular reasoning because threads’ dependences form an acyclic chain T will get lockT2 releases lock T2 gets lock fair sched T1 releases lock T1 gets lock fair sched Not depend on others! next owner 0123 TT2 T1

Our idea: definite action D T will get lockT2 releases lock T2 gets lock fair sched T1 releases lock T1 gets lock fair sched D D “definite” because: action D must eventually be finished (without relying on other threads) once D becomes “enabled”. Enable

DProgress for the D-chain T gets lockT2 releases lock T2 gets lockT1 releases lock T1 gets lock D D DProgress ( n, D, S, Q) iff starting from state S, after n number of Ds from env, current thread can eventually reach a “good” state satisfying Q state S Q (inductively defined over n ) current thread succeeds in acquiring lock

Key proof for ticket-lock example inc() { local i, r; i := getAndInc( next ); while( i != owner ) {} ; r := cnt; cnt := r + 1; owner := i + 1; } T: increment owner T: its i equals owner D (1)Establish D : prove termination of critical section no matter what env does (2)Prove DProgress ( n, D, S, Q) by induction over n = (i - owner) Details of logic and example proofs are in draft paper.

Ongoing work: unify with verifying deadlock-free objects Example: counter with TAS lock inc() { local b, r; b := false; while( !b ) { b := cas(&L, 0, T); } r := cnt; cnt := r + 1; // critical section L := 0; } current thread ID DF: Some thread will succeed in acquiring the lock. It’s not SF: critical section is still straight-line code BUT, threads waiting for the lock do not line up (num of threads ahead of T could increase)

Ongoing work: unify with verifying deadlock-free objects T will get lockT1 releases lock T1 is holding lock D DProgress ( n, D, S, Q) breaks Q state S T2 will get lock T3 will get lock ? ? ? because progress of T can be delayed by other threads Solution: combined with token transfer? [Hoffmann et al. LICS’13]

More problems on modularity inc() { local r; lock(); r := cnt; cnt := r + 1; unlock(); } lock() { local i; i := getAndInc( next ); while( i != owner ) {} ; } unlock() { ; } Can we view “locks” as objects? Define “starvation-free” / “deadlock-free” locks?

Summary Verify lock-based objects under fair scheduling linearizability + starvation-freedom / deadlock-freedom problem: fairness assumption allows a thread to rely on other threads’ helps idea: definite action D & DProgress for the D-chain