Sequen&al Consistency and Linearizability

Size: px

Start display at page:

Download "Sequen&al Consistency and Linearizability"

Gregory Rogers
6 years ago
Views:

1 Sequen&al Consistency and Linearizability (Or, Reasoning About Concurrent Objects) Acknowledgement: Slides par&ally adopted from the companion slides for the book "The Art of Mul&processor Programming" by Maurice Herlihy and Nir Shavit

2 What We'll Cover Today Chapter 3 of: Digital copy can be obtained via WUSTL library: hqp://catalog.wustl.edu/search/

3 Concurrent Computa&on memory object object

4 Objec&vism What does it mean for a concurrent object to be correct? How do we specify its behavior? How do we implement one? How do we tell if the implementa/on is correct? Both sequen&al consistency and linearizability are correctness condi/ons for concurrent objects.

5 Sequen&al Consistency [1] Typically used as a memory consistency model, which specifies in what order the memory opera&ons may appear to execute. You can think of a memory loca&on as a concurrent object.

6 Sequen&al Consistency [1] [T]he result of any execution is the same as if the operations of all the processors* were executed in some sequential order, and the operations of each individual processor appear in this sequence in the order specified by its program. Leslie Lamport, 1979 The sequence of instruc&ons from threads execu&ng concurrently are interleaved to form a global linear order of all instruc&ons. The sequence of instruc&ons from a given thread is defined by the thread s program. Implicit: each memory loca&on is coherent according to the global linear order. * I will be using processor vs thread interchangeably.

dag is as if the execu&on followed some topological sort of the dag.

7 What SC Buys Us r1, r2: registers. 1 x 0 y x 1 y 1 Rela&ng to the dag: Under SC, the final result we get from execu&ng this dag is as if the execu&on followed some topological sort of the dag. r1 y 3 5 r2 x 6 r1 r r1 =?? r2 =?? possible? (example) yes (2,4,3,5) yes (2,3,4,5) yes (4,5,2,3) Not under SC SC precludes execu&ons that don't conform to program order.

8 Peterson's Algorithm public void lock() { flag[i] = true; victim = i; while (flag[j] && victim == i) {}; } public void unlock() { flag[i] = false; }

9 Crux of Peterson Proof Needs SC (1) write B (flag[b]=true) è write B (vic&m=b) (3) write B (vic&m=b) è write A (vic&m=a) (2) write A (vic&m=a) è read A (flag[b]) è read A (vic&m) A read flag[b] == true and vic&m == A, so it could not have entered the CS (QED) The proof assumes execu&on follows program order, and that each memory loca&on is coherent.

10 Linearizability [2] Originally developed to reason about behaviors of concurrent objects. Stronger than sequen&al consistency (we will say more about that later).

11 Example: Circular FIFO Queue public class FIFOQueue { int head = 0, tail = 0; items = (T[]) new Object[capacity]; public void enq(t x) { if (tail-head == capacity) throw new FullException(); items[tail % capacity] = x; tail++; } public T deq() { if (tail == head) throw new EmptyException(); Item item = items[head % capacity]; head++; return item; }} head capacity y z 2 tail

12 Now Consider the Following Scenario The FIFO queue is accessed by two threads concurrently. But, One thread enq only The other deq only

13 Wait- free 2- Thread Queue head 0 1 tail deq() 7 x y 2 enq(z) z

14 Wait- free 2- Thread Queue head 0 1 tail result = x 7 x y 2 queue[tail] = z z

15 Wait- free 2- Thread Queue head 0 1 tail head++ 7 y z 2 tail x 5 4

