Post on 17-Dec-2015
Inherent limitations facilitate design &
verificationof concurrent
programs
Hagit Attiya Technion
Concurrent Programs
• Core challenge is synchronization
• Correct synchronization is hard to get right
• Efficient synchronization is even harder
Principled, Automatic approach
Work with Ramalingam and Rinetzky (POPL 2010)
EXAMPLE I:VERIFYING LOCKING PROTOCOLS
The Goal: Sequential Reductions
Verify concurrent data structures• Pre-execution static analysis
E.g., linked list with hand-over-hand locking
• no memory leaks, shape (it’s a list), serializability
Find sequential reductions Consider only sequential executions But conclude that properties hold in all
executions
Back-of-envelopestimate of gain
Static analysis of a linked-list algorithm
[Amit, Rinetzky, Reps, Sagiv, Yahav, CAV 2007]
– Verifies e.g., memory safety, sortedness, pointed-to by a variable, heap sharing One thread (sequential) 10s 3.6MB
Two threads (interleaved) ~4h 886MB
Three threads (interleaved) > 8h ----
Serializability
operation
interleaved execution
complete non-interleaved execution
~~~~~~ ~~~
[Papadimitriou ‘79]
Observed by the threads locally
Serializability gives Sequential Reduction
Concurrent code M
A small subset of all executions
If M is serializable, then a local property φ holds in all executions of M iff φ holds in all complete non-interleaved executions
Easily derived from [Papadimitriou ‘79]
How do we know that M is serializable, without considering all executions?
Special (and common) case: Disciplined programming with
locksGuard access to data with locks (lock &
unlock)Only one process holds the lock at each time
Follow a locking protocol that guarantees conflict serializability
E.g., two-phase locking (2PL) or tree locking (TL)
Two-phase locking
[Papadimitriou `79]
• Locks acquire (grow) phase followed by locks release (shrink) phaseNo lock is acquired after some lock is
released
t1
H
t1t1
t2t1
Tree (hand-over-hand) locking
[Kedem & Sliberschatz ‘76] [Smadi ‘76] [Bayer & Scholnick ‘77]
• Except for the first lock, acquire a lock only when holding the lock on its parent
• No lock is acquired after being released
t1
H
t1t1
t2
Tree (hand-over-hand) locking
[Kedem & Sliberschatz ‘76] [Smadi ‘76] [Bayer & Scholnick ‘77]
• Except for the first lock, acquire a lock only when holding the lock on its parent
• No lock is acquired after being released
t1
t2t2
H
t1
void p() { acquire(B)B = 0release(B)int b = Bif (b)
acquire(A)}
void q() {acquire(B)B = 1release(B)
}
Yes!– for databases– concurrency control monitor
ensures that M follows the locking policy at run-time M is serializable
No!– for code analysis– no central monitor
Not two-phase lockedBut only in interleaved executions
Our Goal
Statically verify that M follows a locking policy
For local conflict-serializable locking protocols – Depending only on thread’s local variables
& global variables locked by it
E.g., two phase locking, tree locking, (dynamic) DAG locking…
But not protocols that rely on a centralized concurrency control monitor!
Our contribution: Easy step
complete non-interleaved executions of M
A local conflict serializable locking policy is respected in all executions iff it is respected in all non-interleaved executions
A thread-local property holds in all executions iff it holds in all non-interleaved executions
Two phase locking
Tree lockingDynamic tree
locking
Our contribution: Easy step
complete non-interleaved executions of M
Proof considers shortest execution violating the protocol + indistiguishability argument
A local conflict serializable locking policy is respected in all executions iff it is respected in all non-interleaved executions
Further reduction
Almost-complete non-interleaved executions of M
A local conflict serializable locking policy is respected in all executions iff it is respected in all almost-complete non-interleaved executions
Further reduction: A complication
Need to argue about termination
int X=0, Y=0
void p() {acquire(Y)y = Yrelease(Y); if (y ≠ 0)
acquire(X)X = 3release(X)
}
void q() {if (random(5) == 3){
acquire(Y)Y = 1release(Y)while (true) nop
}}
Y is set to 1 & the method
enters an infinite
loop
Observe Y == 1 & violates
2PL
Cannot happen in complete non-
interleaved executions
Further reduction: Termination
Can use sequential reduction to verify termination
A terminating local conflict serializable locking policy is respected in all executions iff it is respected in all almost-complete non-interleaved executions
Initial analysis results
Shape analysis of hand-over-hand linked 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)
Our method 3.5s 4.0MB
TVLA prior 596.1s 90.3MB
Separation logic*
0.4s 0.2MB
Our method 124.6s 90.6MB
What’s next?
• Extend to other serializability protocols– shared (read) locks– non-locking non-conflict based
serializability (e.g., using timestamps)
– optimistic protocols– Aborted / failed methods
EXAMPLE II:REQUIRED MEMORY ORDERINGS
Work with Guerraoui, Hendler, Kuznetsov, Michael and Vechev (POPL 2011)
Relaxed memory models
Out of order execution of memory accesses, to compensate for slow writes
Optimize to issue reads before following writes, if they access different locations
Reordering may lead to inconsistency
CPU 0 CPU 1
cache cache
memory
interconnect
Read-after-write (RAW) Reordering
Process P:
Write(X,1)
Read(Y)
Process Q:
Write(Y,1)
Read(X)
P
QW(Y,1)
R(Y)W(X,1)
R(X)
W(X,1)
Avoiding out-of-order:Read-after-write (RAW) Fence
Process P:
Write(X,1)FENCERead(Y)
Process Q:
Write(Y,1)FENCERead(X)
P
QW(Y,1)
R(Y)W(X,1)
R(X)
Avoiding out-of-order:Atomic Operations
Atomic operations: atomic-write-after-read (AWAR)
E.g., CAS, TAS, Fetch&Add,…
atomic{read(Y) …write(X,1)
}
RAW fences / AWAR are ~60 slower than (remote) memory accesses
• Concurrent data types:– queues, counters, hash tables, trees,…– Non-commutative operations– Serializable solo-terminating implementations
• Mutual exclusion
Our result
Any concurrent program in a certain class must use RAW / AWARs
Non-commutative operations
Operation A is non-commutative if there is operation B where:
A influences Band
B influences A
Example: Queue
enq(v) adds v to the end of the queuedeq() takes item from the head of the queue
Q.deq():1;Q.deq():2 Q.deq():2;Q.deq():1deq() influence each other
Q.enq(3):ok;Q.deq():1 Q.deq():1;Q.enq(3):okenq() is not non-commutative
1 2Q
1 2Q 3
1 2Q 3
Proof Intuition: Writing
If an operation does not write, it does not influence anyoneIt would be commutative
no shared write
1
deq do not influence each other
1deq deq
Proof Intuition: Reading
If an operation does not read, it is not influenced by anyoneIt would be commutative
deq do not influence each other
no shared read
11deq deq
Proof Intuition: RAWdeq
1deq
1
W
no RAW
deq 1 1deq
serialization
Mutual exclusion
(Mutex) Two processes do not hold lock at the same time
(Deadlock-freedom) If a process calls Lock() then some process acquires the lock
Lock() operations do not “commute”!Every successful Lock() incurs a RAW / AWAR
Who should care?
• Concurrent programmers: know when is it futile to try and avoid expensive synchronization
• Hardware designers: motivation to lower cost of specific synchronization constructs
• API designers: choice of API affects synchronization
• Verification engineers: declare incorrect when synchronization is missing
“…although I hope that these shortcomings will be addressed, I hasten to add that they are insignificant compared to the huge step forward that this paper represents….”
-- Paul McKenney, Linux Weekly News, Jan 26, 2011
What else?
• Weaker operations? E.g., idempotent Work Stealing
• Other patterns• Read-after-read, write-after-write, barriers,
across-thread orders
• The cost of verifying adherence to a locking policy
• (Semi-) Automatic insertion of lock acquire / release commands or fences
And beyond…
Other theorems allowing to “cut corners” when designing / verifying concurrent applications
Thank you!