Overview of Lecture 4. Memory Models, Atomicity & Performance. Ben-Ari Concurrency Model. Dekker s Algorithm 4

Transcription

1 Concurrent and Distributed Programming Overview of Lecture 4 2 Memory Models, tomicity & Performance HC 4 - Tuesday, 6 December CDP #4 Machine rchitecture: Things Your Programming Language Never Told You, Herb Sutter, 2007 Ch. 3 Concurrent Objects Quiescent Consistency Sequential Consistency Linearizability Memory Models The rt of Multiprocessor Programming. Maurice Herlihy and Nir Shavit. Morgan Kaufmann, en-ri Concurrency Model 3 Dekker s lgorithm 4 Idealized Statements are atomic Shared variables: Changes can be observed immediately by other processes boolean wantp false, wantq false integer turn 1 p q lg (p. 60) p integer i 0 q i i + 1 i integer i 0 What are the concurrency models of the Real World? p integer t0 t0 i t0 t0 + 1 i t0 q i loop forever p1: non-critical section p2: wantp true p3: while wantq p4: if turn = 2 p5: wantp false p6: await turn = 1 p7: wantp true p8: critical section p9: turn 2 p10: wantp false loop forever q1: non-critical section q2: wantq true q3: while wantp q4: if turn = 1 q5: wantq false q6: await turn = 2 q7: wantq true q8: critical section q9: turn 1 q10: wantq false

2 Dekker s lgorithm: Repaired? 5 Volatile Variables 6 Options: Volatiles Tag variable, not each use! Portable / Restrictions Correct? Locks? Point of Dekker s lg. Reuse proven code Fences/arriers volatile boolean wantp false, wantq false volatile integer turn 1 p loop forever p1: non-critical section p2: wantp true p3: while wantq p4: if turn = 2 p5: wantp false p6: await turn = 1 p7: wantp true p8: critical section p9: turn 2 p10: wantp false Must tag every use! Portable Difficult reasoning: compiler, processor, q loop forever q1: non-critical section q2: wantq true q3: while wantp q4: if turn = 1 q5: wantq false q6: await turn = 2 q7: wantq true q8: critical section q9: turn 1 q10: wantq false Volatiles are supposed to provide tomicity Memory consistency Semantics depend on the programming language used (differences in guarantees) For Java: okay! C compilers: No atomicity guarantees for values larger than a machine word (structs, bitfields, ). NSI C: no atomicity guarantees at all! No guarantees about non-volatile data Note: Even with volatile declaration, x++ is not an atomic update! Invisible Transformations Register llocation t0 = var update t0 (repeatedly) var = t0 Speculative Execution (e.g., branch prediction) if (condition) update var t0 = var update var if (not condition) var = t0 /* undo */ Key issue: System invents updates 7 Conditional Locking: Example 8 update count based on item; Is this transformation safe? (i.e., semantics preserving) Consider vec.size() == 0: count updated without lock taken! Conditional Locking int t0 = count; update t0 based on item; count = t0; loop only entered if vec.size() > 0 ssume vec.size() not changed by other threads between first if and start loop

