Sequential reductions for verifying serializability

1. Sequential reductions for verifying serializability Hagit Attiya Technion & EPFL G. Ramalingam MSR India Noam Rinetzky University of London

2. The goal Verify concurrent data structures • Pre-execution static analysis E.g., linked list with hand-over-hand locking • memory safety (no memory leaks) • shape invariants (it’s a list) • “atomicity” (serializability) Find sequential reductions • Consider only sequential executions • But conclude that properties hold in all executions

3. operation ~ ~ ~ ~ ~ ~ ~ ~ ~ Serializability [Papadimitriou ‘79] interleaved execution ~ thread-local views complete non-interleaved execution

4. Serializability assists verification Concurrent code M Π = all executions of M cni-Π = all complete non-interleaved executions of M  Π φ = some thread-local property If M is serializable Then Π ⊨ φ cni-Π ⊨ φ

5. Chicken and egg? How do we know that M is serializable, w/o considering all executions? I.e., checking only cni-executions If M is serializable Then Π ⊨ φ cni-Π ⊨ φ

6. H Special case: Disciplined coding Guard access to data with locks & ensure well-lockedness Follow a locking protocol that guarantees (conflict) serializability E.g., 2PL or tree (hand-over-hand) locking [Bayer & Scholnick ‘77] [Kedem & Sliberschatz ‘76] [Smadi ‘76] t2 t1 t1 t1

7. H Special case: Disciplined coding Guard access to data with locks & ensure well-lockedness Follow a locking protocol that guarantees (conflict) serializability E.g., 2PL or tree (hand-over-hand) locking [Bayer & Scholnick ‘77] [Kedem & Sliberschatz ‘76] [Smadi ‘76] t2 t1 t1 t2

8. Is this enough? int Y, B; void p() { acquire(B) B = 0 release(B) acquire(B) int b = B if (b) Y = 2 release(B) } void q() { acquire(B) B = 1 release(B) } Not even well-locked But only in interleaved executions Yes! • for databases • concurrency control monitor ensures that M follows the locking policy at run-time  M is serializable No! • for static analysis • no central monitor How to (statically) verify that M follows a locking policy?

9. Our approach Holds for local conflict-serializable (LCS) locking protocols • Use only thread-local information E.g., two phase locking, tree locking, DAG locking… But not protocols that rely on a concurrency control monitor!

10. non-interleaved execution Our contribution: Easy step cni-Π = all complete non-interleaved executions of M  Π Two phase locking Tree locking Dynamic tree locking Dynamic DAG locking For any LCS locking policy LP Π ⊨ LP ni-Π ⊨ LP For any thread-local property φ Π ⊨ φ ni-Π ⊨ φ

11. almost complete non-interleaved execution Our contribution: Further reduction acni-Π = all almost-complete non-interleaved executions of M  Π For any LCS locking policy LP Π ⊨ LP acni-Π ⊨ LP

12. Further reduction: A complication Need to argue about termination Observe Y == 1 & violates 2PL Y is set to 1 & the method enters an infinite loop int X=0, Y=0 void p() { acquire(Y) y = Y release(Y); if (y ≠ 0) acquire(X) X = 3 release(X) } void q() { if (random(5) == 3){ acquire(Y) Y = 1 release(Y) while (true) nop } }

13. Further reduction: Termination  Can use sequential reduction to verify termination For any “terminating” LCS locking policy LP Π ⊨ LP acni-Π ⊨ LP

14. Initial analysis results Shape analysis of hand-over-hand lists * Does not verify sortedness of list and fails to verify linearizability in some cases Shape analysis of hand-over-hand trees(for the first time)

15. Why in the TM workshop? • Transactions are transactions… • But we need to consider additional aspects: aborted transactions non-locking serializability (did anyone say timestamps?) • Combine with other reductions [Guerraoui, Henzinger, Jobstmann, Singh] • Beyond memory transactions: • Disciplined concurrent programming • Automatic insertion of lock/unlock commands

16. Thank you!