semantics for concurrency
play

Semantics for Concurrency Ana Sokolova MOVEP, 18.7.2018 Part I: - PowerPoint PPT Presentation

Semantics for Concurrency Ana Sokolova MOVEP, 18.7.2018 Part I: Concurrent data structures correctness and performance via semantic structure and power relaxations Part II: Order extension results for verifying


  1. Semantics for Concurrency Ana Sokolova MOVEP, 18.7.2018

  2. Part I: Concurrent data structures 
 • correctness and performance via semantic structure and power relaxations Part II: Order extension results for 
 • verifying linearizability Ana Sokolova MOVEP 18.7.18

  3. Concurrent Data Structures Correctness and Relaxations Ali Sezgin Hannes Payer Christoph Kirsch Tom Henzinger Andreas Haas Michael Lippautz Andreas Holzer Helmut Veith

  4. Data structures enq deq Queue FIFO • f e d c b a push pop x Stack LIFO • y ins rem z n Pool unordered • k l o j m Ana Sokolova MOVEP 18.7.18

  5. Concurrent data structures enq deq Queue FIFO • f e d c b a … … push pop x Stack LIFO • … … y ins ins rem rem z n ins Pool unordered • k l o rem j m ins Ana Sokolova MOVEP 18.7.18

  6. Semantics of concurrent data structures t1: enq(2) deq(1) e.g. queues t2: enq(1) deq(2) • Sequential specification = set of legal sequences e.g. queue legal sequence enq(1)enq(2)deq(1)deq(2) • Consistency condition = e.g. linearizability / sequential consistency e.g. the concurrent history above is a linearizable queue concurrent history Ana Sokolova MOVEP 18.7.18

  7. Consistency conditions A history is … wrt a sequential specification iff there exists a legal sequence that preserves Linearizability precedence order [Herlihy,Wing ’90] 2 3 t1: enq(2) deq(1) consistency is t2: 1 4 enq(1) deq(2) about extending partial orders to total orders Sequential Consistency [Lamport’79] there exists a legal t1: 1 4 enq(1) deq(2) sequence that preserves t2: deq(1) 2 enq(2) 3 per-thread precedence (program order) Ana Sokolova MOVEP 18.7.18

  8. Performance and scalability :-))) throughput :-) :-( :-\ # of threads / cores Ana Sokolova MOVEP 18.7.18

  9. Relaxations allow trading correctness for performance provide the potential for better-performing implementations Ana Sokolova MOVEP 18.7.18

  10. Goal Stack - incorrect behavior push(a)push(b)push(c)pop(a)pop(b) • trade correctness for performance • in a controlled way with quantitative bounds measure the error from correct behaviour correct in a relaxed stack ... 2-relaxed? 3-relaxed? Ana Sokolova MOVEP 18.7.18

  11. How can relaxing help? Stack k-Relaxed stack top top thread 1 thread 1 thread 2 { } thread 2 c ... c k ... thread n b b thread n a a Ana Sokolova MOVEP 18.7.18

  12. What we have for semantic relaxations • Framework 
 out-of-order / • Generic examples 
 stuttering stacks, queues, priority queues,.. / • Concrete relaxation examples 
 CAS, shared counter • Efficient concurrent implementations of relaxation instances Ana Sokolova MOVEP 18.7.18

  13. The big picture sequential specification legal sequences S ⊆ Σ * Σ - methods with arguments Ana Sokolova MOVEP 18.7.18

  14. The big picture . S k ⊆ Σ * . k sequential specification legal sequences S ⊆ Σ * relaxed sequential specification Σ - methods with arguments sequences at distance up to k from S Ana Sokolova MOVEP 18.7.18

  15. Relaxing the Semantics Quantitative relaxations Henzinger, Kirsch, Payer, Sezgin,S. POPL13 • Sequential specification = set of legal sequences • Consistency condition = e.g. linearizability / sequential consistency Local linearizability Haas, Henzinger, Holzer,…, S, Veith CONCUR16 Ana Sokolova MOVEP 18.7.18

  16. Syntactic distances do not help push(a)[push(i)pop(i)] n push(b)[push(j)pop(j)] m pop(a) is a 1-out-of-order stack sequence top top top b b ... ... a a a its permutation distance is min(2n,2m) Ana Sokolova MOVEP 18.7.18

  17. 
 
 Semantic distances need a notion of state top state c a • States are equivalence classes of sequences in S 
 example: for stack push(a)push(b)pop(b)push(c) ≡ push(a)push(c) • Two sequences in S are equivalent iff they have an indistinguishable future x ≡ y ⇔ ∀ u ∈ Σ *. (xu ∈ S ⇔ yu ∈ S) Ana Sokolova MOVEP 18.7.18

  18. 
 
 
 Semantics goes operational S ⊆ Σ * is the sequential specification 
 states labels initial state top Stack top LTS(S) = (S/ ≡ , Σ , ➝ , [ ε ] ≡ ) with 
 c push(c) ➝ a a transition relation 
 m [s] ≡ ➝ [sm] ≡ ⇔ sm ∈ S Ana Sokolova MOVEP 18.7.18

  19. The relaxation framework c • Start from LTS(S) 
 c c” • Add transitions with transition costs 
 c’ c c’ • Fix a path cost function distance = minimal cost on all paths labelled by the sequence Ana Sokolova MOVEP 18.7.18

  20. Generic out-of-order m segment_cost( q ➝ q’ ) = | v | transition cost Where v is a sequence of minimal length s.t. removing v enables a transition or inserting v enables a transition goes with different path costs Ana Sokolova MOVEP 18.7.18

  21. 
 
 
 
 
 
 
 
 
 
 
 Out-of-order stack Sequence of push ’s with no matching pop • Canonical representative of a state 
 • Add incorrect transitions with segment-costs 
 top top c pop(a) c b 2 a b • Possible path cost functions max, sum,... also more advanced Ana Sokolova MOVEP 18.7.18

  22. Relaxing the Consistency Condition Local Linearizability (CONCUR16) Ana Sokolova MOVEP 18.7.18

  23. Local Linearizability main idea Already present in some shared-memory consistency conditions (not in our form of choice) • Partition a history into a set of local histories • Require linearizability per local history Local sequential consistency… is also possible no global witness Ana Sokolova MOVEP 18.7.18

  24. Local Linearizability (queue) example (sequential) history not linearizable t1: enq(1) deq(2) t2: enq(2) deq(1) t2-induced history, t1-induced history, linearizable linearizable locally linearizable Ana Sokolova MOVEP 18.7.18

  25. Local Linearizability (queue) definition Queue signature ∑ = {enq(x) | x ∈ V} ∪ {deq(x) | x ∈ V} ∪ {deq(empty)} in-methods of thread T For a history h with a thread T, we put are enqueues performed I T = {enq(x) T ∈ h | x ∈ V} by thread T O T = {deq(x) T’ ∈ h | enq(x) T ∈ I T } ∪ {deq(empty)} out-methods of thread T are dequeues (performed by any thread) corresponding to enqueues that are in-methods h is locally linearizable iff every thread-induced history h T = h | (I T ∪ O T ) is linearizable. Ana Sokolova MOVEP 18.7.18

  26. Local Linearizability for Container-Type DS Signature ∑ = Ins ∪ Rem ∪ SOb ∪ DOb in-methods of thread T For a history h with a thread T, we put are inserts performed by I T = {m T ∈ h | m ∈ Ins} thread T O T = {m(a) ∈ h ∩ Rem| i(a) T ∈ I T } ∪ {m(e) | e ∈ Emp} ∪ {m(a) ∈ h ∩ DOb| i(a) T ∈ I T } out-methods of thread T are removes and data-observations (performed by any thread) corresponding to in-methods h is locally linearizable iff every thread-induced history h T = h | (I T ∪ O T ) is linearizable. Ana Sokolova MOVEP 18.7.18

  27. Generalizations of Local Linearizability Signature ∑ For a history h with n threads, choose in-methods of thread i, methods that go in h i In h (i) Out h (i) by increasing the in-methods, out-methods of thread i, LL gradually moves to dependent methods linearizability on the methods in In h (i) (performed by any thread) h is locally linearizable iff every thread-induced history h i = h | (In h (i) ∪ Out h (i)) is linearizable. Ana Sokolova MOVEP 18.7.18

  28. Where do we stand? In general Linearizability Local Linearizability Sequential Consistency Ana Sokolova MOVEP 18.7.18

  29. Where do we stand? For queues (and most container-type data structures) Linearizability Local Linearizability Sequential Consistency Ana Sokolova MOVEP 18.7.18

  30. Properties like linearizability Local linearizability is compositional unlike sequential consistency h (over multiple objects) is locally linearizable iff each per-object subhistory of h is locally linearizable uses decomposition into smaller Local linearizability is modular / histories, by definition “decompositional” may allow for modular verification Ana Sokolova MOVEP 18.7.18

  31. Verification (queue) Queue sequential specification (axiomatic) s is a legal queue sequence iff 1. s is a legal pool sequence, and 2. enq(x) < s enq(y) ⋀ deq(y) ∈ s ⇒ deq(x) ∈ s ⋀ deq(x) < s deq(y) Queue linearizability (axiomatic) Henzinger, Sezgin, Vafeiadis CONCUR13 h is queue linearizable iff 1. h is pool linearizable, and 2. enq(x) < h enq(y) ⋀ deq(y) ∈ h ⇒ deq(x) ∈ h ⋀ deq(y) ≮ h deq(x) precedence order Ana Sokolova MOVEP 18.7.18

  32. Verification (queue) Queue sequential specification (axiomatic) s is a legal queue sequence iff 1. s is a legal pool sequence, and 2. enq(x) < s enq(y) ⋀ deq(y) ∈ s ⇒ deq(x) ∈ s ⋀ deq(x) < s deq(y) Queue local linearizability (axiomatic) h is queue locally linearizable iff 1. h is pool locally linearizable, and 2. enq(x) < h i enq(y) ⋀ deq(y) ∈ h ⇒ deq(x) ∈ h ⋀ deq(y) ≮ h deq(x) thread-local precedence order Ana Sokolova MOVEP 18.7.18

  33. Relaxations lead to scalable implementations e.g. k-FIFO, k-Stack a 1 x 1 y 1 b 1 k-out-of-order … queue … … … … a k x k y k b k locally linearizable distributed implementation t 1 t 2 … t n local inserts / global removes LLD Φ LL+D Φ Φ Φ Φ Ana Sokolova MOVEP 18.7.18

Recommend


More recommend