Concurrent Objects. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit

Transcription

1 Concurrent Objects Companion slides for The by Maurice Herlihy & Nir Shavit

2 Concurrent Computation memory object object 2

3 Objectivism What is a concurrent object? How do we describe one? How do we implement one? How do we tell if we re right? 3

4 Objectivism What is a concurrent object? How do we describe one? How do we tell if we re right? 4

5 FIFO Queue: Enqueue Method q.enq( ) 5

6 FIFO Queue: Dequeue Method q.deq()/ 6

7 A Lock-Based Queue class LockBasedQueue<T> { int head, tail; T[] items; Lock lock; public LockBasedQueue(int capacity) { head = 0; tail = 0; lock = new ReentrantLock(); items = (T[]) new Object[capacity]; } 7

8 A Lock-Based Queue head 0 1 capacity-1 class LockBasedQueue<T> { y z 2 int head, tail; T[] items; Lock lock; public LockBasedQueue(int capacity) { head = 0; tail = 0; lock = new ReentrantLock(); items = (T[]) new Object[capacity]; } tail Queue fields protected by single shared lock 8

9 A Lock-Based Queue head 0 1 capacity-1 class LockBasedQueue<T> { y z 2 int head, tail; T[] items; Lock lock; public LockBasedQueue(int capacity) { head = 0; tail = 0; lock = new ReentrantLock(); items = (T[]) new Object[capacity]; } Initially head = tail tail 9

10 Implementation: Deq head 0 1 public T deq() throws EmptyException capacity-1 { y z lock.lock(); try { if (tail == head) throw new EmptyException(); T x = items[head % items.length]; head++; return x; } finally { lock.unlock(); } } 2 tail 10

11 Implementation: Deq public T deq() throws EmptyException capacity-1 { y z lock.lock(); try { if (tail == head) throw new EmptyException(); T x = items[head % items.length]; head++; return x; } } finally { lock.unlock(); } head 0 1 Method calls mutually exclusive 2 tail 11

12 Implementation: Deq public T deq() throws EmptyException capacity-1 { y z lock.lock(); try { if (tail == head) throw new EmptyException(); T x = items[head % items.length]; head++; return x; } } finally { lock.unlock(); } head 0 1 If queue empty throw exception 2 tail 12

13 Implementation: Deq public T deq() throws EmptyException capacity-1 { y z lock.lock(); try { if (tail == head) throw new EmptyException(); T x = items[head % items.length]; head++; return x; } } finally { lock.unlock(); } head 0 1 Queue not empty: remove item and update head 2 tail 13

14 Implementation: Deq head 0 1 public T deq() throws EmptyException capacity-1 { y z lock.lock(); try { if (tail == head) throw new EmptyException(); T x = items[head % items.length]; head++; return x; } finally { lock.unlock(); } } Return result 2 tail 14

15 Implementation: Deq public T deq() throws EmptyException capacity-1 { y z lock.lock(); try { if (tail == head) throw new EmptyException(); T x = items[head % items.length]; } head++; return x; } finally { lock.unlock(); } head 0 1 Release lock no matter what! 2 tail 15

16 Implementation: Deq 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(); } } 16

17 Now consider the following implementation The same thing without mutual exclusion For simplicity, only two threads One thread enq only The other deq only 17

18 Wait-free 2-Thread Queue public class WaitFreeQueue { int head = 0, tail = 0; items = (T[]) new Object[capacity]; public void enq(item x) { while (tail-head == capacity); // busy-wait items[tail % capacity] = x; tail++; } public Item deq() { while (tail == head); // busy-wait Item item = items[head % capacity]; head++; return item; }} 18

19 Wait-free 2-Thread Queue public class LockFreeQueue { int head = 0, tail = 0; items = (T[]) new Object[capacity]; head capacity y z 2 tail public void enq(item x) { while (tail-head == capacity); // busy-wait items[tail % capacity] = x; tail++; } public Item deq() { while (tail == head); // busy-wait Item item = items[head % capacity]; head++; return item; }} 19

20 Lock-free 2-Thread Queue public class LockFreeQueue { int head = 0, tail = 0; items = (T[])new Object[capacity]; head capacity y z 2 tail public void enq(item x) { while (tail-head == capacity); // busy-wait items[tail % capacity] = x; tail++; } public Item deq() { while (tail == head); // busy-wait Item item = items[head % capacity]; head+ +; return Queue item; is updated without a lock! }} 20

21 Defining 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 21

22 Correctness and Progress In a concurrent setting, we need to specify both the safety and the liveness properties of an object Need a way to define when an implementation is correct the conditions under which it guarantees progress Lets begin with correctness 22

23 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 23

24 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, 24

25 Pre and PostConditions for Dequeue Precondition: Queue is non-empty Postcondition: Returns first item in queue Postcondition: Removes first item in queue 25

26 Pre and PostConditions for Dequeue Precondition: Queue is empty Postcondition: Throws Empty exception Postcondition: Queue state unchanged 26

27 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 27

28 What About Concurrent Specifications? Methods? Documentation? Adding new methods? 28

29 Methods Take Time time 29

30 Methods Take Time invocation 12:00 q.enq (...) time 30

31 Methods Take Time invocation 12:00 q.enq (...) Method call time 31

32 Methods Take Time invocation 12:00 q.enq (...) Method call time 32

33 Methods Take Time invocation 12:00 response 12:01 q.enq (...) void Method call time 33

34 Sequential vs Concurrent Sequential Methods take time? Who knew? Concurrent Method call is not an event Method call is an interval. 34

35 Concurrent Methods Take Overlapping Time time 35

36 Concurrent Methods Take Overlapping Time Method call time 36

37 Concurrent Methods Take Overlapping Time Method call Method call time 37

38 Concurrent Methods Take Overlapping Time Method call Method call Method call time 38

39 Sequential vs Concurrent Sequential: Object needs meaningful state only between method calls Concurrent Because method calls overlap, object might never be between method calls 39

40 Sequential vs Concurrent Sequential: Each method described in isolation Concurrent Must characterize all possible interactions with concurrent calls What if two enqs overlap? Two deqs? enq and deq? 40

41 Sequential vs Concurrent Sequential: Can add new methods without affecting older methods Concurrent: Everything can potentially interact with everything else 41

42 Sequential vs Concurrent Sequential: Can add new methods without affecting older methods Concurrent: Everything can potentially interact with everything else 42

43 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 43

44 Intuitively 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(); } } 44

45 Intuitively 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 modifications of queue are done mutually exclusive 45

46 Intuitively 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 46

47 Linearizability Each method should take effect Instantaneously Between invocation and response events Object is correct if this sequential behavior is correct Ordering must be maintained between request and responses (addendum) Any such concurrent object is Linearizable 47

48 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 48

49 Example time (6) 49

50 Example q.enq(x) time (6) 50

51 Example q.enq(x) q.enq(y) time (6) 51

52 Example q.enq(x) q.enq(y) q.deq(x) time (6) 52

53 Example q.enq(x) q.deq(y) q.enq(y) q.deq(x) time (6) 53

54 Example q.enq(x) q.deq(y) q.enq(y) q.deq(x) time (6) 54

55 Example q.enq(x) q.deq(y) q.enq(y) q.deq(x) time (6) 55

56 Example time (5) 56

57 Example q.enq(x) time (5) 57

58 Example q.enq(x) q.deq(y) time (5) 58

59 Example q.enq(x) q.deq(y) q.enq(y) time (5) 59

60 Example q.enq(x) q.deq(y) q.enq(y) time (5) 60

61 Example q.enq(x) q.deq(y) q.enq(y) time (5) 61

62 Example time (4) 62

63 Example q.enq(x) time (4) 63

64 Example q.enq(x) q.deq(x) time (4) 64

65 Example q.enq(x) q.deq(x) time (4) 65

66 Example q.enq(x) q.deq(x) time (4) 66

67 Example q.enq(x) time (8) 67

68 Example q.enq(x) q.enq(y) time (8) 68

69 Example q.enq(x) q.deq(y) q.enq(y) time (8) 69

70 Example q.enq(x) q.deq(y) q.enq(y) q.deq(x) time (8) 70

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

86 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 86

87 Formal Model of Executions Define precisely what we mean Ambiguity is bad when intuition is weak Allow reasoning 87

88 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 88

89 Invocation Notation A q.enq(x) (4) 89

90 Invocation Notation A q.enq(x) thread (4) 90

91 Invocation Notation A q.enq(x) thread method (4) 91

92 Invocation Notation A q.enq(x) thread method object (4) 92

93 Invocation Notation A q.enq(x) thread method object arguments (4) 93

94 Response Notation A q: void (2) 94

95 Response Notation A q: void thread (2) 95

96 Response Notation A q: void thread result (2) 96

97 Response Notation A q: void thread result object (2) 97

98 Response Notation A q: void thread result object (2) 98

99 Response Notation A q: empty() thread exception object (2) 99

100 History - Describing an Execution 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 100

101 Definition Invocation & response match if Thread names agree A q.enq(3) A q:void Object names agree Method call (1) 101

102 Object Projections H = A q.enq(3) A q:void B p.enq(4) B p:void B q.deq() B q:3 102

103 Object Projections H q = A q.enq(3) A q:void B p.enq(4) B p:void B q.deq() B q:3 103

104 Thread Projections H = A q.enq(3) A q:void B p.enq(4) B p:void B q.deq() B q:3 104

105 Thread Projections H B = A q.enq(3) A q:void B p.enq(4) B p:void B q.deq() B q:3 105

106 Complete Subhistory H = A q.enq(3) A q:void A q.enq(5) B p.enq(4) B p:void B q.deq() An invocation is B q:3 pending if it has no matching respnse 106

107 Complete Subhistory 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 May or may not have taken effect 107

108 Complete Subhistory 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 discard pending invocations 108

109 Complete Subhistory A q.enq(3) A q:void Complete(H) = B p.enq(4) B p:void B q.deq() B q:3 109

110 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) 110

111 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) 111

112 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 match (4) 112

113 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 match match (4) 113

114 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) match match match Final pending invocation OK 114

115 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) match match match Final pending invocation OK 115

116 Well-Formed Histories H= A q.enq(3) B p.enq(4) B p:void B q.deq() A q:void B q:3 116

117 Well-Formed Histories Per-thread projections sequential 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 117

118 Well-Formed Histories Per-thread projections sequential H= A q.enq(3) B p.enq(4) B p:void B q.deq() A q:void B q:3 H B= H A= B p.enq(4) B p:void B q.deq() B q:3 A q.enq(3) A q:void 118

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

120 Sequential Specifications A sequential specification is some way of telling whether a Single-thread, single-object history Is legal For example: Pre and post-conditions But plenty of other techniques exist 120

121 Legal Histories A sequential (multi-object) history H is legal if For every object x H x is in the sequential spec for x 121

122 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 Method call (1) 122

123 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 Method call (1) 123

124 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 m Relation m 0 H m 1 is a 0 m 1 Partial order Total order if H is sequential 124

125 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 125

126 What is G S G = {a c,b c} S = {a b,a c,b c} a b G c time S (8) 126

127 Remarks Some pending invocations Took effect, so keep them Discard the rest Condition G S Means that S respects real-time order of G 127

128 Example 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) B.q.enq(4) B.q.deq(4) time B. q.enq(6) 128

