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 (its a list)
• atomicity (serializability)
• Find sequential reductions
• Consider only sequential executions
• But conclude that properties hold in all
  executions

3
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 ? ?
• f some thread-local property

If M is serializable Then ? ? f ? cni-? ? f
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 ? ? f ? cni-? ? f
6
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
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
t2
t1
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)

• 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

Not even well-locked But only in interleaved
executions
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
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 f ? ? f ? ni-? ? f
11
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

Y is set to 1 the method enters an infinite loop
Observe Y 1 violates 2PL
int X0, Y0 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!