Presentation is loading. Please wait.

Presentation is loading. Please wait.

Concurrent Objects and Consistency The Art of Multiprocessor Programming Spring 2007.

Similar presentations


Presentation on theme: "Concurrent Objects and Consistency The Art of Multiprocessor Programming Spring 2007."— Presentation transcript:

1 Concurrent Objects and Consistency The Art of Multiprocessor Programming Spring 2007

2 © 2006 Herlihy and Shavit2 Concurrent Computaton memory object

3 © 2006 Herlihy and Shavit3 Objectivism What is a concurrent object? –How do we describe one? –How do we implement one? –How do we tell if we ’ re right?

4 © 2006 Herlihy and Shavit4 Objectivism What is a concurrent object? –How do we describe one? –How do we tell if we ’ re right?

5 © 2006 Herlihy and Shavit5 FIFO Queue: Enqueue Method q.enq ( )

6 © 2006 Herlihy and Shavit6 FIFO Queue: Dequeue Method q.deq()/

7 © 2006 Herlihy and Shavit7 Implementation: Deq public class Queue { int head = 0, tail = 0; Object[QSIZE] items; public synchronized Object deq() { while (tail – head == 0) this.wait(); items[head % QSIZE] = x; head++; this.notifyAll(); } … }} (2) 0 1 QSIZE-1 2 head tail y z

8 © 2006 Herlihy and Shavit8 Implementation: Enq public class Queue { int head = 0, tail = 0; Object[QSIZE] items; public synchronized void enq(Object x) { while (tail – head == QSIZE) this.wait(); items[tail % QSIZE] = x; tail++; this.notifyAll(); } … }} (2) 0 1 QSIZE-1 2 head tail y z

9 © 2006 Herlihy and Shavit9 public class Queue { int head = 0, tail = 0; Object[QSIZE] items; public synchronized void enq(Object x) { while (tail – head == QSIZE) this.wait(); items[tail % QSIZE] = x; tail++; this.notifyAll(); } … }} Method execution is mutually exclusive (2) Implementation: Enq

10 © 2006 Herlihy and Shavit10 public class Queue { int head = 0, tail = 0; Object[QSIZE] items; public synchronized void enq(Object x) { while (tail – head == QSIZE) this.wait(); items[tail % QSIZE] = x; tail++; this.notifyAll(); } … }} Release lock if need to wait (2) Implementation: Enq

11 © 2006 Herlihy and Shavit11 public class Queue { int head = 0, tail = 0; Object[QSIZE] items; public synchronized void enq(Object x) { while (tail – head == QSIZE) this.wait(); items[tail % QSIZE] = x; tail++; this.notifyAll(); } … }} (2) Here is where the queue is actually updated! Implementation: Enq

12 © 2006 Herlihy and Shavit12 public class Queue { int head = 0, tail = 0; Object[QSIZE] items; public synchronized void enq(Object x) { while (tail – head == QSIZE) this.wait(); items[tail % QSIZE] = x; tail++; this.notifyAll(); } … }} (2) notifyAll all that you release the lock Implementation: Enq We understand its “correct” because all modifications are mutually exclusive…

13 © 2006 Herlihy and Shavit13 Now consider the following implementation The same thing without mutual exclusion For simplicity, only two threads please: –One thread only calls enq –The other only deq