129 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 invocation A. q.enq(3) B.q.enq(4) B.q.deq(3) B. q.enq(6) time 129

130 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 invocation B.q.enq(3) B.q.enq(4) B.q.deq(4) B. q.enq(6) time 130

131 Example discard this one A q.enq(3) B q.enq(4) B q:void B q.deq() B q:4 B q:enq(6) A q:void B.q.enq(3) B.q.enq(4) B.q.deq(4) B. q.enq(6) time 131

132 Example discard this one A q.enq(3) B q.enq(4) B q:void B q.deq() B q:4 A q:void B.q.enq(3) B.q.enq(4) B.q.deq(4) time 132

133 Example A q.enq(3) B q.enq(4) B q:void B q.deq() B q:4 A q:void B.q.enq(3) B.q.enq(4) B.q.deq(4) time 133

134 Example 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 B.q.enq(3) B.q.enq(4) B.q.deq(4) time 134

135 Example Equivalent sequential 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 B.q.enq(3) B.q.enq(4) B.q.deq(4) time 135

136 Concurrency How much concurrency does linearizability allow? When must a method invocation block? 136

137 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 137

138 Concurrency Question: When does linearizability require a method invocation to block? Answer: never. Linearizability is non-blocking 138

139 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 139

140 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. 140

141 Composability Theorem History H is linearizable if and only if For every object x H x is linearizable 141