3 Conditional Locking: Fix 1 9 Conditional Locking: Fix 2 10 update count based on item; update count based on item; write is conditional int t0 = count; update t0 based on item; if (vec.size() > 0) count = t0; write is conditional int t0 = 0; update t0 based on item; if (t0 > 0) count = t0; Conditional Locking: Fix 3 11 update count based on item; write is conditional int t0 = count; dirty = false; { update t0 based on item; dirty = true; if (dirty) count = t0; From Program to Execution 12 Source Code Compiler/JIT Optimizations (CSE, Register lloc.) System ssumption: Programs should be synchronized correctly! Processor Prefetching Speculative Exec. Out-of-Order Exec. Cache Store uffers Shared Caches Local Caches Transformations invisible Programmer operates under assumption: Order of executed operations equivalent to some sequential execution according to program order Writes become visible to all processors at the same Registers ctual Execution

4 Correctness Properties 13 Correctness of Sequential Objects 14 Correctness of an execution: Equivalence with some sequential behavior Each object has a state (usually consisting of values of variables) and a set of methods. Principle if (precondition) It is easier to reason about correctness if concurrent executions can be mapped to sequential ones. Then reason about the sequential ones. the object is in a particular state before the method is called then (postcondition) the method will return a particular value or throw a particular exception and (postcondition, continued) the object will be in some other state when the method returns Pre- and Postconditions: Example 15 Sequential Objects 16 Dequeue method on a FIFO queue: precondition: queue is non-empty Interactions among methods are captured by side-effects on object states. postcondition: postcondition: returns first item in queue removes first item in queue n object state is meaningful between method calls. precondition: postcondition: postcondition: queue is empty throws QueueEmptyException queue remains unchanged Each method can be described in isolation. New methods can be added without changing the description of old methods.

5 Concurrent Objects 17 Correctness of concurrent objects 18 Method calls on concurrent threads can overlap (in ). Quiescent Consistency Result: an object may never be between method calls. Sequential Consistency Linearizability ll possible interactions between method calls must be taken into account. Currently investigating: use of histories Pre- or postcondition may be invalidated by other thread. What does it mean for a concurrent object to be correct? Quiescence n object is quiescent, if it has no pending method calls. (pending: called, but not yet returned) r.w(7) Notation: r.w(v) writes v r.r(v) reads v r.r(-7) violates sequential order: value appears from thin air 19 Quiescence 20 Principle (TMP) Method calls should appear to happen in a oneat-a- sequential order. r.w(-3) r.r(-7) r.r(7) r.r(?) We expect either r.r(7) or r.r(-3) one-at-a- sequential order = instantaneously Principle by itself is too weak: e.g., always return initial state r quiescent

6 Quiescent Consistency 21 Quiescent Consistency 22 Principle is too weak: always return initial state We expect: Principle (TMP) Method calls should appear to happen in a one-at-a sequential order. r.w(7) r.r(-3) Principle (TMP) r.w(-3) Method calls separated by a period of quiescence should appear to take effect in their real- order. Quiescent Consistency: Principles ny an object becomes quiescent, execution so far is equivalent to some sequential execution of the completed calls Quiescent Consistency: Problems 23 Sequential Consistency 24 We expect that within a single thread, method calls happen in program order: Principle (TMP) Method calls should appear to happen in a one-at-a sequential order. r.r( ) r.r( ) Principle (TMP) r.w(7) r.w(-3) r.r(7) r.r(?) We expect r.r(-3) Method calls should appear to take effect in program order. r quiescent? r quiescent? NO! Principle does not apply; program order is violated Sequential Consistency [Lamport79]: Principles Object is SC, if all its possible executions are SC.

7 Sequential consistency 25 Sequential Consistency: Example 1 26 We expect that within a single thread, method calls happen in program order: Notation: q.enq(v) enqueues v q.deq(v) dequeues value, which is v r.r( ) r.r( ) r.w(7) r.w(-3) r.r(-3) r.r(?) Sequentially Consistent Sequential Consistency: Example 2 27 Sequential Consistency: Example 3 28 Sequentially Consistent Not Sequentially Consistent

8 Sequential Consistency: Example 3 29 Sequential Consistency: Problems 30 p.enq(x) p.deq(y) p.enq(y) Proof: ssume sequential consistency, <, (by program order), <, (by program order), <, (q is FIFO & y dequeued before x), <, <, (contradiction) s < t means s happens before t FIFOs p and q are each sequentially consistent, execution as a whole is not! p.enq(y), < p.enq(x), p.enq(x), <,, <,, < p.enq(y), Cyclic dependencies: p.enq(y), < p.enq(y), Compositionality 31 Linearizability 32 Compositionality (TMP) correctness property P is compositional if, whenever each object in the system satisfies P, the system as a whole satisfies P. Principle (TMP) Each method call should appear to take effect instantaneously at some moment between its invocation and return. Desirable property for large systems (modularity) Real- behavior of method calls must be preserved. Components can be proved correct independently Quiescent Consistency is compositional Sequential Consistency is not compositional Linearizability implies Sequential Consistency, but not vice versa. Object is linearizable, if all its possible executions are linearizable.

9 Linearizability: Example 1 33 Linearizability: Example 2 34 Linearizable Linearizable Linearizability: Example 3 35 Summary 36 Linearizability is compositional Sequential Consistency is not compositional Quiescent Consistency is compositional Sequential Consistency and Quiescent Consistency are incomparable: neither implies the other Not Linearizable Sequential Consistency is less restrictive than Linearizability: method calls can take effect after they returned.

10 Which one is it? 37 Which correctness property is right for a given application? This depends on the needs of the application: print server can allow jobs to be reordered. banking server better be sequentially consistent. stock-trading server requires linearizability. Linearizability is well-suited for high-level objects. Most hardware architectures do not support sequential consistency: it is considered too expensive. Most reads/writes are not for synchronization: Pay as you go