Concurrent Queues and Stacks. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
|
|
|
- Thomasine Mavis Ball
- 5 years ago
- Views:
Transcription
1 Concurrent Queues and Stacks Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
2 The Five-Fold Path Coarse-grained locking Fine-grained locking Optimistic synchronization Lazy synchronization Lock-free synchronization Art of Multiprocessor Programming 2
3 Another Fundamental Problem We told you about Sets implemented by linked lists Next: queues Next: stacks Art of Multiprocessor Programming 3
4 Queues & Stacks pool of items Art of Multiprocessor Programming 4
5 Queues deq()/ enq( ) Total order First in First out Art of Multiprocessor Programming 5
6 Stacks pop()/ push( ) Total order Last in First out Art of Multiprocessor Programming 6
7 Bounded Fixed capacity Good when resources an issue Art of Multiprocessor Programming 7
8 Unbounded Unlimited capacity Often more convenient Art of Multiprocessor Programming 8
9 Blocking zzz Block on attempt to remove from empty stack or queue Art of Multiprocessor Programming 9
10 Blocking zzz Block on attempt to add to full bounded stack or queue Art of Multiprocessor Programming 10
11 Non-Blocking Ouch! Throw exception on attempt to remove from empty stack or queue Art of Multiprocessor Programming 11
12 This Lecture Queue Bounded, blocking, lock-based Unbounded, non-blocking, lock-free Stack Unbounded, non-blocking lock-free Elimination-backoff algorithm Art of Multiprocessor Programming 12
13 Queue: Concurrency enq(x) tail head y=deq() enq() and deq() work at different ends of the object Art of Multiprocessor Programming 13
14 Concurrency enq(x) y=deq() Challenge: what if the queue is empty or full? Art of Multiprocessor Programming 14
15 Bounded Queue head tail Sentinel Art of Multiprocessor Programming 15
16 Bounded Queue head tail First actual item Art of Multiprocessor Programming 16
17 Bounded Queue head tail deqlock Lock out other deq() calls Art of Multiprocessor Programming 17
18 Bounded Queue head tail deqlock enqlock Lock out other enq() calls Art of Multiprocessor Programming 18
19 Not Done Yet head tail deqlock enqlock Need to tell whether queue is full or empty Art of Multiprocessor Programming 19
20 Not Done Yet head tail deqlock enqlock size 1 Max size is 8 items Art of Multiprocessor Programming 20
21 Not Done Yet head tail deqlock enqlock size 1 Incremented by enq() Decremented by deq() Art of Multiprocessor Programming 21
22 Enqueuer head tail deqlock enqlock Lock enqlock size 1 Art of Multiprocessor Programming 22
23 Enqueuer head tail deqlock enqlock Read size size 1 OK Art of Multiprocessor Programming 23
24 Enqueuer head tail deqlock enqlock No need to lock tail size 1 Art of Multiprocessor Programming 24
25 Enqueuer head tail deqlock enqlock size 1 Enqueue Node Art of Multiprocessor Programming 25
26 Enqueuer head tail deqlock enqlock size 12 getandincrement() Art of Multiprocessor Programming 26
27 Enqueuer head tail deqlock enqlock size 82 Release lock Art of Multiprocessor Programming 27
28 Enqueuer head tail deqlock enqlock size 2 If queue was empty, notify waiting dequeuers Art of Multiprocessor Programming 28
29 Unsuccesful Enqueuer head tail deqlock enqlock Read size size 8 Uh-oh Art of Multiprocessor Programming 29
30 Dequeuer head tail deqlock enqlock size 2 Lock deqlock Art of Multiprocessor Programming 30
31 Dequeuer head tail deqlock enqlock size 2 Read sentinel s next field OK Art of Multiprocessor Programming 31
32 Dequeuer head tail deqlock enqlock size 2 Read value Art of Multiprocessor Programming 32
33 Dequeuer Make first Node new sentinel head tail deqlock enqlock size 2 Art of Multiprocessor Programming 33
34 Dequeuer head tail deqlock enqlock size 1 Decrement size Art of Multiprocessor Programming 34
35 Dequeuer head tail deqlock enqlock size 1 Release deqlock Art of Multiprocessor Programming 35
36 Unsuccesful Dequeuer head tail deqlock enqlock size 0 Read sentinel s next field uh-oh Art of Multiprocessor Programming 36
37 Digression: Monitor Locks Java synchronized objects and ReentrantLocks are monitors Allow blocking on a condition rather than spinning Threads: acquire and release lock wait on a condition Art of Multiprocessor Programming 37
38 The Java Lock Interface public interface Lock { void lock(); void lockinterruptibly() throws InterruptedException; boolean trylock(); boolean trylock(long time, TimeUnit unit); Condition newcondition(); void unlock; } Acquire lock Art of Multiprocessor Programming 38
39 The Java Lock Interface public interface Lock { void lock(); void lockinterruptibly() throws InterruptedException; boolean trylock(); boolean trylock(long time, TimeUnit unit); Condition newcondition(); void unlock; } Release lock Art of Multiprocessor Programming 39
40 The Java Lock Interface public interface Lock { void lock(); void lockinterruptibly() throws InterruptedException; boolean trylock(); boolean trylock(long time, TimeUnit unit); Condition newcondition(); void unlock; } Try for lock, but not too hard Art of Multiprocessor Programming 40
41 The Java Lock Interface public interface Lock { void lock(); void lockinterruptibly() throws InterruptedException; boolean trylock(); boolean trylock(long time, TimeUnit unit); Condition newcondition(); void unlock; } Create condition to wait on Art of Multiprocessor Programming 41
42 The Java Lock Interface public interface Lock { void lock(); void lockinterruptibly() throws InterruptedException; boolean trylock(); boolean trylock(long time, TimeUnit unit); Condition newcondition(); void unlock; } Never mind what this method does Art of Multiprocessor Programming 42
43 Lock Conditions public interface Condition { void await(); boolean await(long time, TimeUnit unit); void signal(); void signalall(); } Art of Multiprocessor Programming 43
44 Lock Conditions public interface Condition { void await(); boolean await(long time, TimeUnit unit); void signal(); void signalall(); } Release lock and wait on condition Art of Multiprocessor Programming 44
45 Lock Conditions public interface Condition { void await(); boolean await(long time, TimeUnit unit); void signal(); void signalall(); } Wake up one waiting thread Art of Multiprocessor Programming 45
46 Lock Conditions public interface Condition { void await(); boolean await(long time, TimeUnit unit); void signal(); void signalall(); } Wake up all waiting threads Art of Multiprocessor Programming 46
47 Await q.await() Releases lock associated with q Sleeps (gives up processor) Awakens (resumes running) Reacquires lock & returns Art of Multiprocessor Programming 47
48 Signal q.signal(); Awakens one waiting thread Which will reacquire lock Art of Multiprocessor Programming 48
49 Signal All q.signalall(); Awakens all waiting threads Which will each reacquire lock Art of Multiprocessor Programming 49
50 Critical Section A Monitor Lock lock() waiting room unlock() Art of Multiprocessor Programming 50
51 Critical Section Unsuccessful Deq lock() waiting room deq() await() Oh no, empty! Art of Multiprocessor Programming 51
52 Critical Section Another One lock() waiting room deq() await() Oh no, empty! Art of Multiprocessor Programming 52
53 Critical Section Enqueuer to the Rescue lock() Yawn! Yawn! waiting room enq( ) signalall() unlock() Art of Multiprocessor Programming 53
54 Critical Section Monitor Signalling waiting room Yawn! Yawn! Awakened thread might still lose lock to outside contender Art of Multiprocessor Programming 54
55 Critical Section Dequeuers Signalled waiting room Yawn! Found it Art of Multiprocessor Programming 55
56 Critical Section Dequeuers Signaled waiting room Yawn! Still empty! Art of Multiprocessor Programming 56
57 Critical Section Dollar Short + Day Late waiting room Art of Multiprocessor Programming 57
58 Java Synchronized Methods public class Queue<T> { int head = 0, tail = 0; T[QSIZE] items; public synchronized T deq() { while (tail head == 0) wait(); T result = items[head % QSIZE]; head++; notifyall(); return result; } }} Art of Multiprocessor Programming 58
59 Java Synchronized Methods public class Queue<T> { } }} int head = 0, tail = 0; T[QSIZE] items; public synchronized T deq() { while (tail head == 0) wait(); T result = items[head % QSIZE]; head++; notifyall(); return result; Each object has an implicit lock with an implicit condition Art of Multiprocessor Programming 59
60 Java Synchronized Methods public class Queue<T> { int head = 0, tail = 0; T[QSIZE] items; Lock on entry, unlock on return public synchronized T deq() { while (tail head == 0) wait(); T result = items[head % QSIZE]; head++; notifyall(); return result; } }} Art of Multiprocessor Programming 60
61 Java Synchronized Methods public class Queue<T> { int head = 0, tail = 0; T[QSIZE] items; Wait on implicit condition public synchronized T deq() { while (tail head == 0) wait(); T result = items[head % QSIZE]; head++; this.notifyall(); return result; } }} Art of Multiprocessor Programming 61
62 Java Synchronized Methods public class Queue<T> { int head = 0, tail = 0; T[QSIZE] items; Signal all threads waiting on condition public synchronized T deq() { while (tail head == 0) this.wait(); T result = items[head % QSIZE]; head++; notifyall(); return result; } }} Art of Multiprocessor Programming 62
63 (Pop!) The Bounded Queue public class BoundedQueue<T> { ReentrantLock enqlock, deqlock; Condition notemptycondition, notfullcondition; AtomicInteger size; Node head; Node tail; int capacity; enqlock = new ReentrantLock(); notfullcondition = enqlock.newcondition(); deqlock = new ReentrantLock(); notemptycondition = deqlock.newcondition(); } Art of Multiprocessor Programming 63
64 Critical Section Beware Lost Wake-Ups lock() Yawn! waiting room enq( ) Queue empty so signal () unlock() Art of Multiprocessor Programming 64
65 Critical Section lock() Lost Wake-Up Yawn! waiting room enq( ) Queue not empty so no need to signal unlock() Art of Multiprocessor Programming 65
66 Critical Section Lost Wake-Up Yawn! waiting room Art of Multiprocessor Programming 66
67 Critical Section Lost Wake-Up waiting room Found it Art of Multiprocessor Programming 67
68 Critical Section What s Wrong Here? waiting room Still waiting.! Art of Multiprocessor Programming 68
69 Solution to Lost Wakeup Always use signalall() and notifyall() Not signal() and notify() Art of Multiprocessor Programming 69
70 The enq() & deq() Methods Share no locks That s good But do share an atomic counter Accessed on every method call That s not so good Can we alleviate this bottleneck? Art of Multiprocessor Programming 70
71 Split the Counter The enq() method Increments only Cares only if value is capacity The deq() method Decrements only Cares only if value is zero Art of Multiprocessor Programming 71
72 Split Counter Enqueuer increments enqsize Dequeuer decrements deqsize When enqueuer runs out Locks deqlock computes size = enqsize - DeqSize Intermittent synchronization Not with each method call Need both locks! (careful ) Art of Multiprocessor Programming 72
73 A Lock-Free Queue head tail Sentinel Art of Multiprocessor Programming 73
74 Compare and Set CAS Art of Multiprocessor Programming 74
75 Enqueue head tail enq( ) Art of Multiprocessor Programming 75
76 Enqueue head tail Art of Multiprocessor Programming 76
77 Logical Enqueue head CAS tail Art of Multiprocessor Programming 77
78 Physical Enqueue head tail CAS Art of Multiprocessor Programming 78
79 Enqueue These two steps are not atomic The tail field refers to either Actual last Node (good) Penultimate Node (not so good) Be prepared! Art of Multiprocessor Programming 79
80 Enqueue What do you do if you find A trailing tail? Stop and help fix it If tail node has non-null next field CAS the queue s tail field to tail.next As in the universal construction Art of Multiprocessor Programming 80
81 When CASs Fail During logical enqueue Abandon hope, restart Still lock-free (why?) During physical enqueue Ignore it (why?) Art of Multiprocessor Programming 81
82 Dequeuer head tail Read value Art of Multiprocessor Programming 82
83 Dequeuer Make first Node new sentinel head tail CAS Art of Multiprocessor Programming 83
84 Memory Reuse? What do we do with nodes after we dequeue them? Java: let garbage collector deal? Suppose there is no GC, or we prefer not to use it? Art of Multiprocessor Programming 84
85 Dequeuer head tail CAS Can recycle Art of Multiprocessor Programming 85
86 Simple Solution Each thread has a free list of unused queue nodes Allocate node: pop from list Free node: push onto list Deal with underflow somehow Art of Multiprocessor Programming 86
87 Why Recycling is Hard head tail Want to redirect head from gray to red zzz Free pool Art of Multiprocessor Programming 87
88 Both Nodes Reclaimed head tail zzz Free pool Art of Multiprocessor Programming 88
89 One Node Recycled head tail Yawn! Free pool Art of Multiprocessor Programming 89
90 Why Recycling is Hard head CAS tail OK, here I go! Free pool Art of Multiprocessor Programming 90
91 Recycle FAIL head tail zomg what went wrong? Free pool Art of Multiprocessor Programming 91
92 The Dreaded ABA Problem head tail Head reference has value A Thread reads value A Art of Multiprocessor Programming 92
93 Dreaded ABA continued head tail zzz Head reference has value B Node A freed Art of Multiprocessor Programming 93
94 Dreaded ABA continued head tail Yawn! Head reference has value A again Node A recycled and reinitialized Art of Multiprocessor Programming 94
95 Dreaded ABA continued head CAS tail CAS succeeds because references match, even though reference s meaning has changed Art of Multiprocessor Programming 95
96 The Dreaded ABA FAIL Is a result of CAS() semantics I blame Sun, Intel, AMD, Not with Load-Locked/Store-Conditional Good for IBM? Art of Multiprocessor Programming 96
97 Dreaded ABA A Solution Tag each pointer with a counter Unique over lifetime of node Pointer size vs word size issues Overflow? Don t worry be happy? Bounded tags? AtomicStampedReference class Art of Multiprocessor Programming 97
98 Atomic Stamped Reference AtomicStampedReference class Java.util.concurrent.atomic package Can get reference & stamp atomically Reference address S Stamp Art of Multiprocessor Programming 98
99 Concurrent Stack Methods push(x) pop() Last-in, First-out (LIFO) order Lock-Free! Art of Multiprocessor Programming 99
100 Empty Stack Top Art of Multiprocessor Programming 100
101 Push Top Art of Multiprocessor Programming 101
102 Push Top CAS Art of Multiprocessor Programming 102
103 Push Top Art of Multiprocessor Programming 103
104 Push Top Art of Multiprocessor Programming 104
105 Push Top Art of Multiprocessor Programming 105
106 Push Top CAS Art of Multiprocessor Programming 106
107 Push Top Art of Multiprocessor Programming 107
108 Pop Top Art of Multiprocessor Programming 108
109 Pop Top CAS Art of Multiprocessor Programming 109
110 Pop Top CAS mine! Art of Multiprocessor Programming 110
111 Pop Top CAS Art of Multiprocessor Programming 111
112 Pop Top Art of Multiprocessor Programming 112
113 Lock-free Stack Good No locking Bad Without GC, fear ABA Without backoff, huge contention at top In any case, no parallelism Art of Multiprocessor Programming 113
114 Big Question Are stacks inherently sequential? Reasons why Every pop() call fights for top item Reasons why not Stay tuned Art of Multiprocessor Programming 114
115 Elimination-Backoff Stack How to turn contention into parallelism Replace familiar exponential backoff With alternative elimination-backoff Art of Multiprocessor Programming 115
116 Observation Push( ) linearizable stack Pop() Yes! After an equal number of pushes and pops, stack stays the same Art of Multiprocessor Programming 116
117 Idea: Elimination Array Pick at random Push( ) stack Pop() Pick at random Elimination Array Art of Multiprocessor Programming 117
118 Push Collides With Pop continue Push( ) stack Pop() continue Yes! No need to access stack Art of Multiprocessor Programming 118
119 No Collision Push( ) stack Pop() If pushes collide or pops If no collide collision, access access stack stack Art of Multiprocessor Programming 119
120 Elimination-Backoff Stack Lock-free stack + elimination array Access Lock-free stack, If uncontended, apply operation if contended, back off to elimination array and attempt elimination Art of Multiprocessor Programming 120
121 Elimination-Backoff Stack Push( ) Pop() CAS Top If CAS fails, back off Art of Multiprocessor Programming 121
122 Dynamic Range and Delay Push( ) Pick random range and max waiting time based on level of contention encountered Art of Multiprocessor Programming 122
123 Linearizability Un-eliminated calls linearized as before Eliminated calls: linearize pop() immediately after matching push() Combination is a linearizable stack Art of Multiprocessor Programming 123
124 Un-Eliminated Linearizability pop(v 1 ) pop(v 1 ) push(v 1 ) time Art of Multiprocessor Programming 124
125 Collision Point Eliminated Linearizability pop(v 1 ) push(v 1 ) pop(v 2 ) push(v 2 ) Red calls are eliminated time Art of Multiprocessor Programming 125
126 Backoff Has Dual Effect Elimination introduces parallelism Backoff to array cuts contention on lockfree stack Elimination in array cuts down number of threads accessing lock-free stack Art of Multiprocessor Programming 126
127 Elimination Array public class EliminationArray { private static final int duration =...; private static final int timeunit =...; Exchanger<T>[] exchanger; public EliminationArray(int capacity) { exchanger = new Exchanger[capacity]; for (int i = 0; i < capacity; i++) exchanger[i] = new Exchanger<T>(); } } Art of Multiprocessor Programming 127
128 Elimination Array public class EliminationArray { private static final int duration =...; private static final int timeunit =...; Exchanger<T>[] exchanger; public EliminationArray(int capacity) { exchanger = new Exchanger[capacity]; for (int i = 0; i < capacity; i++) exchanger[i] = new Exchanger<T>(); } An array of Exchangers } Art of Multiprocessor Programming 128
129 Digression: A Lock-Free Exchanger public class Exchanger<T> { AtomicStampedReference<T> slot = new AtomicStampedReference<T>(null, 0); Art of Multiprocessor Programming 129
130 A Lock-Free Exchanger public class Exchanger<T> { AtomicStampedReference<T> slot = new AtomicStampedReference<T>(null, 0); Atomically modifiable reference + status Art of Multiprocessor Programming 130
131 Atomic Stamped Reference AtomicStampedReference class Java.util.concurrent.atomic package In C or C++: reference address S stamp Art of Multiprocessor Programming 131
132 Extracting Reference & Stamp public T get(int[] stampholder); Art of Multiprocessor Programming 132
133 Extracting Reference & Stamp public T get(int[] stampholder); Returns reference to object of type T Returns stamp at array index 0! Art of Multiprocessor Programming 133
134 Exchanger Status enum Status {EMPTY, WAITING, BUSY}; Art of Multiprocessor Programming 134
135 Exchanger Status enum Status {EMPTY, WAITING, BUSY}; Nothing yet Art of Multiprocessor Programming 135
136 Exchange Status enum Status {EMPTY, WAITING, BUSY}; Nothing yet One thread is waiting for rendez-vous Art of Multiprocessor Programming 136
137 Exchange Status enum Status {EMPTY, WAITING, BUSY}; Nothing yet One thread is waiting for rendez-vous Other threads busy with rendez-vous Art of Multiprocessor Programming 137
138 The Exchange public T Exchange(T myitem, long nanos) throws TimeoutException { long timebound = System.nanoTime() + nanos; int[] stampholder = {EMPTY}; while (true) { if (System.nanoTime() > timebound) throw new TimeoutException(); T heritem = slot.get(stampholder); int stamp = stampholder[0]; switch(stamp) { case EMPTY: // slot is free case WAITING: // someone waiting for me } } case BUSY: // others exchanging Art of Multiprocessor Programming 138
139 The Exchange public T Exchange(T myitem, long nanos) throws TimeoutException { long timebound = System.nanoTime() + nanos; int[] stampholder = {EMPTY}; while (true) { if (System.nanoTime() > timebound) throw new TimeoutException(); Item and timeout T heritem = slot.get(stampholder); int stamp = stampholder[0]; switch(stamp) { case EMPTY: // slot is free case WAITING: // someone waiting for me } } case BUSY: // others exchanging Art of Multiprocessor Programming 139
140 The Exchange public T Exchange(T myitem, long nanos) throws TimeoutException { long timebound = System.nanoTime() + nanos; int[] stampholder = {EMPTY}; while (true) { if (System.nanoTime() > timebound) throw new TimeoutException(); T heritem = slot.get(stampholder); int stamp = stampholder[0]; Array holds status switch(stamp) { case EMPTY: // slot is free case WAITING: // someone waiting for me } } case BUSY: // others exchanging Art of Multiprocessor Programming 140
141 The Exchange public T Exchange(T myitem, long nanos) throws TimeoutException { long timebound = System.nanoTime() + nanos; int[] stampholder = {0}; while (true) { if (System.nanoTime() > timebound) throw new TimeoutException(); T heritem = slot.get(stampholder); int stamp = stampholder[0]; switch(stamp) { case EMPTY: // slot is free case WAITING: // someone waiting for me case BUSY: // others exchanging } Loop until timeout }} Art of Multiprocessor Programming 141
142 The Exchange public T Exchange(T myitem, long nanos) throws TimeoutException { long timebound = System.nanoTime() + nanos; int[] stampholder = {0}; while (true) { if (System.nanoTime() > timebound) throw new TimeoutException(); T heritem = slot.get(stampholder); int stamp = stampholder[0]; switch(stamp) { case EMPTY: // slot is free case WAITING: // someone waiting for me case BUSY: // others exchanging } Get other s item and status }} Art of Multiprocessor Programming 142
143 The Exchange public T Exchange(T myitem, long nanos) throws TimeoutException { long timebound = System.nanoTime() + nanos; int[] An Exchanger stampholder has = three {0}; possible states while (true) { if (System.nanoTime() > timebound) throw new TimeoutException(); T heritem = slot.get(stampholder); int stamp = stampholder[0]; switch(stamp) { case EMPTY: // slot is free case WAITING: // someone waiting for me case BUSY: // others exchanging } }} Art of Multiprocessor Programming 143
144 Lock-free Exchanger EMPTY Art of Multiprocessor Programming 144
145 Lock-free Exchanger CAS EMPTY Art of Multiprocessor Programming 145
146 Lock-free Exchanger WAITING Art of Multiprocessor Programming 146
147 Lock-free Exchanger In search of partner WAITING Art of Multiprocessor Programming 147
148 Lock-free Exchanger Still waiting Try to exchange item and set status to BUSY Slot CAS WAITING Art of Multiprocessor Programming 148
149 Lock-free Exchanger Partner showed up, take item and reset to EMPTY Slot BUSY item status Art of Multiprocessor Programming 149
150 Lock-free Exchanger Partner showed up, take item and reset to EMPTY Slot EMPTY BUSY item status Art of Multiprocessor Programming 150
151 Exchanger State EMPTY case EMPTY: // slot is free if (slot.cas(heritem, myitem, EMPTY, WAITING)) { while (System.nanoTime() < timebound){ heritem = slot.get(stampholder); if (stampholder[0] == BUSY) { slot.set(null, EMPTY); return heritem; }} if (slot.cas(myitem, null, WAITING, EMPTY)){ throw new TimeoutException(); } else { heritem = slot.get(stampholder); slot.set(null, EMPTY); return heritem; } } break; Art of Multiprocessor Programming 151
152 Exchanger State EMPTY case EMPTY: // slot is free if (slot.cas(heritem, myitem, EMPTY, WAITING)) { while (System.nanoTime() < timebound){ heritem = slot.get(stampholder); if (stampholder[0] == BUSY) { slot.set(null, EMPTY); return heritem; Try to insert myitem and }} change state to WAITING if (slot.cas(myitem, null, WAITING, EMPTY)){ throw new TimeoutException(); } else { heritem = slot.get(stampholder); slot.set(null, EMPTY); return heritem; } } break; Art of Multiprocessor Programming 152
153 Exchanger State EMPTY case EMPTY: // slot is free if (slot.cas(heritem, myitem, EMPTY, WAITING)) { while (System.nanoTime() < timebound){ heritem = slot.get(stampholder); if (stampholder[0] == BUSY) { slot.set(null, EMPTY); return heritem; }} if (slot.cas(myitem, null, WAITING, EMPTY)){ throw new TimeoutException(); } else { Spin until either heritem = slot.get(stampholder); slot.set(null, myitem EMPTY); is taken or timeout } } break; return heritem; Art of Multiprocessor Programming 153
154 Exchanger State EMPTY case EMPTY: // slot is free if (slot.cas(heritem, myitem, EMPTY, WAITING)) { while (System.nanoTime() < timebound){ heritem = slot.get(stampholder); if (stampholder[0] == BUSY) { slot.set(null, EMPTY); return heritem; }} if (slot.cas(myitem, null, WAITING, EMPTY)){ throw new TimeoutException(); } else { heritem myitem = slot.get(stampholder); was taken, slot.set(null, EMPTY); } } break; so return heritem that was put in its place return heritem; Art of Multiprocessor Programming 154
155 Exchanger State EMPTY case EMPTY: // slot is free if Otherwise (slot.cas(heritem, we ran out myitem, of time, EMPTY, WAITING)) { while (System.nanoTime() < timebound){ try heritem to reset = slot.get(stampholder); status to EMPTY if (stampholder[0] and time out == BUSY) { slot.set(null, EMPTY); return heritem; }} if (slot.cas(myitem, null, WAITING, EMPTY)){ throw new TimeoutException(); } else { heritem = slot.get(stampholder); slot.set(null, EMPTY); return heritem; } } break; Art of Multiprocessor Programming 155
156 Exchanger State EMPTY case EMPTY: // slot is free if (slot.compareandset(heritem, myitem, WAITING, BUSY)) { while (System.nanoTime() < timebound){ If reset failed, heritem = slot.get(stampholder); if (stampholder[0] someone showed == BUSY) up after { all, slot.set(null, so take EMPTY); that item return heritem; }} if (slot.compareandset(myitem, null, WAITING, EMPTY)){throw new TimeoutException(); } else { heritem = slot.get(stampholder); slot.set(null, EMPTY); return heritem; } } break; Art of Art of Multiprocessor Programming 156 Programming Herlihy-Shavit
157 Exchanger State EMPTY case EMPTY: // slot is free if (slot.cas(heritem, myitem, EMPTY, WAITING)) { while (System.nanoTime() < timebound){ heritem = slot.get(stampholder); if (stampholder[0] == BUSY) { slot.set(null, EMPTY); return Clear heritem; slot and take that item }} if (slot.cas(myitem, null, WAITING, EMPTY)){ throw new TimeoutException(); } else { heritem = slot.get(stampholder); slot.set(null, EMPTY); return heritem; } } break; Art of Multiprocessor Programming 157
158 Exchanger State EMPTY case EMPTY: // slot is free if (slot.cas(heritem, myitem, EMPTY, WAITING)) { while (System.nanoTime() < timebound){ heritem = slot.get(stampholder); if (stampholder[0] == BUSY) { slot.set(null, EMPTY); return heritem; If initial CAS failed, }} then someone else changed status if (slot.cas(myitem, null, WAITING, EMPTY)){ throw from new TimeoutException(); EMPTY to WAITING, } else { so retry from start heritem = slot.get(stampholder); slot.set(null, EMPTY); return heritem; } } break; Art of Multiprocessor Programming 158
159 States WAITING and BUSY case WAITING: // someone waiting for me if (slot.cas(heritem, myitem, WAITING, BUSY)) return heritem; break; case BUSY: // others in middle of exchanging break; default: // impossible break; } } } } Art of Multiprocessor Programming 159
160 States WAITING and BUSY case WAITING: // someone waiting for me if (slot.cas(heritem, myitem, WAITING, BUSY)) return heritem; break; case BUSY: // others in middle of exchanging break; default: // impossible break; someone is waiting to exchange, } so try to CAS my item in } } and change state to BUSY } Art of Multiprocessor Programming 160
161 States WAITING and BUSY case WAITING: // someone waiting for me if (slot.cas(heritem, myitem, WAITING, BUSY)) return heritem; break; case BUSY: // others in middle of exchanging break; default: // impossible break; } } } } If successful, return other s item, otherwise someone else took it, so try again from start Art of Multiprocessor Programming 161
162 States WAITING and BUSY case WAITING: // someone waiting for me if (slot.cas(heritem, myitem, WAITING, BUSY)) return heritem; break; case BUSY: // others in middle of exchanging break; default: // impossible break; } } } } If BUSY, other threads exchanging, so start again Art of Multiprocessor Programming 162
163 The Exchanger Slot Exchanger is lock-free Because the only way an exchange can fail is if others repeatedly succeeded or no-one showed up The slot we need does not require symmetric exchange Art of Multiprocessor Programming 163
164 Back to the Stack: the Elimination Array public class EliminationArray { public T visit(t value, int range) throws TimeoutException { int slot = random.nextint(range); int nanodur = converttonanos(duration, timeunit)); return (exchanger[slot].exchange(value, nanodur) }} Art of Multiprocessor Programming 164
165 Elimination Array public class EliminationArray { public T visit(t value, int range) throws TimeoutException { int slot = random.nextint(range); int nanodur = converttonanos(duration, timeunit)); return (exchanger[slot].exchange(value, nanodur) }} visit the elimination array with fixed value and range Art of Multiprocessor Programming 165
166 Elimination Array public class EliminationArray { public T visit(t value, int range) throws TimeoutException { int slot = random.nextint(range); int nanodur = converttonanos(duration, timeunit)); return (exchanger[slot].exchange(value, nanodur) }} Pick a random array entry Art of Multiprocessor Programming 166
167 Elimination Array public class EliminationArray { public T visit(t value, Exchange int range) value or time out throws TimeoutException { int slot = random.nextint(range); int nanodur = converttonanos(duration, timeunit)); return (exchanger[slot].exchange(value, nanodur) }} Art of Multiprocessor Programming 167
168 Elimination Stack Push public void push(t value) {... while (true) { if (trypush(node)) { return; } else try { T othervalue = eliminationarray.visit(value,policy.range); if (othervalue == null) { return; } } Art of Multiprocessor Programming 168
169 Elimination Stack Push public void push(t value) {... while (true) { if (trypush(node)) { return; } else try { T othervalue = eliminationarray.visit(value,policy.range); if (othervalue == null) { return; } First, try to push } Art of Multiprocessor Programming 169
170 Elimination Stack Push public void push(t value) {... while (true) If I failed, { backoff & try to eliminate if (trypush(node)) { return; } else try { T othervalue = eliminationarray.visit(value,policy.range); if (othervalue == null) { return; } } Art of Multiprocessor Programming 170
171 Elimination Stack Push public void push(t value) {... while (true) { Value pushed and range to try if (trypush(node)) { return; } else try { T othervalue = eliminationarray.visit(value,policy.range); if (othervalue == null) { return; } } Art of Multiprocessor Programming 171
172 Elimination Stack Push public void push(t value) {... Only pop() leaves null, while (true) { if (trypush(node)) so elimination { was successful return; } else try { T othervalue = eliminationarray.visit(value,policy.range); if (othervalue == null) { return; } } Art of Multiprocessor Programming 172
173 Elimination Stack Push public void push(t value) {... Otherwise, retry push() on lock-free stack while (true) { if (trypush(node)) { return; } else try { T othervalue = eliminationarray.visit(value,policy.range); if (othervalue == null) { return; } } Art of Multiprocessor Programming 173
174 Elimination Stack Pop public T pop() {... while (true) { if (trypop()) { return returnnode.value; } else try { T othervalue = eliminationarray.visit(null,policy.range; if (othervalue!= null) { return othervalue; } } }} Art of Multiprocessor Programming 174
175 Elimination Stack Pop public T pop() {... while (true) { if If value (trypop()) not null, { other thread is a push(), return returnnode.value; } else so elimination succeeded try { T othervalue = eliminationarray.visit(null,policy.range; if ( othervalue!= null) { return othervalue; } } }} Art of Multiprocessor Programming 175
176 Summary We saw both lock-based and lock-free implementations of queues and stacks Don t be quick to declare a data structure inherently sequential Linearizable stack is not inherently sequential (though it is in worst case) ABA is a real problem, pay attention Art of Multiprocessor Programming 176
177 This work is licensed under a Creative Commons Attribution- ShareAlike 2.5 License. : to copy, distribute and transmit the work to adapt the work :. 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).. 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 177
178 Art of Multiprocessor Programming 178
Concurrent Queues, Monitors, and the ABA problem. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Concurrent Queues, Monitors, and the ABA problem Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Queues Often used as buffers between producers and consumers
The Five-Fold Path. Queues & Stacks. Bounded vs Unbounded. Blocking vs Non-Blocking. Concurrent Queues and Stacks. Another Fundamental Problem
Concurrent Queues and Stacks The Five-Fold Path Coarse-grained locking Fine-grained locking Optimistic synchronization Lazy synchronization Lock-free synchronization 2 Another Fundamental Problem Queues
CSE 613: Parallel Programming. Lecture 17 ( Concurrent Data Structures: Queues and Stacks )
CSE 613: Parallel Programming Lecture 17 ( Concurrent Data Structures: Queues and Stacks ) Rezaul A. Chowdhury Department of Computer Science SUNY Stony Brook Spring 2012 Desirable Properties of Concurrent
Programming Paradigms for Concurrency Lecture 3 Concurrent Objects
Programming Paradigms for Concurrency Lecture 3 Concurrent Objects Based on companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Modified by Thomas Wies New York University
Blocking Non-blocking Caveat:
Overview of Lecture 5 1 Progress Properties 2 Blocking The Art of Multiprocessor Programming. Maurice Herlihy and Nir Shavit. Morgan Kaufmann, 2008. Deadlock-free: some thread trying to get the lock eventually
Linked Lists: Locking, Lock-Free, and Beyond. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Linked Lists: Locking, Lock-Free, and Beyond Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Concurrent Objects Adding threads should not lower throughput Contention
Spin Locks and Contention. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Spin Locks and Contention Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Real world concurrency Understanding hardware architecture What is contention How to
Introduction. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Introduction Companion slides for The by Maurice Herlihy & Nir Shavit Moore s Law Transistor count still rising Clock speed flattening sharply 2 Moore s Law (in practice) 3 Nearly Extinct: the Uniprocesor
Spin Locks and Contention. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Spin Locks and Contention Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Focus so far: Correctness and Progress Models Accurate (we never lied to you) But idealized
Spin Locks and Contention
Spin Locks and Contention Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Modified for Software1 students by Lior Wolf and Mati Shomrat Kinds of Architectures
Linked Lists: Locking, Lock- Free, and Beyond. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Linked Lists: Locking, Lock- Free, and Beyond Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Coarse-Grained Synchronization Each method locks the object Avoid
Whatever can go wrong will go wrong. attributed to Edward A. Murphy. Murphy was an optimist. authors of lock-free programs LOCK FREE KERNEL
Whatever can go wrong will go wrong. attributed to Edward A. Murphy Murphy was an optimist. authors of lock-free programs LOCK FREE KERNEL 251 Literature Maurice Herlihy and Nir Shavit. The Art of Multiprocessor
Universality of Consensus. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Universality of Consensus Companion slides for The by Maurice Herlihy & Nir Shavit Turing Computability 1 0 1 1 0 1 0 A mathematical model of computation Computable = Computable on a T-Machine 2 Shared-Memory
Concurrent Skip Lists. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Concurrent Skip Lists Companion slides for The by Maurice Herlihy & Nir Shavit Set Object Interface Collection of elements No duplicates Methods add() a new element remove() an element contains() if element
CMSC 330: Organization of Programming Languages. Threads Classic Concurrency Problems
: Organization of Programming Languages Threads Classic Concurrency Problems The Dining Philosophers Problem Philosophers either eat or think They must have two forks to eat Can only use forks on either
Whatever can go wrong will go wrong. attributed to Edward A. Murphy. Murphy was an optimist. authors of lock-free programs 3.
Whatever can go wrong will go wrong. attributed to Edward A. Murphy Murphy was an optimist. authors of lock-free programs 3. LOCK FREE KERNEL 309 Literature Maurice Herlihy and Nir Shavit. The Art of Multiprocessor
The Dining Philosophers Problem CMSC 330: Organization of Programming Languages
The Dining Philosophers Problem CMSC 0: Organization of Programming Languages Threads Classic Concurrency Problems Philosophers either eat or think They must have two forks to eat Can only use forks on
Concurrent Objects and Linearizability
Chapter 3 Concurrent Objects and Linearizability 3.1 Specifying Objects An object in languages such as Java and C++ is a container for data. Each object provides a set of methods that are the only way
CMSC 330: Organization of Programming Languages. The Dining Philosophers Problem
CMSC 330: Organization of Programming Languages Threads Classic Concurrency Problems The Dining Philosophers Problem Philosophers either eat or think They must have two forks to eat Can only use forks
CS 455: INTRODUCTION TO DISTRIBUTED SYSTEMS [THREADS] Frequently asked questions from the previous class survey
![CS 455: INTRODUCTION TO DISTRIBUTED SYSTEMS [THREADS] Frequently asked questions from the previous class survey](/thumbs/95/126504862.jpg "CS 455: INTRODUCTION TO DISTRIBUTED SYSTEMS [THREADS] Frequently asked questions from the previous class survey")
CS 455: INTRODUCTION TO DISTRIBUTED SYSTEMS [THREADS] Threads block when they can t get that lock Wanna have your threads stall? Go ahead, synchronize it all The antidote to this liveness pitfall? Keeping
CMSC 330: Organization of Programming Languages
CMSC 330: Organization of Programming Languages Multithreading Multiprocessors Description Multiple processing units (multiprocessor) From single microprocessor to large compute clusters Can perform multiple
Non-blocking Array-based Algorithms for Stacks and Queues!
Non-blocking Array-based Algorithms for Stacks and Queues! Niloufar Shafiei! Department of Computer Science and Engineering York University ICDCN 09 Outline! Introduction! Stack algorithm! Queue algorithm!
Unit 6: Indeterminate Computation
Unit 6: Indeterminate Computation Martha A. Kim October 6, 2013 Introduction Until now, we have considered parallelizations of sequential programs. The parallelizations were deemed safe if the parallel
Threads and Locks, Part 2. CSCI 5828: Foundations of Software Engineering Lecture 08 09/18/2014
Threads and Locks, Part 2 CSCI 5828: Foundations of Software Engineering Lecture 08 09/18/2014 1 Goals Cover the material presented in Chapter 2 of our concurrency textbook In particular, selected material
Concurrent Objects. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Concurrent Objects Companion slides for The by Maurice Herlihy & Nir Shavit Concurrent Computation memory object object 2 Objectivism What is a concurrent object? How do we describe one? How do we implement
Lecture 7: Mutual Exclusion 2/16/12. slides adapted from The Art of Multiprocessor Programming, Herlihy and Shavit
Principles of Concurrency and Parallelism Lecture 7: Mutual Exclusion 2/16/12 slides adapted from The Art of Multiprocessor Programming, Herlihy and Shavit Time Absolute, true and mathematical time, of
Concurrent Programming using Threads
Concurrent Programming using Threads Threads are a control mechanism that enable you to write concurrent programs. You can think of a thread in an object-oriented language as a special kind of system object
27/04/2012. We re going to build Multithreading Application. Objectives. MultiThreading. Multithreading Applications. What are Threads?
Objectives MultiThreading What are Threads? Interrupting threads Thread properties By Võ Văn Hải Faculty of Information Technologies Summer 2012 Threads priorities Synchronization Callables and Futures
CMSC 330: Organization of Programming Languages
CMSC 330: Organization of Programming Languages Threads Synchronization Refers to mechanisms allowing a programmer to control the execution order of some operations across different threads in a concurrent
Programming Paradigms for Concurrency Lecture 6 Synchronization of Concurrent Objects
Programming Paradigms for Concurrency Lecture 6 Synchronization of Concurrent Objects Based on companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Modified by Thomas
MultiThreading 07/01/2013. Session objectives. Introduction. Introduction. Advanced Java Programming Course
Advanced Java Programming Course MultiThreading By Võ Văn Hải Faculty of Information Technologies Industrial University of Ho Chi Minh City Session objectives Introduction Creating thread Thread class
Linked Lists: Locking, Lock- Free, and Beyond. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Linked Lists: Locking, Lock- Free, and Beyond Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Last Lecture: Spin-Locks CS. spin lock critical section Resets lock
Advanced Java Programming Course. MultiThreading. By Võ Văn Hải Faculty of Information Technologies Industrial University of Ho Chi Minh City
Advanced Java Programming Course MultiThreading By Võ Văn Hải Faculty of Information Technologies Industrial University of Ho Chi Minh City Session objectives Introduction Creating thread Thread class
Models of concurrency & synchronization algorithms
Models of concurrency & synchronization algorithms Lecture 3 of TDA383/DIT390 (Concurrent Programming) Carlo A. Furia Chalmers University of Technology University of Gothenburg SP3 2016/2017 Today s menu
Last Lecture: Spin-Locks
Linked Lists: Locking, Lock- Free, and Beyond Last Lecture: Spin-Locks. spin lock CS critical section Resets lock upon exit Today: Concurrent Objects Adding threads should not lower throughput Contention
Non-blocking Array-based Algorithms for Stacks and Queues. Niloufar Shafiei
Non-blocking Array-based Algorithms for Stacks and Queues Niloufar Shafiei Outline Introduction Concurrent stacks and queues Contributions New algorithms New algorithms using bounded counter values Correctness
Modern High-Performance Locking
Modern High-Performance Locking Nir Shavit Slides based in part on The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Locks (Mutual Exclusion) public interface Lock { public void lock();
Shared-Memory Computability
Shared-Memory Computability 10011 Universal Object Wait-free/Lock-free computable = Threads with methods that solve n- consensus Art of Multiprocessor Programming Copyright Herlihy- Shavit 2007 93 GetAndSet
Coarse-grained and fine-grained locking Niklas Fors
Coarse-grained and fine-grained locking Niklas Fors 2013-12-05 Slides borrowed from: http://cs.brown.edu/courses/cs176course_information.shtml Art of Multiprocessor Programming 1 Topics discussed Coarse-grained
CMSC 433 Programming Language Technologies and Paradigms. Spring 2013
1 CMSC 433 Programming Language Technologies and Paradigms Spring 2013 Wait / Notify / NotifyAll Optimistic Retries Composition Follow-up (the risk I mentioned) ReentrantLock, Wait, Notify, NotifyAll Some
The Relative Power of Synchronization Methods
Chapter 5 The Relative Power of Synchronization Methods So far, we have been addressing questions of the form: Given objects X and Y, is there a wait-free implementation of X from one or more instances
Solution: a lock (a/k/a mutex) public: virtual void unlock() =0;
1 Solution: a lock (a/k/a mutex) class BasicLock { public: virtual void lock() =0; virtual void unlock() =0; ; 2 Using a lock class Counter { public: int get_and_inc() { lock_.lock(); int old = count_;
COMP 322: Fundamentals of Parallel Programming
COMP 322: Fundamentals of Parallel Programming https://wiki.rice.edu/confluence/display/parprog/comp322 Lecture 30: Advanced locking in Java Vivek Sarkar Department of Computer Science Rice University
Spin Locks and Contention. Companion slides for Chapter 7 The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Spin Locks and Contention Companion slides for Chapter 7 The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Focus so far: Correctness and Progress Models Accurate (we never lied to you)
Hashing and Natural Parallism. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Hashing and Natural Parallism Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Sequential Closed Hash Map 0 1 2 3 16 9 buckets 2 Items h(k) = k mod 4 Art of Multiprocessor
Linked Lists: The Role of Locking. Erez Petrank Technion
Linked Lists: The Role of Locking Erez Petrank Technion Why Data Structures? Concurrent Data Structures are building blocks Used as libraries Construction principles apply broadly This Lecture Designing
Lecture 10: Avoiding Locks
Lecture 10: Avoiding Locks CSC 469H1F Fall 2006 Angela Demke Brown (with thanks to Paul McKenney) Locking: A necessary evil? Locks are an easy to understand solution to critical section problem Protect
Java theory and practice: Going atomic The new atomic classes are the hidden gems of java.util.concurrent
1 of 8 Java theory and practice: Going atomic The new atomic classes are the hidden gems of java.util.concurrent Level: Intermediate Brian Goetz (brian@quiotix.com), Principal Consultant, Quiotix 23 Nov
Concurrency in Java Prof. Stephen A. Edwards
Concurrency in Java Prof. Stephen A. Edwards The Java Language Developed by James Gosling et al. at Sun Microsystems in the early 1990s Originally called Oak, first intended application was as an OS for
Spin Locks and Contention. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Spin Locks and Contention Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit MIMD Architectures memory Shared Bus Memory Contention Communication Contention Communication
CS 241 Honors Concurrent Data Structures
CS 241 Honors Concurrent Data Structures Bhuvan Venkatesh University of Illinois Urbana Champaign March 27, 2018 CS 241 Course Staff (UIUC) Lock Free Data Structures March 27, 2018 1 / 43 What to go over
Implementing Mutual Exclusion. Sarah Diesburg Operating Systems CS 3430
Implementing Mutual Exclusion Sarah Diesburg Operating Systems CS 3430 From the Previous Lecture The too much milk example shows that writing concurrent programs directly with load and store instructions
AST: scalable synchronization Supervisors guide 2002
AST: scalable synchronization Supervisors guide 00 tim.harris@cl.cam.ac.uk These are some notes about the topics that I intended the questions to draw on. Do let me know if you find the questions unclear
Introduction to Multiprocessor Synchronization
Introduction to Multiprocessor Synchronization Maurice Herlihy http://cs.brown.edu/courses/cs176/lectures.shtml Moore's Law Transistor count still rising Clock speed flattening sharply Art of Multiprocessor
Java ReentrantLock (Part 1)
Java ReentrantLock (Part 1) Douglas C. Schmidt d.schmidt@vanderbilt.edu www.dre.vanderbilt.edu/~schmidt Institute for Software Integrated Systems Vanderbilt University Nashville, Tennessee, USA Learning
Fast and Lock-Free Concurrent Priority Queues for Multi-Thread Systems
Fast and Lock-Free Concurrent Priority Queues for Multi-Thread Systems Håkan Sundell Philippas Tsigas Outline Synchronization Methods Priority Queues Concurrent Priority Queues Lock-Free Algorithm: Problems
Operating Systems. Lecture 4 - Concurrency and Synchronization. Master of Computer Science PUF - Hồ Chí Minh 2016/2017
Operating Systems Lecture 4 - Concurrency and Synchronization Adrien Krähenbühl Master of Computer Science PUF - Hồ Chí Minh 2016/2017 Mutual exclusion Hardware solutions Semaphores IPC: Message passing
CMSC421: Principles of Operating Systems
CMSC421: Principles of Operating Systems Nilanjan Banerjee Assistant Professor, University of Maryland Baltimore County nilanb@umbc.edu http://www.csee.umbc.edu/~nilanb/teaching/421/ Principles of Operating
Overview. CMSC 330: Organization of Programming Languages. Concurrency. Multiprocessors. Processes vs. Threads. Computation Abstractions
CMSC 330: Organization of Programming Languages Multithreaded Programming Patterns in Java CMSC 330 2 Multiprocessors Description Multiple processing units (multiprocessor) From single microprocessor to
CMSC 433 Programming Language Technologies and Paradigms Fall Locks & Conditions
CMSC 433 Programming Language Technologies and Paradigms Fall 2011 Locks & Conditions Intrinsic Lock Example public class RWDictionaryIntrinsicLock { Map m = new TreeMap();
Chapter 32 Multithreading and Parallel Programming
Chapter 32 Multithreading and Parallel Programming 1 Objectives To get an overview of multithreading ( 32.2). To develop task classes by implementing the Runnable interface ( 32.3). To create threads to
More Synchronization; Concurrency in Java. CS 475, Spring 2018 Concurrent & Distributed Systems
More Synchronization; Concurrency in Java CS 475, Spring 2018 Concurrent & Distributed Systems Review: Semaphores Synchronization tool that provides more sophisticated ways (than Mutex locks) for process
Locking Granularity. CS 475, Spring 2019 Concurrent & Distributed Systems. With material from Herlihy & Shavit, Art of Multiprocessor Programming
Locking Granularity CS 475, Spring 2019 Concurrent & Distributed Systems With material from Herlihy & Shavit, Art of Multiprocessor Programming Discussion: HW1 Part 4 addtolist(key1, newvalue) Thread 1
Recap. Contents. Reenterancy of synchronized. Explicit Locks: ReentrantLock. Reenterancy of synchronise (ctd) Advanced Thread programming.
Lecture 07: Advanced Thread programming Software System Components 2 Behzad Bordbar School of Computer Science, University of Birmingham, UK Recap How to deal with race condition in Java Using synchronised
CSL373: Lecture 5 Deadlocks (no process runnable) + Scheduling (> 1 process runnable)
CSL373: Lecture 5 Deadlocks (no process runnable) + Scheduling (> 1 process runnable) Past & Present Have looked at two constraints: Mutual exclusion constraint between two events is a requirement that
Stacks and Queues
Stacks and Queues 2-25-2009 1 Opening Discussion Let's look at solutions to the interclass problem. Do you have any questions about the reading? Do you have any questions about the assignment? Minute Essays
Lecture 21: Transactional Memory. Topics: Hardware TM basics, different implementations
Lecture 21: Transactional Memory Topics: Hardware TM basics, different implementations 1 Transactions New paradigm to simplify programming instead of lock-unlock, use transaction begin-end locks are blocking,
Mutual Exclusion. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Mutual Exclusion Companion slides for The by Maurice Herlihy & Nir Shavit Mutual Exclusion Today we will try to formalize our understanding of mutual exclusion We will also use the opportunity to show
CSE332: Data Abstractions Lecture 19: Mutual Exclusion and Locking
CSE332: Data Abstractions Lecture 19: Mutual Exclusion and Locking James Fogarty Winter 2012 Including slides developed in part by Ruth Anderson, James Fogarty, Dan Grossman Banking Example This code is
CS 162 Operating Systems and Systems Programming Professor: Anthony D. Joseph Spring Lecture 8: Semaphores, Monitors, & Condition Variables
CS 162 Operating Systems and Systems Programming Professor: Anthony D. Joseph Spring 2004 Lecture 8: Semaphores, Monitors, & Condition Variables 8.0 Main Points: Definition of semaphores Example of use
What's wrong with Semaphores?
Next: Monitors and Condition Variables What is wrong with semaphores? Monitors What are they? How do we implement monitors? Two types of monitors: Mesa and Hoare Compare semaphore and monitors Lecture
Concurrent Preliminaries
Concurrent Preliminaries Sagi Katorza Tel Aviv University 09/12/2014 1 Outline Hardware infrastructure Hardware primitives Mutual exclusion Work sharing and termination detection Concurrent data structures
CSE 332: Data Structures & Parallelism Lecture 17: Shared-Memory Concurrency & Mutual Exclusion. Ruth Anderson Winter 2019
CSE 332: Data Structures & Parallelism Lecture 17: Shared-Memory Concurrency & Mutual Exclusion Ruth Anderson Winter 2019 Toward sharing resources (memory) So far, we have been studying parallel algorithms
CS11 Java. Fall Lecture 7
CS11 Java Fall 2006-2007 Lecture 7 Today s Topics All about Java Threads Some Lab 7 tips Java Threading Recap A program can use multiple threads to do several things at once A thread can have local (non-shared)
Sequen&al Consistency and Linearizability
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"
Fine-grained synchronization & lock-free programming
Lecture 17: Fine-grained synchronization & lock-free programming Parallel Computer Architecture and Programming CMU 15-418/15-618, Spring 2016 Tunes Minnie the Moocher Robbie Williams (Swings Both Ways)
JFokus Finding And Solving Java Deadlocks
JFokus 03 - Finding And Solving Java Deadlocks Dr Heinz Kabutz JFokus 03 - Finding and Solving Java Deadlocks Heinz Kabutz German from Cape Town, now lives in Chania PhD Computer Science from University
G52CON: Concepts of Concurrency
G52CON: Concepts of Concurrency Lecture 11 Synchronisation in Java II Natasha Alechina School of Computer Science nza@cs.nott.ac.uk Outline of this lecture Mutual exclusion in Java continued (next lecture:
Spin Locks and Contention. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Spin Locks and Contention Companion slides for The Programming by Maurice Herlihy & Nir Shavit Focus so far: Correctness Models Accurate (we never lied to you) But idealized (so we forgot to mention a
Lecture 21: Transactional Memory. Topics: consistency model recap, introduction to transactional memory
Lecture 21: Transactional Memory Topics: consistency model recap, introduction to transactional memory 1 Example Programs Initially, A = B = 0 P1 P2 A = 1 B = 1 if (B == 0) if (A == 0) critical section
Thread-Local. Lecture 27: Concurrency 3. Dealing with the Rest. Immutable. Whenever possible, don t share resources
Thread-Local Lecture 27: Concurrency 3 CS 62 Fall 2016 Kim Bruce & Peter Mawhorter Some slides based on those from Dan Grossman, U. of Washington Whenever possible, don t share resources Easier to have
CPS 310 first midterm exam, 10/6/2014
CPS 310 first midterm exam, 10/6/2014 Your name please: Part 1. More fun with fork and exec* What is the output generated by this program? Please assume that each executed print statement completes, e.g.,
Dr.-Ing. Michael Eichberg
Dr.-Ing. Michael Eichberg Concurrent Programming (Overview of the Java concurrency model and its relationship to other models...) (some slides are based on slides by Andy Wellings) 2 Processes vs. Threads
Parallel GC. (Chapter 14) Eleanor Ainy December 16 th 2014
GC (Chapter 14) Eleanor Ainy December 16 th 2014 1 Outline of Today s Talk How to use parallelism in each of the 4 components of tracing GC: Marking Copying Sweeping Compaction 2 Introduction Till now
Chair of Software Engineering. Java and C# in depth. Carlo A. Furia, Marco Piccioni, Bertrand Meyer. Java: concurrency
Chair of Software Engineering Carlo A. Furia, Marco Piccioni, Bertrand Meyer Java: concurrency Outline Java threads thread implementation sleep, interrupt, and join threads that return values Thread synchronization
Introduction. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Introduction Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Moore s Law Transistor count still rising Clock speed flattening sharply Art of Multiprocessor Programming
Order Is A Lie. Are you sure you know how your code runs?
Order Is A Lie Are you sure you know how your code runs? Order in code is not respected by Compilers Processors (out-of-order execution) SMP Cache Management Understanding execution order in a multithreaded
CSE332: Data Abstractions Lecture 22: Shared-Memory Concurrency and Mutual Exclusion. Tyler Robison Summer 2010
CSE332: Data Abstractions Lecture 22: Shared-Memory Concurrency and Mutual Exclusion Tyler Robison Summer 2010 1 Toward sharing resources (memory) So far we ve looked at parallel algorithms using fork-join
Agenda. Lecture. Next discussion papers. Bottom-up motivation Shared memory primitives Shared memory synchronization Barriers and locks
Agenda Lecture Bottom-up motivation Shared memory primitives Shared memory synchronization Barriers and locks Next discussion papers Selecting Locking Primitives for Parallel Programming Selecting Locking
Page 1. Goals for Today" Atomic Read-Modify-Write instructions" Examples of Read-Modify-Write "
Goals for Today" CS162 Operating Systems and Systems Programming Lecture 5 Semaphores, Conditional Variables" Atomic instruction sequence Continue with Synchronization Abstractions Semaphores, Monitors
Lindsay Groves, Simon Doherty. Mark Moir, Victor Luchangco
Lindsay Groves, Simon Doherty Victoria University of Wellington Mark Moir, Victor Luchangco Sun Microsystems, Boston (FORTE, Madrid, September, 2004) Lock-based concurrency doesn t scale Lock-free/non-blocking
Computation Abstractions. Processes vs. Threads. So, What Is a Thread? CMSC 433 Programming Language Technologies and Paradigms Spring 2007
CMSC 433 Programming Language Technologies and Paradigms Spring 2007 Threads and Synchronization May 8, 2007 Computation Abstractions t1 t1 t4 t2 t1 t2 t5 t3 p1 p2 p3 p4 CPU 1 CPU 2 A computer Processes
Locks Chapter 4. Overview. Introduction Spin Locks. Queue locks. Roger Wattenhofer. Test-and-Set & Test-and-Test-and-Set Backoff lock
Locks Chapter 4 Roger Wattenhofer ETH Zurich Distributed Computing www.disco.ethz.ch Overview Introduction Spin Locks Test-and-Set & Test-and-Test-and-Set Backoff lock Queue locks 4/2 1 Introduction: From
CS510 Concurrent Systems. Jonathan Walpole
CS510 Concurrent Systems Jonathan Walpole Simple, Fast, and Practical Non-Blocking and Blocking Concurrent Queue Algorithms utline Background Non-Blocking Queue Algorithm Two Lock Concurrent Queue Algorithm
Info 408 Distributed Applications Programming Exercise sheet nb. 4
Lebanese University Info 408 Faculty of Science 2017-2018 Section I 1 Custom Connections Info 408 Distributed Applications Programming Exercise sheet nb. 4 When accessing a server represented by an RMI
Lecture 9: Introduction to Monitors
COMP 150-CCP Concurrent Programming Lecture 9: Introduction to Monitors Dr. Richard S. Hall rickhall@cs.tufts.edu Concurrent programming February 14, 2008 Abstracting Locking Details Recall our discussion
Page 1. Goals for Today" Atomic Read-Modify-Write instructions" Examples of Read-Modify-Write "
Goals for Today" CS162 Operating Systems and Systems Programming Lecture 5 Semaphores, Conditional Variables" Atomic instruction sequence Continue with Synchronization Abstractions Semaphores, Monitors
Synchronization in Concurrent Programming. Amit Gupta
Synchronization in Concurrent Programming Amit Gupta Announcements Project 1 grades are out on blackboard. Detailed Grade sheets to be distributed after class. Project 2 grades should be out by next Thursday.
PROCESS SYNCHRONIZATION
PROCESS SYNCHRONIZATION Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Semaphores Classic Problems of Synchronization Monitors Synchronization
Outline of lecture. i219 Software Design Methodology 10. Multithreaded programming. Kazuhiro Ogata (JAIST)
i219 Software Design Methodology 10. Multithreaded programming Kazuhiro Ogata (JAIST) Outline of lecture 2 Thread Race condition Synchronization Deadlock Bounded buffer problem Thread (1) 3 Units of execution.