deq() { if (tail == head) throw new EmptyException(); Item item = items[head % capacity]; head++; return item; head capacity-1

16 Wait- Free Concurrent 2- Thread Queue public class FIFOQueue { int head = 0, tail = 0; items = (T[]) new Object[capacity]; }} public void enq(t x) { if (tail-head == capacity) throw new FullException(); items[tail % capacity] = x; tail++; } public T deq() { if (tail == head) throw new EmptyException(); Item item = items[head % capacity]; head++; return item; head capacity y z Claim: the same implementa/on can be used as a wait- free two- thread queue, and the queue will behave correctly. 2 tail

17 What is a Concurrent Queue? Need a way to specify a concurrent queue object Need a way to prove that an algorithm implements the object s specifica&on Lets talk about object specifica&ons

18 Sequen&al Objects Each object has a state Usually given by a set of fields Queue example: sequence of items Each object has a set of methods Only way to manipulate state Queue example: enq and deq methods

19 Sequen&al Specifica&ons If (precondi&on) the object is in such- and- such a state before you call the method, Then (postcondi&on) the method will return a par&cular value or throw a par&cular excep&on. and (postcondi&on, con t) the object will be in some other state when the method returns,

20 Pre and PostCondi&ons for Deq Precondi&on: Queue is non- empty Postcondi&on: Returns first item in queue Postcondi&on: Removes first item in queue

21 Pre and PostCondi&ons for Deq Precondi&on: Queue is empty Postcondi&on: Throws Empty excep&on Postcondi&on: Queue state unchanged

22 Why Sequen&al Specifica&ons Totally Rock Interac&ons among methods captured by side- effects on object state State meaningful between method calls Documenta&on size linear in number of methods Each method described in isola&on Can add new methods Without changing descrip&ons of old methods

23 Sequen&al vs Concurrent Sequen&al Methods take &me? Who knew? Objects need meaningful states only between method calls. Concurrent Method call is not an event Method call is an interval. Because method calls overlap, object might never be between method calls.

24 Sequen&al vs Concurrent Sequen&al: Each method can be described in isola&on. Can add new methods without affec&ng older methods Concurrent: Must characterize all possible interac&ons with concurrent calls What if two enq() calls overlap? Two deq() calls? enq() and deq()? Everything can poten&ally interact with everything else

25 The Big Ques&on What does it mean for a concurrent object to be correct? What is a concurrent FIFO queue? FIFO means strict temporal order Concurrent means ambiguous temporal order

26 Intui&vely public T deq() throws EmptyException { lock.lock(); try { if (tail == head) throw new EmptyException(); T x = items[head % items.length]; head++; } return x; } finally { lock.unlock(); } All queue modifica&ons are mutually exclusive

27 Intui&vely Lets capture the idea of describing the concurrent via the sequential lock() q.deq unlock() q.enq deq lock() enq unlock() Behavior is Sequential time enq deq

28 Linearizability [2] Each method should take effect instantaneously (lineariza&on point) between invoca&on (making a method call) and response (returning from a method call) events If we can look at the trace from parallel execu&on, and pick a lineariza&on point for all method invoca&ons such that the history "make sense" (i.e., matches sequen&al behavior), then the history is linearizable. A linearizable object: one all of whose possible execu&ons are linearizable.

29 Example q.enq(x) q.deq(y) q.enq(y) q.deq(x) time

30 Example q.enq(x) q.deq(y) q.enq(y) q.deq(x) time

31 Example q.enq(x) q.deq(y) q.enq(y) q.deq(x) time

32 Example q.enq(x) q.deq(y) q.enq(y) time

33 Example q.enq(x) q.deq(y) q.enq(y) q.deq(x) time

34 Example q.enq(x) q.deq(y) q.enq(y) q.deq(x) time

35 Read/Write Register Example write(0) read(1) write(2) write(1) already happened write(1) time read(0)

36 Read/Write Register Example write(0) read(1) write(2) write(1) already happened write(1) time read(0)

37 Read/Write Register Example write(0) read(1) write(2) write(1) already happened write(1) time read(1)

38 Read/Write Register Example write(0) read(1) write(2) write(1) already happened write(1) time read(1)

39 Read/Write Register Example write(0) write(2) write(1) read(1) time

40 Read/Write Register Example write(0) write(2) write(1) read(1) time

41 Talking About Execu&ons Why? Can t we specify the lineariza&on point of each opera&on without describing an execu&on? Not Always In some cases, lineariza&on point depends on the execu&on

42 Linearizability, Formally Split Method Calls into Two Events: Invoca&on method name & args q.enq(x) Response result or excep&on q.enq(x) returns void q.deq() returns x q.deq() throws empty

43 Invoca&on Nota&on A q.enq (x) thread method object arguments

44 Response Nota&on A q: void thread result object

45 Response Nota&on A q: empty() thread exception object

46 Defini&on Invoca&on & response match if Thread names agree A q.enq(3) A q:void Object names agree Method call

47 History: Describing an Execu&on H = A q.enq(3) A q:void A q.enq(5) B p.enq(4) B p:void B q.deq() B q:3 Sequence of invocations and responses

48 Object Projec&on H q = A q.enq(3) A q:void A q.enq(5) B p.enq(4) B p:void B q.deq() B q:3 Picking out entries performed on the target object.

49 Thread Projec&on H B = A q.enq(3) A q:void A q.enq(5) B p.enq(4) B p:void B q.deq() B q:3 Picking out entries performed by a given thread.

50 History: Describing an Execu&on H = A q.enq(3) A q:void A q.enq(5) B p.enq(4) B p:void B q.deq() B q:3 An invocation is pending if it has no matching response.

51 Well- Formed Histories H = A q.enq(3) A q:void B p.enq(4) A q.enq(5) B p:void B q.deq() B q:3 H A = A q.enq(3) A q:void A q.enq(5) B p.enq(4) B p:void H B = B q.deq() B q:3 Each per-thread projection contains matching invocation and responses, except for the last pending invocation.

52 Equivalent Histories H = A q.enq(3) A q:void A q.enq(5) B p.enq(4) B p:void B q.deq() B q:3 G = A q.enq(3) B p.enq(4) A q:void B p:void B q.deq() B q:3 A q.enq(5) Threads see the same thing in both H A = G A H B = G B

53 Sequen&al Specifica&ons A sequen&al specifica&on is some way of telling whether a single- thread, single- object history is legal For example: Pre and post- condi&ons But plenty of other techniques exist

54 Legal Histories A sequen&al (mul&- object) history H is legal if For every object x H x follows the sequen&al specifica&on for x

55 Precedence Ordering A q.enq(3) B p.enq(4) B p.void A q:void B q.deq() B q:3 A q.enq(3) B p.enq(4) B p.void B q.deq() A q:void B q:3 A method call precedes another if response event precedes invoca&on event Otherwise they overlap

56 Nota&on Given History H method execu&ons m 0 and m 1 in H We say m 0 è H m 1, if m 0 precedes m 1 in H Rela&on m 0 è H m 1 is a Par&al order Total order if H is sequen&al m 0 m 1

57 Linearizability [2] History H is linearizable if it can be extended to G by Appending zero or more responses to pending invoca&ons Discarding other pending invoca&ons So that G is equivalent to a legal sequen&al history S where è G è S Fix the invoca&ons that already took effect and discard the rest that haven't.

58 Linearizability [2] History H is linearizable if it can be extended to G by Appending zero or more responses to pending invoca&ons Discarding other pending invoca&ons So that G is equivalent to a legal sequen&al history S where è G è S Equivalent to S captures the fact that input/output of the methods must be the same as in sequen&al execu&on.

59 Linearizability [2] History H is linearizable if it can be extended to G by Appending zero or more responses to pending invoca&ons Discarding other pending invoca&ons So that G is equivalent to a legal sequen&al history S where è G è S The total order in S must respect the par&al order ("real- &me" ordering) in the original history.

60 Ensuring è G è S è G = {aà c,bà c} è S = {aà b,aà c,bà c} a b è G c time è S

61 Example A q.enq(3) B q.enq(4) B q:void B q.deq() B q:4 B q:enq(6) Complete this pending invoca/on A q.enq(3) B q.enq(4) B q.deq(4) B q.enq(6) time

62 Example A q.enq(3) B q.enq(4) B q:void B q.deq() B q:4 B q:enq(6) A q:void Complete this pending invoca/on A q.enq(3) B q.enq(4) B q.deq(4) B q.enq(6) time

63 Example A q.enq(3) B q.enq(4) B q:void B q.deq() B q:4 B q:enq(6) A q:void Discard this pending invoca/on A q.enq(3) B q.enq(4) B q.deq(4) B q.enq(6) time

64 Example Equivalent sequen/al history A q.enq(3) B q.enq(4) B q:void B q.deq() B q:4 A q:void B q.enq(4) B q:void A q.enq(3) A q:void B q.deq() B q:4 A q.enq(3) B q.enq(4) B q.deq(4) time

65 Composability Theorem History H is linearizable if and only if For every object x H x is linearizable Why Does Composability MaQer? Modularity Can prove linearizability of objects in isola&on Can compose independently- implemented objects

66 public class FIFOQueue { int head = 0, tail = 0; items = (T[]) new Object[capacity]; }} Reasoning About Linearizability: Wait- Free Concurrent 2- Thread Queue public void enq(t x) { if (tail-head == capacity) throw new FullException(); items[tail % capacity] = x; tail++; } public T deq() { if (tail == head) throw new EmptyException(); Item item = items[head % capacity]; head++; return item; Lineariza/on point

67 General Strategy Iden&fy one atomic step where method happens Cri&cal sec&on Machine instruc&on Not necessarily a single lineariza&on point Might need to define several different ones for a given method

68 Linearizability: Summary Powerful specifica&on tool for shared objects Allows us to capture the no&on of objects being atomic Don t leave home without it

69 Alterna&ve: Sequen&al Consistency History H is sequen&ally consistent if it can be extended to G by Appending zero or more responses to pending invoca&ons Discarding other pending invoca&ons So that G is equivalent to a legal sequen&al history S where è G è S Allows reordering opera&ons by different threads to establish a global sequen&al order. G is equivalent to S, which implies that S preserves program order within a thread.

70 SC is Weaker than Linearizability q.enq(x) q.deq(y) q.enq(y) time

71 SC is Weaker than Linearizability q.enq(x) q.deq(y) q.enq(y) time

72 Theorem Sequen&al Consistency is not composable

73 FIFO Queue Example p.enq(x) q.enq(x) p.deq(y) q.enq(y) p.enq(y) q.deq(x) time

74 H p Sequen&ally Consistent p.enq(x) q.enq(x) p.deq(y) q.enq(y) p.enq(y) q.deq(x) time

75 H q Sequen&ally Consistent p.enq(x) q.enq(x) p.deq(y) q.enq(y) p.enq(y) q.deq(x) time

76 Ordering imposed by p p.enq(x) q.enq(x) p.deq(y) q.enq(y) p.enq(y) q.deq(x) time

77 Ordering imposed by q p.enq(x) q.enq(x) p.deq(y) q.enq(y) p.enq(y) q.deq(x) time

78 Ordering imposed by both p.enq(x) q.enq(x) p.deq(y) q.enq(y) p.enq(y) q.deq(x) time

79 Combining orders p.enq(x) q.enq(x) p.deq(y) q.enq(y) p.enq(y) q.deq(x) time

80 Hardware Memory Consistency No modern- day processor implements sequen&al consistency. Hardware ac&vely reorders instruc&ons. Compilers may reorder instruc&ons, too. Why? Because most of performance is derived from a single thread s unsynchronized execu&on of code.

81 Memory Barriers (Fences) A memory barrier (or memory fence) is a hardware ac&on that enforces an ordering constraint between the instruc&ons before and aqer the fence. A memory barrier can be issued explicitly as an instruc&on (e.g., in x86: mfence) The typical cost of a memory fence is comparable to that of an L2- cache access.

82 Memory Consistency in High- Level Language In Java, can ask compiler to keep a variable up- to- date by declaring it vola&le: Adds a memory barrier aqer each store Inhibits reordering, removing from loops, & other compiler op&miza&ons C++11 standard offers atomic variables that come with a set of different memory ordering constraints.

83 Summary: Real- World Hardware weaker than sequen&al consistency Can get sequen&al consistency at a price Linearizability beqer fit for high- level soqware

84 References [1] L. Lamport. How to make a mul&processor computer that correctly executes mul&process programs. IEEE Transac&ons on Computers. September 1979;C- 28(9):690. [2] M. Herlihy, J. M. Wing. Linearizability: a correctness condi&on for concurrent objects. ACM Transac&ons on Programming Languages and Systems (TOPLAS). 1990;12(3):

85 This work is licensed under a Creative Commons Attribution-ShareAlike 2.5 License. You are free: to Share to copy, distribute and transmit the work to Remix to adapt the work Under the following conditions: Attribution. You must attribute the work to The Art of Multiprocessor Programming (but not in any way that suggests that the authors endorse you or your use of the work). Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under the same, similar or a compatible license. For any reuse or distribution, you must make clear to others the license terms of this work. The best way to do this is with a link to Any of the above conditions can be waived if you get permission from the copyright holder. Nothing in this license impairs or restricts the author's moral rights. Art of Multiprocessor Programming 94

DD2451 Parallel and Distributed Computing --- FDD3008 Distributed Algorithms

DD2451 Parallel and Distributed Computing --- FDD3008 Distributed Algorithms Lecture 2 Concurrent Objects Mads Dam Autumn/Winter 2011 Concurrent Computaton memory object object Art of Mul*processor 2 Objects