142 Why Does Composability Matter? Modularity Can prove linearizability of objects in isolation Can compose independently-implemented objects 142

143 Reasoning About Lineraizability: Locking head 0 1 public T deq() throws EmptyException capacity-1 { y z lock.lock(); try { if (tail == head) throw new EmptyException(); T x = items[head % items.length]; head++; return x; } finally { lock.unlock(); } } 2 tail 143

144 Reasoning About Lineraizability: Locking 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(); } Linearization points are when locks are released 144

145 More Reasoning: Lock-free public class LockFreeQueue { int head = 0, tail = 0; items = (T[]) new Object[capacity]; head capacity y z 2 tail public void enq(item x) { while (tail-head == capacity); // busy-wait items[tail % capacity] = x; tail++; } public Item deq() { while (tail == head); // busy-wait Item item = items[head % capacity]; head++; return item; }} 145

146 More Reasoning public class LockFreeQueue { Linearization order is order head and tail fields modified int head = 0, tail = 0; items = (T[]) new Object[capacity]; public void enq(item x) { while (tail-head == capacity); // busy-wait items[tail % capacity] = x; tail++; } public Item deq() { while (tail == head); // busy-wait Item item = items[head % capacity]; head++; return item; }} 146

147 Strategy 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 147

148 Linearizability: Summary Powerful specification tool for shared objects Allows us to capture the notion of objects being atomic There is a lot of ongoing research in verification community to build tools that can verify/debug concurrent implementations wrt linearizability 148

149 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

150 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

151 Example time (5)

152 Example q.enq(x) time (5)

153 Example q.enq(x) q.deq(y) time (5)

154 Example q.enq(x) q.deq(y) q.enq(y) time (5)

155 Example q.enq(x) q.deq(y) q.enq(y) time (5)

156 Example q.enq(x) q.deq(y) q.enq(y) time (5)

157 Example q.enq(x) q.deq(y) q.enq(y) time (5)

158 Theorem Sequential Consistency is not a local property (and thus we lose composability )

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

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

161 FIFO Queue Example p.enq(x) q.enq(x) p.deq(y) q.enq(y) p.enq(y) q.deq(x) History H time

162 H p Sequentially Consistent p.enq(x) q.enq(x) p.deq(y) q.enq(y) p.enq(y) q.deq(x) time

163 H q Sequentially Consistent p.enq(x) q.enq(x) p.deq(y) q.enq(y) p.enq(y) q.deq(x) time

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

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

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

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

168 Fact Most hardware architectures don t support sequential consistency Because they think it s too strong Here s another story

169 The Flag Example x.write(1) y.read(0) y.write(1) x.read(0) time

170 The Flag Example x.write(1) y.read(0) y.write(1) x.read(0) Each thread s view is sequentially consistent It went first time

171 The Flag Example x.write(1) y.read(0) y.write(1) x.read(0) Entire history isn t sequentially consistent time Can t both go first

172 The Flag Example x.write(1) y.read(0) y.write(1) x.read(0) Is this behavior really so wrong? We can argue either way time

173 Opinion1: It s Wrong This pattern Write mine, read yours Heart of mutual exclusion Peterson Bakery, etc. It s non-negotiable!

174 Opinion2: But It Should be Allowed 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

175 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

176 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

177 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.

178 Bottomline.. 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?

179 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

180 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

181 Volatile In Java, can ask compiler to keep a variable up-to-date with volatile keyword Also inhibits reordering, removing from loops, & other optimizations

182 Real-World Hardware Memory Weaker than sequential consistency Examples: TSO, RMO, Intel x86 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

183 Critical Sections Easy way to implement linearizability Take sequential object Make each method a critical section Problems Blocking No concurrency

184 Linearizability Linearizability Operation takes effect instantaneously between invocation and response Uses sequential specification, locality implies composablity Good for high level objects

185 Correctness: Linearizability Sequential Consistency Not composable Harder to work with Good way to think about hardware models We will use linearizability as in the remainder of this course unless stated otherwise

186 Progress We saw an implementation whose methods were lock-based (deadlockfree) We saw an implementation whose methods did not use locks (lock-free) How do they relate?

187 Maximal vs. Minimal Minimal progress: in some suffix of H, some pending active invocation has a matching response (some method call eventually completes ).

188 Maximal vs. Minimal Minimal progress: in some suffix of H, some pending active invocation has a matching response (some method call eventually completes ).

189 Maximal vs. Minimal Minimal progress: in some suffix of H, some pending active invocation has a matching response (some method call eventually completes ). Maximal progress: in every suffix of H, every pending active invocation has a matching response (every method call always completes).

190 Maximal vs. Minimal Minimal progress: in some suffix of H, some pending active invocation has a matching response (some method call eventually completes ). Maximal progress: in every suffix of H, every pending active invocation has a matching response (every method call always completes).

191 Progress Conditions Deadlock-free: some thread trying to acquire the lock eventually succeeds. Starvation-free: every thread trying to acquire the lock eventually succeeds. Lock-free: some thread calling a method eventually returns. Wait-free: every thread calling a method eventually returns.

192 Progress Conditions Non-Blocking Blocking Everyone makes progress Someone makes progress Wait-free Lock-free Starvation-free Deadlock-free

193 Summary We will look at linearizable blocking and non-blocking implementations of objects.