14 © 2006 Herlihy and Shavit14 Lock-free 2-Thread Queue public class LockFreeQueue { int head = 0, tail = 0; Item[QSIZE] items; public void enq(Item x) { while (tail-head == QSIZE); // busy-wait items[tail % QSIZE] = x; tail++; } public Item deq() { while (tail == head); // busy-wait Item item = items[head % QSIZE]; head++; return item; }} 0 1 QSIZE-1 2 head tail y z

15 © 2006 Herlihy and Shavit15 Lock-free 2-Thread Queue public class LockFreeQueue { int head = 0, tail = 0; Item[QSIZE] items; public void enq(Item x) { while (tail-head == QSIZE); // busy-wait items[tail % QSIZE] = x; tail++; } public Item deq() { while (tail == head); // busy-wait Item item = items[head % QSIZE]; head++; return item; }} 0 1 QSIZE-1 2 head tail y z Queue is updated without a lock! How do we define “correct” when modifications are not exclusive?

16 © 2006 Herlihy and Shavit16 Defining correct concurrent queue implementations Need a way to specify a concurrent queue object Need a way to prove that an algorithm implements the object ’ s specification Lets talk about object specifications …

17 © 2006 Herlihy and Shavit17 Sequential 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

18 © 2006 Herlihy and Shavit18 Sequential Specifications If (precondition) –the object is in such-and-such a state –before you call the method, Then (postcondition) –the method will return a particular value –or throw a particular exception. and (postcondition, con ’ t) –the object will be in some other state –when the method returns,

19 © 2006 Herlihy and Shavit19 Pre and PostConditions for Dequeue Precondition: –Queue is non-empty Postcondition: –Returns first item in queue Postcondition: –Removes first item in queue

20 © 2006 Herlihy and Shavit20 Pre and PostConditions for Dequeue Precondition: –Queue is empty Postcondition: –Throws Empty exception Postcondition: –Queue state unchanged

21 © 2006 Herlihy and Shavit21 Why Sequential Specifications Totally Rock Interactions among methods captured by side-effects on object state –State meaningful between method calls Documentation size linear in number of methods –Each method described in isolation Can add new methods –Without changing descriptions of old methods

22 © 2006 Herlihy and Shavit22 What About Concurrent Specifications ? Methods? Documentation? Adding new methods?

23 © 2006 Herlihy and Shavit23 Methods Take Time time

24 © 2006 Herlihy and Shavit24 Methods Take Time time invocation 12:00 q.enq(... ) time

25 © 2006 Herlihy and Shavit25 Methods Take Time time Method call invocation 12:00 q.enq(... ) time

26 © 2006 Herlihy and Shavit26 Methods Take Time time Method call invocation 12:00 q.enq(... ) time

27 © 2006 Herlihy and Shavit27 Methods Take Time time Method call invocation 12:00 q.enq(... ) time void response 12:01

28 © 2006 Herlihy and Shavit28 Sequential vs Concurrent Sequential –Methods take time? Who knew? Concurrent –Method call is not an event –Method call is an interval.

29 © 2006 Herlihy and Shavit29 time Concurrent Methods Take Overlapping Time time

30 © 2006 Herlihy and Shavit30 time Concurrent Methods Take Overlapping Time time Method call

31 © 2006 Herlihy and Shavit31 time Concurrent Methods Take Overlapping Time time Method call

32 © 2006 Herlihy and Shavit32 time Concurrent Methods Take Overlapping Time time Method call

33 © 2006 Herlihy and Shavit33 Sequential vs Concurrent Sequential: –Object needs meaningful state only between method calls Concurrent –Because method calls overlap, object might never be between method calls

34 © 2006 Herlihy and Shavit34 Sequential vs Concurrent Sequential: –Each method described in isolation Concurrent –Must characterize all possible interactions with concurrent calls What if two enq s overlap? Two deq s? enq and deq ? …

35 © 2006 Herlihy and Shavit35 Sequential vs Concurrent Sequential: –Can add new methods without affecting older methods Concurrent: –Everything can potentially interact with everything else

36 © 2006 Herlihy and Shavit36 Sequential vs Concurrent Sequential: –Can add new methods without affecting older methods Concurrent: –Everything can potentially interact with everything else Panic!

37 © 2006 Herlihy and Shavit37 The Big Question 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

38 © 2006 Herlihy and Shavit38 Intuitively … public class Queue { int head = 0, tail = 0; Object[QSIZE] items; public synchronized void enq(Object x) { while (tail – head == QSIZE) this.wait(); items[tail % QSIZE] = x; tail++; this.notifyAllAll(); } … }} (2) Queue is updated while holding lock (mutually exclusive)

39 © 2006 Herlihy and Shavit39 time Intuitively q.deq q.enq enq deq lock() unlock() lock() unlock() Behavior is “Sequential” enq deq Lets capture the idea of describing the concurrent via the sequential

40 © 2006 Herlihy and Shavit40 Linearizability Each method should –“ take effect ” –Instantaneously –Between invocation and response events Object is correct if this “ sequential ” behavior is correct Any such concurrent object is –Linearizable ™

41 © 2006 Herlihy and Shavit41 Is it really about the object? Each method should –“ take effect ” –Instantaneously –Between invocation and response events Sounds like a property of an execution … A linearizable object: one all of whose possible executions are linearizable

42 © 2006 Herlihy and Shavit42 Example time (6)

43 © 2006 Herlihy and Shavit43 Example time q.enq(x) time (6)

44 © 2006 Herlihy and Shavit44 Example time q.enq(x) q.enq(y) time (6)

45 © 2006 Herlihy and Shavit45 Example time q.enq(x) q.enq(y)q.deq(x) time (6)

46 © 2006 Herlihy and Shavit46 Example time q.enq(x) q.enq(y)q.deq(x) q.deq(y) time (6)

47 © 2006 Herlihy and Shavit47 Example time q.enq(x) q.enq(y)q.deq(x) q.deq(y) linearizable q.enq(x) q.enq(y)q.deq(x) q.deq(y) time (6)

48 © 2006 Herlihy and Shavit48 Example time q.enq(x) q.enq(y)q.deq(x) q.deq(y) Valid? q.enq(x) q.enq(y)q.deq(x) q.deq(y) time (6)

49 © 2006 Herlihy and Shavit49 Example time (5)

50 © 2006 Herlihy and Shavit50 Example time q.enq(x) (5)

51 © 2006 Herlihy and Shavit51 Example time q.enq(x)q.deq(y) (5)

52 © 2006 Herlihy and Shavit52 Example time q.enq(x) q.enq(y) q.deq(y) (5)

53 © 2006 Herlihy and Shavit53 Example time q.enq(x) q.enq(y) q.deq(y) q.enq(x) q.enq(y) (5)

54 © 2006 Herlihy and Shavit54 Example time q.enq(x) q.enq(y) q.deq(y) q.enq(x) q.enq(y) (5) not linearizable

55 © 2006 Herlihy and Shavit55 Example time (4)

56 © 2006 Herlihy and Shavit56 Example time q.enq(x) time (4)

57 © 2006 Herlihy and Shavit57 Example time q.enq(x) q.deq(x) time (4)

58 © 2006 Herlihy and Shavit58 Example time q.enq(x) q.deq(x) q.enq(x) q.deq(x) time (4)

59 © 2006 Herlihy and Shavit59 Example time q.enq(x) q.deq(x) q.enq(x) q.deq(x) linearizable time (4)

60 © 2006 Herlihy and Shavit60 Example time q.enq(x) time (8)

61 © 2006 Herlihy and Shavit61 Example time q.enq(x) q.enq(y) time (8)

62 © 2006 Herlihy and Shavit62 Example time q.enq(x) q.enq(y) q.deq(y) time (8)

63 © 2006 Herlihy and Shavit63 Example time q.enq(x) q.enq(y) q.deq(y) q.deq(x) time (8)

64 © 2006 Herlihy and Shavit64 q.enq(x) q.enq(y) q.deq(y) q.deq(x) Comme ci Example time Comme ça multiple orders OK linearizable

65 © 2006 Herlihy and Shavit65 Read/Write Register Example time read(1)write(0) write(1) write(2) time read(0) (4)

66 © 2006 Herlihy and Shavit66 Read/Write Register Example time read(1)write(0) write(1) write(2) time read(0) write(1) already happened (4)

67 © 2006 Herlihy and Shavit67 Read/Write Register Example time read(1)write(0) write(1) write(2) time read(0) write(1) write(1) already happened (4)

68 © 2006 Herlihy and Shavit68 Read/Write Register Example time read(1)write(0) write(1) write(2) time read(0) write(1) write(1) already happened (4) not linearizable

69 © 2006 Herlihy and Shavit69 Read/Write Register Example time read(1)write(0) write(1) write(2) time read(1) write(1) already happened (4)

70 © 2006 Herlihy and Shavit70 Read/Write Register Example time read(1)write(0) write(1) write(2) time read(1) write(1)write(2) (4) write(1) already happened

71 © 2006 Herlihy and Shavit71 Read/Write Register Example time read(1)write(0) write(1) write(2) time read(1) write(1)write(2) not linearizable (4) write(1) already happened

72 © 2006 Herlihy and Shavit72 Read/Write Register Example time write(0) write(1) write(2) time read(1) (4)

73 © 2006 Herlihy and Shavit73 Read/Write Register Example time write(0) write(1) write(2) time read(1) write(1) write(2) (4)

74 © 2006 Herlihy and Shavit74 Read/Write Register Example time write(0) write(1) write(2) time read(1) write(1) write(2) linearizable (4)

75 © 2006 Herlihy and Shavit75 Read/Write Register Example time read(1)write(0) write(1) write(2) time read(2) (2)

76 © 2006 Herlihy and Shavit76 Read/Write Register Example time read(1)write(0) write(1) write(2) time read(2) write(1) (2)

77 © 2006 Herlihy and Shavit77 Read/Write Register Example time read(1)write(0) write(1) write(2) time read(2) write(1)write(2) (2)

78 © 2006 Herlihy and Shavit78 Read/Write Register Example time read(1)write(0) write(1) write(2) time read(2) write(1)write(2) linearizable (2)

79 © 2006 Herlihy and Shavit79 Talking About Executions Why? –Can ’ t we specify the linearization point of each operation without describing an execution? Not Always –In some cases, linearization point depends on the execution

80 © 2006 Herlihy and Shavit80 Formal Model of Executions Define precisely what we mean –Ambiguity is bad when intuition is weak Allow reasoning –Formal –But mostly informal In the long run, actually more important Ask me why!

81 © 2006 Herlihy and Shavit81 Split Method Calls into Two Events Invocation –method name & args –q.enq(x) Response –result or exception –q.enq(x) returns void –q.deq() returns x –q.deq() throws empty

82 © 2006 Herlihy and Shavit82 Invocation Notation A q.enq(x) (4)

83 © 2006 Herlihy and Shavit83 Invocation Notation A q.enq(x) thread (4)

84 © 2006 Herlihy and Shavit84 Invocation Notation A q.enq(x) thread method (4)

85 © 2006 Herlihy and Shavit85 Invocation Notation A q.enq(x) thread object (4) method

86 © 2006 Herlihy and Shavit86 Invocation Notation A q.enq(x) thread object method arguments (4)

87 © 2006 Herlihy and Shavit87 Response Notation A q: void (2)

88 © 2006 Herlihy and Shavit88 Response Notation A q: void thread (2)

89 © 2006 Herlihy and Shavit89 Response Notation A q: void thread result (2)

90 © 2006 Herlihy and Shavit90 Response Notation A q: void thread object result (2)

91 © 2006 Herlihy and Shavit91 Response Notation A q: void thread object result (2) Method is implicit

92 © 2006 Herlihy and Shavit92 Response Notation A q: empty() thread object (2) Method is implicit exception

93 © 2006 Herlihy and Shavit93 History - Describing an Execution 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 H =

94 © 2006 Herlihy and Shavit94 Definition Invocation & response match if A q.enq(3) A q:void Thread names agree Object names agree Method call (1)

95 © 2006 Herlihy and Shavit95 Object Projections A q.enq(3) A q:void B p.enq(4) B p:void B q.deq() B q:3 H =

96 © 2006 Herlihy and Shavit96 Object Projections A q.enq(3) A q:void B p.enq(4) B p:void B q.deq() B q:3 H|q =

97 © 2006 Herlihy and Shavit97 Thread Projections A q.enq(3) A q:void B p.enq(4) B p:void B q.deq() B q:3 H =

98 © 2006 Herlihy and Shavit98 Thread Projections A q.enq(3) A q:void B p.enq(4) B p:void B q.deq() B q:3 H|B =

99 © 2006 Herlihy and Shavit99 Complete Subhistory 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 respnse H =

100 © 2006 Herlihy and Shavit100 Complete Subhistory A q.enq(3) A q:void A q.enq(5) B p.enq(4) B p:void B q.deq() B q:3 May or may not have taken effect H =

101 © 2006 Herlihy and Shavit101 Complete Subhistory A q.enq(3) A q:void A q.enq(5) B p.enq(4) B p:void B q.deq() B q:3 discard pending invocations H =

102 © 2006 Herlihy and Shavit102 Complete Subhistory A q.enq(3) A q:void B p.enq(4) B p:void B q.deq() B q:3 Complete(H) =

103 © 2006 Herlihy and Shavit103 Sequential Histories A q.enq(3) A q:void B p.enq(4) B p:void B q.deq() B q:3 A q:enq(5) (4)

104 © 2006 Herlihy and Shavit104 Sequential Histories A q.enq(3) A q:void B p.enq(4) B p:void B q.deq() B q:3 A q:enq(5) match (4)

105 © 2006 Herlihy and Shavit105 Sequential Histories A q.enq(3) A q:void B p.enq(4) B p:void B q.deq() B q:3 A q:enq(5) match (4)

106 © 2006 Herlihy and Shavit106 Sequential Histories A q.enq(3) A q:void B p.enq(4) B p:void B q.deq() B q:3 A q:enq(5) match (4)

107 © 2006 Herlihy and Shavit107 Sequential Histories A q.enq(3) A q:void B p.enq(4) B p:void B q.deq() B q:3 A q:enq(5) match Final pending invocation OK (4)

108 © 2006 Herlihy and Shavit108 Sequential Histories A q.enq(3) A q:void B p.enq(4) B p:void B q.deq() B q:3 A q:enq(5) match Final pending invocation OK (4) Method calls of different threads do not interleave

109 © 2006 Herlihy and Shavit109 Well-Formed Histories H= A q.enq(3) B p.enq(4) B p:void B q.deq() A q:void B q:3

110 © 2006 Herlihy and Shavit110 Well-Formed Histories H= A q.enq(3) B p.enq(4) B p:void B q.deq() A q:void B q:3 H|B= B p.enq(4) B p:void B q.deq() B q:3 Per-thread projections sequential

111 © 2006 Herlihy and Shavit111 Well-Formed Histories H= A q.enq(3) B p.enq(4) B p:void B q.deq() A q:void B q:3 H|B= B p.enq(4) B p:void B q.deq() B q:3 A q.enq(3) A q:void H|A= Per-thread projections sequential

112 © 2006 Herlihy and Shavit112 Equivalent Histories H= A q.enq(3) B p.enq(4) B p:void B q.deq() A q:void B q:3 Threads see the same thing in both A q.enq(3) A q:void B p.enq(4) B p:void B q.deq() B q:3 G= H|A = G|A H|B = G|B

113 © 2006 Herlihy and Shavit113 Sequential Specifications A sequential specification is some way of telling whether a –Single-thread, single-object history –Is legal My favorite way is using –Pre and post-conditions –But plenty of other techniques exist …

114 © 2006 Herlihy and Shavit114 Legal Histories A sequential (multi-object) history H is legal if –For every object x –H|x is in the sequential spec for x

115 © 2006 Herlihy and Shavit115 Precedence A q.enq(3) B p.enq(4) B p.void A q:void B q.deq() B q:3 A method call precedes another if response event precedes invocation event Method call (1)

116 © 2006 Herlihy and Shavit116 Non-Precedence A q.enq(3) B p.enq(4) B p.void B q.deq() A q:void B q:3 Some method calls overlap one another Method call (1)

117 © 2006 Herlihy and Shavit117 Notation Given –History H –method executions m 0 and m 1 in H We say m 0  H  m 1, if –m 0 precedes m 1 Relation m 0  H  m 1 is a –Partial order –Total order if H is sequential m0m0 m1m1

118 © 2006 Herlihy and Shavit118 Linearizability History H is linearizable if it can be extended to G by –Appending zero or more responses to pending invocations –Discarding other pending invocations So that G is equivalent to –Legal sequential history S –where  G   S

119 © 2006 Herlihy and Shavit119 What is  G   S time a b (8) GG SS c GG  G = {a  c,b  c}  S = {a  b,a  c,b  c} A limitation on the Choice of S!

120 © 2006 Herlihy and Shavit120 Remarks Some pending invocations –Took effect, so keep them –Discard the rest Condition  G   S –Means that S respects “ real-time order ” of G

121 © 2006 Herlihy and Shavit121 A q.enq(3) B q.enq(4) B q:void B q.deq() B q:4 B q:enq(6) Example time B.q.enq(4 ) A. q.enq(3) B.q.deq(4 ) B. q.enq(6)

122 © 2006 Herlihy and Shavit122 Example Complete this pending invocation time B.q.enq(4 ) B.q.deq(3 ) B. q.enq(6) A q.enq(3) B q.enq(4) B q:void B q.deq() B q:4 B q:enq(6) A. q.enq(3)

123 © 2006 Herlihy and Shavit123 Example Complete this pending invocation time B.q.enq(4 ) B.q.deq(3 ) B. q.enq(6) B.q.enq(4 ) A q.enq(3) B q.enq(4) B q:void B q.deq() B q:4 B q:enq(6) A q:void

124 © 2006 Herlihy and Shavit124 Example time B.q.enq(4 ) B.q.deq(3 ) B. q.enq(6) B.q.enq(4 ) 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 one

125 © 2006 Herlihy and Shavit125 Example time B.q.enq(4 ) B.q.deq(3 ) B.q.enq(4 ) A q.enq(3) B q.enq(4) B q:void B q.deq() B q:4 A q:void discard this one

126 © 2006 Herlihy and Shavit126 A q.enq(3) B q.enq(4) B q:void B q.deq() B q:4 A q:void Example time B.q.enq(4 ) B.q.deq(3 ) B.q.enq(4 )

127 © 2006 Herlihy and Shavit127 A q.enq(3) B q.enq(4) B q:void B q.deq() B q:4 A q:void Example time B q.enq(4) B q:void A q.enq(3) A q:void B q.deq() B q:4 B.q.enq(4 ) B.q.deq(3 ) B.q.enq(4 )

128 © 2006 Herlihy and Shavit128 B.q.enq(4 ) B.q.deq(3 ) B.q.enq(4 ) A q.enq(3) B q.enq(4) B q:void B q.deq() B q:4 A q:void Example time B q.enq(4) B q:void A q.enq(3) A q:void B q.deq() B q:4 Equivalent sequential history

129 © 2006 Herlihy and Shavit129 Concurrency How much concurrency does linearizability allow? When must a method invocation block?

130 © 2006 Herlihy and Shavit130 Concurrency Focus on total methods –Defined in every state Example: –deq() that throws Empty exception –Versus deq() that waits … Why? –Otherwise, blocking unrelated to synchronization

131 © 2006 Herlihy and Shavit131 Concurrency Question: When does linearizability require a method invocation to block? Answer: never. Linearizability is non-blocking

132 © 2006 Herlihy and Shavit132 Non-Blocking Theorem If method invocation A q.inv( … ) is pending in history H, then there exists a response A q:res( … ) such that H + A q:res( … ) is linearizable

133 © 2006 Herlihy and Shavit133 Proof Pick linearization S of H If S already contains –Invocation A q.inv( … ) and response, –Then we are done. Otherwise, pick a response such that –S + A q.inv( … ) + A q:res( … ) –Possible because object is total.

134 © 2006 Herlihy and Shavit134 Locality Theorem History H is linearizable if and only if –For every object x –H|x is linearizable We care about objects only! –(Materialism?)

135 © 2006 Herlihy and Shavit135 Why Does Locality Matter? Modularity Can prove linearizability of objects in isolation Can compose independently- implemented objects

136 © 2006 Herlihy and Shavit136 Reasoning About Lineraizability: Locking public class Queue { int head = 0, tail = 0; Object[QSIZE] items; public synchronized void enq(Object x) { while (tail – head == QSIZE) this.wait(); items[tail % QSIZE] = x; tail++; this.notifyAll(); } … }} (2) 0 1 QSIZE-1 2 head tail y z

137 © 2006 Herlihy and Shavit137 public class Queue { int head = 0, tail = 0; Object[QSIZE] items; public synchronized void enq(Object x) { while (tail – head == QSIZE) this.wait(); items[tail % QSIZE] = x; tail++; this.notifyAll(); } … }} As we said, the linearization order is order lock acquired (2) Implementation: Enq

138 © 2006 Herlihy and Shavit138 More Reasoning: Lock-free public class LockFreeQueue { int head = 0, tail = 0; Item[QSIZE] items; public void enq(Item x) { while (tail-head == QSIZE); // busy-wait items[tail % QSIZE] = x; tail++; } public Item deq() { while (tail == head); // busy-wait Item item = items[head % QSIZE]; head++; return item; }} 0 1 QSIZE-1 2 head tail y z

139 © 2006 Herlihy and Shavit139 public class LockFreeQueue { int head = 0, tail = 0; Item[QSIZE] items; public void enq(Item x) { while (tail-head == QSIZE); // busy-wait items[tail % QSIZE] = x; tail++; } public Item deq() { while (tail == head); // busy-wait Item item = items[head % QSIZE]; head++; return item; }} Linearization order is order head and tail fields modified More Reasoning

140 © 2006 Herlihy and Shavit140 Stragegy Identify one atomic step where method “ happens ” –Critical section –Machine instruction Doesn ’ t always work –Might need to define several different steps for a given method

141 © 2006 Herlihy and Shavit141 Linearizability: Summary Powerful specification tool for shared objects Allows us to capture the notion of objects being “ atomic ” Don ’ t leave home without it

142 © 2006 Herlihy and Shavit142 Alternative: Sequential Consistency History H is Sequentially Consistent if it can be extended to G by –Appending zero or more responses to pending invocations –Discarding other pending invocations So that G is equivalent to a –Legal sequential history S – Where  G   S Differs from linearizability

143 © 2006 Herlihy and Shavit143 Alternative: Sequential Consistency No need to preserve real-time order –Cannot re-order operations done by the same thread –Can re-order non-overlapping operations done by different threads Often used to describe multiprocessor memory architectures

144 © 2006 Herlihy and Shavit144 Example time (5)

145 © 2006 Herlihy and Shavit145 Example time q.enq(x) (5)

146 © 2006 Herlihy and Shavit146 Example time q.enq(x)q.deq(y) (5)

147 © 2006 Herlihy and Shavit147 Example time q.enq(x) q.enq(y) q.deq(y) (5)

148 © 2006 Herlihy and Shavit148 Example time q.enq(x) q.enq(y) q.deq(y) q.enq(x) q.enq(y) (5)

149 © 2006 Herlihy and Shavit149 Example time q.enq(x) q.enq(y) q.deq(y) q.enq(x) q.enq(y) (5) not linearizable

150 © 2006 Herlihy and Shavit150 Example time q.enq(x) q.enq(y) q.deq(y) q.enq(x) q.enq(y) (5) Yet Sequentially Consistent

151 © 2006 Herlihy and Shavit151 Theorem Sequential Consistency is not a local property (and thus we loose composability … )

152 © 2006 Herlihy and Shavit152 FIFO Queue Example time p.enq(x)p.deq(y)q.enq(x) time

153 © 2006 Herlihy and Shavit153 FIFO Queue Example time p.enq(x)p.deq(y)q.enq(x) q.enq(y)q.deq(x)p.enq(y) time

154 © 2006 Herlihy and Shavit154 FIFO Queue Example time p.enq(x)p.deq(y)q.enq(x) q.enq(y)q.deq(x)p.enq(y) History H time

155 © 2006 Herlihy and Shavit155 H|p Sequentially Consistent time p.enq(x)p.deq(y) p.enq(y) q.enq(x) q.enq(y)q.deq(x) time

156 © 2006 Herlihy and Shavit156 H|q Sequentially Consistent time p.enq(x)p.deq(y)q.enq(x) q.enq(y)q.deq(x)p.enq(y) time

157 © 2006 Herlihy and Shavit157 Ordering imposed by p time p.enq(x)p.deq(y)q.enq(x) q.enq(y)q.deq(x)p.enq(y) time

158 © 2006 Herlihy and Shavit158 Ordering imposed by q time p.enq(x)p.deq(y)q.enq(x) q.enq(y)q.deq(x)p.enq(y) time

159 © 2006 Herlihy and Shavit159 Ordering imposed by q time p.enq(x)p.deq(y)q.enq(x) q.enq(y)q.deq(x)p.enq(y) time

160 © 2006 Herlihy and Shavit160 Ordering imposed by both time p.enq(x)p.deq(y)q.enq(x) q.enq(y)q.deq(x)p.enq(y) time

161 © 2006 Herlihy and Shavit161 Fact Most hardware architectures don ’ t support sequential consistency Because they think it ’ s too strong Here ’ s another story …

162 © 2006 Herlihy and Shavit162 The Flag Example time x.write(1) y.read(0) y.write(1) x.read(0) time

163 © 2006 Herlihy and Shavit163 The Flag Example time x.write(1) y.read(0) y.write(1) x.read(0) Each thread ’ s view is sequentially consistent –It went first

164 © 2006 Herlihy and Shavit164 The Flag Example time x.write(1) y.read(0) y.write(1) x.read(0) Entire history isn ’ t sequentially consistent –Can ’ t both go first

165 © 2006 Herlihy and Shavit165 The Flag Example time x.write(1) y.read(0) y.write(1) y.read(0) Is this behavior really so wrong? –We can argue either way …

166 © 2006 Herlihy and Shavit166 Oppinion1: It ’ s Wrong This pattern –Write mine, read yours Is exactly the flag principle –Beloved of Alice and Bob –Heart of mutual exclusion Peterson Bakery, etc. It ’ s non-negotiable!

167 © 2006 Herlihy and Shavit167 Oppinion2: But It Feels So Right … Many hardware architects think that sequential consistency is too strong Too expensive to implement in modern hardware OK if flag principle –violated by default –Honored by explicit request

168 © 2006 Herlihy and Shavit168 Memory Hierarchy On modern multiprocessors, processors do not read and write directly to memory. Memory accesses are very slow compared to processor speeds, Instead, each processor reads and writes directly to a cache

169 © 2006 Herlihy and Shavit169 Memory Operations To read a memory location, –load data into cache. To write a memory location –update cached copy, –Lazily write cached data back to memory

170 © 2006 Herlihy and Shavit170 While Writing to Memory A processor can execute hundreds, or even thousands of instructions Why delay on every memory write? Instead, write back in parallel with rest of the program.

171 © 2006 Herlihy and Shavit171 Revisionist History Flag violation history is actually OK –processors delay writing to memory –Until after reads have been issued. Otherwise unacceptable delay between read and write instructions. Who knew you wanted to synchronize?

172 © 2006 Herlihy and Shavit172 Who knew you wanted to synchronize? Writing to memory = mailing a letter Vast majority of reads & writes –Not for synchronization –No need to idle waiting for post office If you want to synchronize –Announce it explicitly –Pay for it only when you need it

173 © 2006 Herlihy and Shavit173 Explicit Synchronization Memory barrier instruction –Flush unwritten caches –Bring caches up to date Compilers often do this for you –Entering and leaving critical sections Expensive

174 © 2006 Herlihy and Shavit174 Volatile In Java, can ask compiler to keep a variable up-to-date with volatile keyword Also inhibits reordering, removing from loops, & other “ optimizations ”

175 © 2006 Herlihy and Shavit175 Real-World Hardware Memory Weaker than sequential consistency But you can get sequential consistency at a price OK for expert, tricky stuff –assembly language, device drivers, etc. Linearizability more appropriate for high-level software

176 © 2006 Herlihy and Shavit176 Serializability A transaction is a finite sequence of method calls It is serializable if –transactions appear to execute serially Strictly serializable if –order is compatible with real-time Used in databases

177 © 2006 Herlihy and Shavit177 Serializability is Blocking x.read(0) y.read(0)

178 © 2006 Herlihy and Shavit178 Serializability is Blocking x.read(0) y.read(0)x.write(1) y.write(1)

179 © 2006 Herlihy and Shavit179 Serializability is Blocking x.read(0) y.read(0)x.write(1) y.write(1) deadlock Lineariability is not blocking

180 © 2006 Herlihy and Shavit180 Serializability not Local Cannot mix, say –Two-phase locking –Timestamp synchronization May serialize transactions at different objects in opposite orders Lineariability is local

181 © 2006 Herlihy and Shavit181 Comparison Serializability appropriate for –Fault-tolerance –Multi-step transactions Linearizability appropriate for –Single objects –Multiprocessor synchronization

182 © 2006 Herlihy and Shavit182 Critical Sections Easy way to implement linearizability –Take sequential object –Make each method a critical section Like synchronized methods in Java ™ Problems –Blocking –No concurrency

183 © 2006 Herlihy and Shavit183 Summary Linearizability –Operation takes effect instantaneously between invocation and response –Uses sequential specification, locality implies composablity –Good for high level objects

184 © 2006 Herlihy and Shavit184 Summary Sequential Consistency –Not composable –Harder to work with –Good way to think about hardware models We will use linearizability in the remainder of this course unless stated otherwise


Download ppt "Concurrent Objects and Consistency The Art of Multiprocessor Programming Spring 2007."

Similar presentations


Ads by Google