Linked Lists: Locking, Lock-Free, and Beyond. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
|
|
|
- Lindsey Cross
- 5 years ago
- Views:
Transcription
1 Linked Lists: Locking, Lock-Free, and Beyond Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
2 Concurrent Objects Adding threads should not lower throughput Contention effects Mostly fixed by scalable locks Art of Multiprocessor Programming 2
3 Concurrent Objects Adding threads should not lower throughput Contention effects Mostly fixed by scalable locks Should increase throughput Not possible if inherently sequential Surprising things are parallelizable Art of Multiprocessor Programming 3
4 Coarse-Grained Synchronization Each method locks the object Avoid contention using scalable locks Art of Multiprocessor Programming 4
5 Coarse-Grained Synchronization Each method locks the object Avoid contention using scalable locks Easy to reason about In simple cases Art of Multiprocessor Programming 5
6 Coarse-Grained Synchronization Each method locks the object Avoid contention using scalable locks Easy to reason about In simple cases So, are we done? Art of Multiprocessor Programming 6
7 Coarse-Grained Synchronization Sequential bottleneck Threads stand in line Art of Multiprocessor Programming 7
8 Coarse-Grained Synchronization Sequential bottleneck Threads stand in line Adding more threads Does not improve throughput Struggle to keep it from getting worse Art of Multiprocessor Programming 8
9 Coarse-Grained Synchronization Sequential bottleneck Threads stand in line Adding more threads Does not improve throughput Struggle to keep it from getting worse So why even use a multiprocessor? Well, some apps inherently parallel Art of Multiprocessor Programming 9
10 This Lecture Introduce four patterns Bag of tricks Methods that work more than once Art of Multiprocessor Programming 10
11 This Lecture Introduce four patterns Bag of tricks Methods that work more than once For highly-concurrent objects Concurrent access More threads, more throughput Art of Multiprocessor Programming 11
12 First: Fine-Grained Synchronization Instead of using a single lock Split object into Independently-synchronized components Methods conflict when they access The same component At the same time Art of Multiprocessor Programming 12
13 Second: Optimistic Synchronization Search without locking Art of Multiprocessor Programming 13
14 Second: Optimistic Synchronization Search without locking If you find it, lock and check OK: we are done Oops: start over Art of Multiprocessor Programming 14
15 Second: Optimistic Synchronization Search without locking If you find it, lock and check OK: we are done Oops: start over Evaluation Usually cheaper than locking, but Mistakes are expensive Art of Multiprocessor Programming 15
16 Third: Lazy Synchronization Postpone hard work Removing components is tricky Logical removal Mark component to be deleted Physical removal Do what needs to be done Art of Multiprocessor Programming 16
17 Fourth: Lock-Free Synchronization Don t use locks at all Use compareandset() & relatives Art of Multiprocessor Programming 17
18 Fourth: Lock-Free Synchronization Don t use locks at all Use compareandset() & relatives Advantages No Scheduler Assumptions/Support Art of Multiprocessor Programming 18
19 Fourth: Lock-Free Synchronization Don t use locks at all Use compareandset() & relatives Advantages No Scheduler Assumptions/Support Disadvantages Complex Sometimes high overhead Art of Multiprocessor Programming 19
20 Linked List Illustrate these patterns Using a list-based Set Common application Building block for other apps Art of Multiprocessor Programming 20
21 Set Interface Unordered collection of items Art of Multiprocessor Programming 21
22 Set Interface Unordered collection of items No duplicates Art of Multiprocessor Programming 22
23 Set Interface Unordered collection of items No duplicates Methods add(x) put x in set remove(x) take x out of set contains(x) tests if x in set Art of Multiprocessor Programming 23
24 List-Based Sets public interface Set<T> { public boolean add(t x); public boolean remove(t x); public boolean contains(t x); } Art of Multiprocessor Programming 24
25 List-Based Sets public interface Set<T> { public boolean add(t x); public boolean remove(t x); public boolean contains(t x); } Add item to set Art of Multiprocessor Programming 25
26 List-Based Sets public interface Set<T> { public boolean add(t x); public boolean remove(t x); public boolean contains(tt x); } Remove item from set Art of Multiprocessor Programming 26
27 List-Based Sets public interface Set<T> { public boolean add(t x); public boolean remove(t x); public boolean contains(t x); } Is item in set? Art of Multiprocessor Programming 27
28 List Node public class Node { public T item; public int key; public Node next; } Art of Multiprocessor Programming 28
29 List Node public class Node { public T item; public int key; public Node next; } item of interest Art of Multiprocessor Programming 29
30 List Node public class Node { public T item; public int key; public Node next; } Usually hash code Art of Multiprocessor Programming 30
31 List Node public class Node { public T item; public int key; public Node next; } Reference to next node Art of Multiprocessor Programming 31
32 The List-Based Set - a b c + Sorted with Sentinel nodes (min & max possible keys) Art of Multiprocessor Programming 32
33 Reasoning about Concurrent Objects Invariant Property that always holds Art of Multiprocessor Programming 33
34 Reasoning about Concurrent Objects Invariant Property that always holds Established because True when object is created Truth preserved by each method Each step of each method Art of Multiprocessor Programming 34
35 Sequential List Based Set add() a c d remove() a b c Art of Multiprocessor Programming 41
36 Sequential List Based Set add() a c d remove() b a b c Art of Multiprocessor Programming 42
37 Coarse-Grained Locking a b d Art of Multiprocessor Programming 43
38 Coarse-Grained Locking a b d c Art of Multiprocessor Programming 44
39 Coarse-Grained Locking a b d honk! honk! c Simple but hotspot + bottleneck Art of Multiprocessor Programming 45
40 Coarse-Grained Locking Easy, same as synchronized methods One lock to rule them all Art of Multiprocessor Programming 46
41 Coarse-Grained Locking Easy, same as synchronized methods One lock to rule them all Simple, clearly correct Deserves respect! Works poorly with contention Queue locks help But bottleneck still an issue Art of Multiprocessor Programming 47
42 Fine-grained Locking Requires careful thought Do not meddle in the affairs of wizards, for they are subtle and quick to anger Art of Multiprocessor Programming 48
43 Fine-grained Locking Requires careful thought Do not meddle in the affairs of wizards, for they are subtle and quick to anger Split object into pieces Each piece has own lock Methods that work on disjoint pieces need not exclude each other Art of Multiprocessor Programming 49
44 Hand-over-Hand locking a b c Art of Multiprocessor Programming 50
45 Hand-over-Hand locking a b c Art of Multiprocessor Programming 51
46 Hand-over-Hand locking a b c Art of Multiprocessor Programming 52
47 Hand-over-Hand locking a b c Art of Multiprocessor Programming 53
48 Hand-over-Hand locking a b c Art of Multiprocessor Programming 54
49 Removing a Node a b c d remove(b) Art of Multiprocessor Programming 55
50 Removing a Node a b c d remove(b) Art of Multiprocessor Programming 56
51 Removing a Node a b c d remove(b) Art of Multiprocessor Programming 57
52 Removing a Node a b c d remove(b) Art of Multiprocessor Programming 58
53 Removing a Node a b c d remove(b) Art of Multiprocessor Programming 59
54 Removing a Node a c d remove(b) Why hold 2 locks? Art of Multiprocessor Programming 60
55 Concurrent Removes a b c d remove(b) remove(c) Art of Multiprocessor Programming 61
56 Concurrent Removes a b c d remove(b) remove(c) Art of Multiprocessor Programming 62
57 Concurrent Removes a b c d remove(b) remove(c) Art of Multiprocessor Programming 63
58 Concurrent Removes a b c d remove(b) remove(c) Art of Multiprocessor Programming 64
59 Concurrent Removes a b c d remove(b) remove(c) Art of Multiprocessor Programming 65
60 Concurrent Removes a b c d remove(b) remove(c) Art of Multiprocessor Programming 66
61 Concurrent Removes a b c d remove(b) remove(c) Art of Multiprocessor Programming 67
62 Concurrent Removes a b c d remove(b) remove(c) Art of Multiprocessor Programming 68
63 Concurrent Removes a b c d remove(b) remove(c) Art of Multiprocessor Programming 69
64 Concurrent Removes a b c d remove(b) remove(c) Art of Multiprocessor Programming 70
65 Uh, Oh a c d remove(b) remove(c) Art of Multiprocessor Programming 71
66 Uh, Oh Bad news, c not removed a c d remove(b) remove(c) Art of Multiprocessor Programming 72
67 Problem To delete node c Swing node b s next field to d a b c Problem is, Someone deleting b concurrently could direct a pointer a b c to c Art of Multiprocessor Programming 73
68 Insight If a node is locked No one can delete node s successor If a thread locks Node to be deleted And its predecessor Then it works Art of Multiprocessor Programming 74
69 Hand-Over-Hand Again a b c d remove(b) Art of Multiprocessor Programming 75
70 Hand-Over-Hand Again a b c d remove(b) Art of Multiprocessor Programming 76
71 Hand-Over-Hand Again a b c d remove(b) Art of Multiprocessor Programming 77
72 Hand-Over-Hand Again a b c d remove(b) Found it! Art of Multiprocessor Programming 78
73 Hand-Over-Hand Again a b c d remove(b) Found it! Art of Multiprocessor Programming 79
74 Hand-Over-Hand Again a c d remove(b) Art of Multiprocessor Programming 80
75 Removing a Node a b c d remove(b) remove(c) Art of Multiprocessor Programming 81
76 Removing a Node a b c d remove(b) remove(c) Art of Multiprocessor Programming 82
77 Removing a Node a b c d remove(b) remove(c) Art of Multiprocessor Programming 83
78 Removing a Node a b c d remove(b) remove(c) Art of Multiprocessor Programming 84
79 Removing a Node a b c d remove(b) remove(c) Art of Multiprocessor Programming 85
80 Removing a Node a b c d remove(b) remove(c) Art of Multiprocessor Programming 86
81 Removing a Node a b c d remove(b) remove(c) Art of Multiprocessor Programming 87
82 Removing a Node a b c d remove(b) remove(c) Art of Multiprocessor Programming 88
83 Removing a Node a b c d Must acquire Lock for b remove(c) Art of Multiprocessor Programming 89
84 Removing a Node a b c d Cannot acquire lock for b remove(c) Art of Multiprocessor Programming 90
85 Removing a Node a b c d Wait! remove(c) Art of Multiprocessor Programming 91
86 Removing a Node a b d Proceed to remove(b) Art of Multiprocessor Programming 92
87 Removing a Node a b d remove(b) Art of Multiprocessor Programming 93
88 Removing a Node a b d remove(b) Art of Multiprocessor Programming 94
89 Removing a Node a d remove(b) Art of Multiprocessor Programming 95
90 Removing a Node a d Art of Multiprocessor Programming 96
91 Adding Nodes To add node e Must lock predecessor Must lock successor Neither can be deleted (Is successor lock actually required?) Art of Multiprocessor Programming 104
92 Drawbacks Better than coarse-grained lock Threads can traverse in parallel Still not ideal Long chain of acquire/release Inefficient Art of Multiprocessor Programming 105
93 Optimistic Synchronization Find nodes without locking Lock nodes Check that everything is OK Art of Multiprocessor Programming 106
94 Optimistic: Traverse without Locking a b d e add(c) Aha! Art of Multiprocessor Programming 107
95 Optimistic: Lock and Load a b d e add(c) Art of Multiprocessor Programming 108
96 Optimistic: Lock and Load c a b d e add(c) Art of Multiprocessor Programming 109
97 What could go wrong? a b d e add(c) Aha! Art of Multiprocessor Programming 110
98 What could go wrong? a b d e add(c) Art of Multiprocessor Programming 111
99 What could go wrong? a b d e remove(b) Art of Multiprocessor Programming 112
100 What could go wrong? a b d e remove(b) Art of Multiprocessor Programming 113
101 What could go wrong? a b d e add(c) Art of Multiprocessor Programming 114
102 What could go wrong? c a b d e add(c) Art of Multiprocessor Programming 115
103 What could go wrong? a d e add(c) Uh-oh Art of Multiprocessor Programming 116
104 Validate Part 1 a b d e add(c) Yes, b still reachable from head Art of Multiprocessor Programming 117
105 What Else Could Go Wrong? a b d e add(c) Aha! Art of Multiprocessor Programming 118
106 What Else Coould Go Wrong? a b d e add(c) add(b ) Art of Multiprocessor Programming 119
107 What Else Coould Go Wrong? a b d e add(c) b add(b ) Art of Multiprocessor Programming 120
108 What Else Could Go Wrong? a b d e add(c) b Art of Multiprocessor Programming 121
109 What Else Could Go Wrong? c a b d e add(c) Art of Multiprocessor Programming 122
110 Validate Part 2 (while holding locks) a b d e add(c) Yes, b still points to d Art of Multiprocessor Programming 123
111 Invariants Careful: we may traverse deleted nodes But we establish properties by Validation After we lock target nodes Art of Multiprocessor Programming 124
112 Correctness If Nodes b and c both locked Node b still accessible Node c still successor to b Then Neither will be deleted OK to delete and return true Art of Multiprocessor Programming 125
113 Unsuccessful Remove a b d e remove(c) Aha! Art of Multiprocessor Programming 126
114 Validate (1) a b d e remove(c) Yes, b still reachable from head Art of Multiprocessor Programming 127
115 Validate (2) a b d e remove(c) Yes, b still points to d Art of Multiprocessor Programming 128
116 OK Computer a b d e remove(c) return false Art of Multiprocessor Programming 129
117 Correctness If Nodes b and d both locked Node b still accessible Node d still successor to b Then Neither will be deleted No thread can add c after b OK to return false Art of Multiprocessor Programming 130
118 Optimistic List Limited hot-spots Targets of add(), remove(), contains() No contention on traversals Moreover Traversals are wait-free Food for thought Art of Multiprocessor Programming 131
119 So Far, So Good Much less lock acquisition/release Performance Concurrency Problems Need to traverse list twice contains() method acquires locks Art of Multiprocessor Programming 132
120 Evaluation Optimistic is effective if cost of scanning twice without locks is less than cost of scanning once with locks Drawback contains() acquires locks 90% of calls in many apps Art of Multiprocessor Programming 133
121 Lazy List Like optimistic, except Scan once contains(x) never locks Key insight Removing nodes causes trouble Do it lazily Art of Multiprocessor Programming 134
122 Lazy List remove() Scans list (as before) Locks predecessor & current (as before) Logical delete Marks current node as removed (new!) Physical delete Redirects predecessor s next (as before) Art of Multiprocessor Programming 135
123 Lazy Removal a b c d Art of Multiprocessor Programming 136
124 Lazy Removal a b c d Present in list Art of Multiprocessor Programming 137
125 Lazy Removal a b c d Logically deleted Art of Multiprocessor Programming 138
126 Lazy Removal a b c d Physically deleted Art of Multiprocessor Programming 139
127 Lazy Removal a b d Physically deleted Art of Multiprocessor Programming 140
128 Lazy List All Methods Scan through locked and marked nodes Removing a node doesn t slow down other method calls Must still lock pred and curr nodes. Art of Multiprocessor Programming 141
129 Validation No need to rescan list! Check that pred is not marked Check that curr is not marked Check that pred points to curr Art of Multiprocessor Programming 142
130 Business as Usual a b c Art of Multiprocessor Programming 143
131 Business as Usual a b c Art of Multiprocessor Programming 144
132 Business as Usual a b c Art of Multiprocessor Programming 145
133 Business as Usual a b c remove(b) Art of Multiprocessor Programming 146
134 Business as Usual a b c a not marked Art of Multiprocessor Programming 147
135 Business as Usual a b c a still points to b Art of Multiprocessor Programming 148
136 Business as Usual a b c Logical delete Art of Multiprocessor Programming 149
137 Business as Usual a b c physical delete Art of Multiprocessor Programming 150
138 Business as Usual a b c Art of Multiprocessor Programming 151
139 Invariant An item is in the set if not marked reachable from head and if not yet traversed it is reachable from pred Art of Multiprocessor Programming 152
140 Validation private boolean validate(node pred, Node curr) { return!pred.marked &&!curr.marked && pred.next == curr); } Art of Multiprocessor Programming 153
141 List Validate Method private boolean validate(node pred, Node curr) { return!pred.marked &&!curr.marked && pred.next == curr); } Predecessor not Logically removed Art of Multiprocessor Programming 154
142 List Validate Method private boolean validate(node pred, Node curr) { return!pred.marked &&!curr.marked && pred.next == curr); } Current not Logically removed Art of Multiprocessor Programming 155
143 List Validate Method private boolean validate(node pred, Node curr) { return!pred.marked &&!curr.marked && pred.next == curr); } Predecessor still Points to current Art of Multiprocessor Programming 156
144 Contains public boolean contains(item item) { int key = item.hashcode(); Node curr = this.head; while (curr.key < key) { curr = curr.next; } return curr.key == key &&!curr.marked; } Start at the head Art of Multiprocessor Programming 157
145 Contains public boolean contains(item item) { int key = item.hashcode(); Node curr = this.head; while (curr.key < key) { curr = curr.next; } return curr.key == key &&!curr.marked; } Search key range Art of Multiprocessor Programming 158
146 Contains public boolean contains(item item) { int key = item.hashcode(); Node curr = this.head; while (curr.key < key) { curr = curr.next; } return curr.key == key &&!curr.marked; } Traverse without locking (nodes may have been removed) Art of Multiprocessor Programming 159
147 Contains public boolean contains(item item) { int key = item.hashcode(); Node curr = this.head; while (curr.key < key) { curr = curr.next; } return curr.key == key &&!curr.marked; } Present and undeleted? Art of Multiprocessor Programming 160
148 Summary: Wait-free Contains a 0 b 0 d c 10 e 0 Use Mark bit + list ordering 1. Not marked in the set 2. Marked or missing not in the set Art of Multiprocessor Programming 161
149 Lazy List a 0 b 0 d c 10 e 0 Lazy add() and remove() + Wait-free contains() Art of Multiprocessor Programming 162
150 Evaluation Good: contains() doesn t lock In fact, its wait-free! Good because typically high % contains() Uncontended calls don t re-traverse Bad Contended add() and remove() calls do retraverse Traffic jam if one thread delays Art of Multiprocessor Programming 163
151 Traffic Jam Any concurrent data structure based on mutual exclusion has a weakness If one thread Enters critical section And eats the big muffin Cache miss, page fault, descheduled Everyone else using that lock is stuck! Need to trust the scheduler. Art of Multiprocessor Programming 164
152 Reminder: Lock-Free Data No matter what Structures Guarantees minimal progress in any execution i.e. Some thread will always complete a method call Even if others halt at malicious times Implies that implementation can t use locks Art of Multiprocessor Programming 165
153 Lock-free Lists Next logical step Wait-free contains() lock-free add() and remove() Use only compareandset() What could go wrong? Art of Multiprocessor Programming 166
154 Lock-free Lists Logical Removal a 0 b 0 c 10 e 0 Use CAS to verify pointer is correct Physical Removal Not enough! Art of Multiprocessor Programming 167
155 Problem Logical Removal a 0 b 0 c 10 e 0 Physical Removal d 0 Node added Art of Multiprocessor Programming 168
156 The Solution: Combine Bit and Pointer Logical Removal = Set Mark Bit a 0 b 0 c 10 e 0 Mark-Bit and Pointer are CASed as one (AtomicMarkableReference) Physical Removal CAS d 0 Failed CAS: Node not added after logical Removal Art of Multiprocessor Programming 169
157 Solution Use AtomicMarkableReference Atomically Swing reference and Update flag Remove in two steps Set mark bit in next field Redirect predecessor s pointer Art of Multiprocessor Programming 170
158 Removing a Node a b CAS c d remove c Art of Multiprocessor Programming 172
159 Removing a Node failed a CAS b CAS c d remove b remove c Art of Multiprocessor Programming 173
160 Removing a Node a b c d remove b remove c Art of Multiprocessor Programming 174
161 Removing a Node a d remove b remove c Art of Multiprocessor Programming 175
162 Traversing the List Q: what do you do when you find a logically deleted node in your path? A: finish the job. CAS the predecessor s next field Proceed (repeat as needed) Art of Multiprocessor Programming 176
163 Lock-Free Traversal (only Add and Remove) pred pred curr curr CAS a b c d Uh-oh Art of Multiprocessor Programming 177
164 Performance On 16 node shared memory machine Benchmark throughput of Java List-based Set algs. Vary % of Contains() method Calls. Art of Multiprocessor Programming 178
165 High Contains Ratio Lock-free Lazy list Coarse Grained Fine Lock-coupling Art of Multiprocessor Programming 179
166 Low Contains Ratio Lock-free Lazy list Coarse Grained Fine Lock-coupling Art of Multiprocessor Programming 180
167 As Contains Ratio Increases Lock-free Lazy list Coarse Grained Fine Lock-coupling % Contains() Art of Multiprocessor Programming 181
168 Summary Coarse-grained locking Fine-grained locking Optimistic synchronization Lock-free synchronization Art of Multiprocessor Programming 182
169 To Lock or Not to Lock Locking vs. Non-blocking: Extremist views on both sides The answer: nobler to compromise, combine locking and non-blocking Example: Lazy list combines blocking add() and remove() and a wait-free contains() Remember: Blocking/non-blocking is a property of a method Art of Multiprocessor Programming 183
170 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 184
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
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
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
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
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
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
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
Concurrency. Part 2, Chapter 10. Roger Wattenhofer. ETH Zurich Distributed Computing
Concurrency Part 2, Chapter 10 Roger Wattenhofer ETH Zurich Distributed Computing www.disco.ethz.ch Overview Concurrent Linked List Fine-grained synchronization Optimistic synchronization Lazy synchronization
Concurrent Data Structures
Concurrent Data Structures Chapter 8 Roger Wattenhofer ETH Zurich Distributed Computing www.disco.ethz.ch Overview Concurrent Linked List Fine-grained synchronization Optimistic synchronization Lazy synchronization
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
The Art of Multiprocessor Programming Copyright 2007 Elsevier Inc. All rights reserved. October 3, 2007 DRAFT COPY
The Art of Multiprocessor Programming Copyright 2007 Elsevier Inc. All rights reserved Maurice Herlihy October 3, 2007 Nir Shavit 2 Contents 1 Introduction 13 1.1 Shared Objects and Synchronization..............
Introduction to Concurrency and Multicore Programming. Slides adapted from Art of Multicore Programming by Herlihy and Shavit
Introduction to Concurrency and Multicore Programming Slides adapted from Art of Multicore Programming by Herlihy and Shavit Overview Introduction Mutual Exclusion Linearizability Concurrent Data Structure
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
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_;
Coarse-Grained Synchronization
Coarse-Grained Synchronization Ogni metodo opera mediante un lock sull oggetto Code di attesa per operare sull oggetto Nozione di correttezza (linearizability) Modello astratto basato sulla nozione di
Non-Blocking Synchronization
Herlihy Ch 9. Linked Lists: The Role of Locking Non-Blocking Synchronization BJÖRN A. JOHNSSON Overview? So far: Coarse- and fine-grained synchronization Optimistic synchronization Lazy synchronization
Locking. Part 2, Chapter 7. Roger Wattenhofer. ETH Zurich Distributed Computing
Locking Part 2, Chapter 7 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 Concurrent
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
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
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
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
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
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
Parallel linked lists
Parallel linked lists Lecture 10 of TDA384/DIT391 (Principles of Conent Programming) Carlo A. Furia Chalmers University of Technology University of Gothenburg SP3 2017/2018 Today s menu The burden of locking
Practice: Small Systems Part 2, Chapter 3
Practice: Small Systems Part 2, Chapter 3 Roger Wattenhofer Overview Introduction Spin Locks Test and Set & Test and Test and Set Backoff lock Queue locks Concurrent Linked List Fine grained synchronization
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
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
Distributed Computing Group
Distributed Computing Group HS 2009 Prof. Dr. Roger Wattenhofer, Thomas Locher, Remo Meier, Benjamin Sigg Assigned: December 11, 2009 Discussion: none Distributed Systems Theory exercise 6 1 ALock2 Have
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
Building Efficient Concurrent Graph Object through Composition of List-based Set
Building Efficient Concurrent Graph Object through Composition of List-based Set Sathya Peri Muktikanta Sa Nandini Singhal Department of Computer Science & Engineering Indian Institute of Technology Hyderabad
Concurrent Data Structures Concurrent Algorithms 2016
Concurrent Data Structures Concurrent Algorithms 2016 Tudor David (based on slides by Vasileios Trigonakis) Tudor David 11.2016 1 Data Structures (DSs) Constructs for efficiently storing and retrieving
A Concurrent Skip List Implementation with RTM and HLE
A Concurrent Skip List Implementation with RTM and HLE Fan Gao May 14, 2014 1 Background Semester Performed: Spring, 2014 Instructor: Maurice Herlihy The main idea of my project is to implement a skip
Introduction. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit. Art of Multiprocessor Programming
Introduction Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Art of Multiprocessor Programming Moore s Law Transistor count still rising Clock speed flattening
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
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();
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
PERFORMANCE ANALYSIS AND OPTIMIZATION OF SKIP LISTS FOR MODERN MULTI-CORE ARCHITECTURES
PERFORMANCE ANALYSIS AND OPTIMIZATION OF SKIP LISTS FOR MODERN MULTI-CORE ARCHITECTURES Anish Athalye and Patrick Long Mentors: Austin Clements and Stephen Tu 3 rd annual MIT PRIMES Conference Sequential
Goldibear and the 3 Locks. Programming With Locks Is Tricky. More Lock Madness. And To Make It Worse. Transactional Memory: The Big Idea
Programming With Locks s Tricky Multicore processors are the way of the foreseeable future thread-level parallelism anointed as parallelism model of choice Just one problem Writing lock-based multi-threaded
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
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
Programming Paradigms for Concurrency Introduction
Programming Paradigms for Concurrency Introduction Based on companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Modified by Thomas Wies New York University Moore
Design and Evaluation of Scalable Software
Design and Evaluation of Scalable Software Damian Dechev 1,2 1: University of Central Florida, CSE S3 Lab, http://cse.eecs.ucf.edu Orlando, FL 2: Sandia Labs, Livermore, CA Traditional Scaling Process
Locking. Part 2, Chapter 11. Roger Wattenhofer. ETH Zurich Distributed Computing
Locking Part 2, Chapter 11 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 11/2 Introduction:
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
CS 31: Introduction to Computer Systems : Threads & Synchronization April 16-18, 2019
CS 31: Introduction to Computer Systems 22-23: Threads & Synchronization April 16-18, 2019 Making Programs Run Faster We all like how fast computers are In the old days (1980 s - 2005): Algorithm too slow?
Integrating Transactionally Boosted Data Structures with STM Frameworks: A Case Study on Set
Integrating Transactionally Boosted Data Structures with STM Frameworks: A Case Study on Set Ahmed Hassan Roberto Palmieri Binoy Ravindran Virginia Tech hassan84@vt.edu robertop@vt.edu binoy@vt.edu Abstract
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
Thread Synchronization: Foundations. Properties. Safety properties. Edsger s perspective. Nothing bad happens
Edsger s perspective Testing can only prove the presence of bugs Thread Synchronization: Foundations Properties Property: a predicate that is evaluated over a run of the program (a trace) every message
Concurrent Queues and Stacks. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit
Concurrent Queues and Stacks Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit The Five-Fold Path Coarse-grained locking Fine-grained locking Optimistic synchronization
Lecture 9: Multiprocessor OSs & Synchronization. CSC 469H1F Fall 2006 Angela Demke Brown
Lecture 9: Multiprocessor OSs & Synchronization CSC 469H1F Fall 2006 Angela Demke Brown The Problem Coordinated management of shared resources Resources may be accessed by multiple threads Need to control
6.852: Distributed Algorithms Fall, Class 20
6.852: Distributed Algorithms Fall, 2009 Class 20 Today s plan z z z Transactional Memory Reading: Herlihy-Shavit, Chapter 18 Guerraoui, Kapalka, Chapters 1-4 Next: z z z Asynchronous networks vs asynchronous
HydraVM: Mohamed M. Saad Mohamed Mohamedin, and Binoy Ravindran. Hot Topics in Parallelism (HotPar '12), Berkeley, CA
HydraVM: Mohamed M. Saad Mohamed Mohamedin, and Binoy Ravindran Hot Topics in Parallelism (HotPar '12), Berkeley, CA Motivation & Objectives Background Architecture Program Reconstruction Implementation
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
Advance Operating Systems (CS202) Locks Discussion
Advance Operating Systems (CS202) Locks Discussion Threads Locks Spin Locks Array-based Locks MCS Locks Sequential Locks Road Map Threads Global variables and static objects are shared Stored in the static
Programming Paradigms for Concurrency Lecture 2 - Mutual Exclusion
Programming Paradigms for Concurrency Lecture 2 - Mutual Exclusion Based on companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Modified by Thomas Wies New York University
Peterson s Algorithm
Peterson s Algorithm public void lock() { flag[i] = true; victim = i; while (flag[j] && victim == i) {}; } public void unlock() { flag[i] = false; } 24/03/10 Art of Multiprocessor Programming 1 Mutual
Chapter 18: Database System Architectures.! Centralized Systems! Client--Server Systems! Parallel Systems! Distributed Systems!
Chapter 18: Database System Architectures! Centralized Systems! Client--Server Systems! Parallel Systems! Distributed Systems! Network Types 18.1 Centralized Systems! Run on a single computer system and
Concurrent Counting using Combining Tree
Final Project Report by Shang Wang, Taolun Chai and Xiaoming Jia Concurrent Counting using Combining Tree 1. Introduction Counting is one of the very basic and natural activities that computers do. However,
NON-BLOCKING DATA STRUCTURES AND TRANSACTIONAL MEMORY. Tim Harris, 3 Nov 2017
NON-BLOCKING DATA STRUCTURES AND TRANSACTIONAL MEMORY Tim Harris, 3 Nov 2017 Lecture 1/3 Introduction Basic spin-locks Queue-based locks Hierarchical locks Reader-writer locks Reading without locking Flat
Lecture 7: Transactional Memory Intro. Topics: introduction to transactional memory, lazy implementation
Lecture 7: Transactional Memory Intro Topics: introduction to transactional memory, lazy implementation 1 Transactions New paradigm to simplify programming instead of lock-unlock, use transaction begin-end
Multi-Core Computing with Transactional Memory. Johannes Schneider and Prof. Roger Wattenhofer
Multi-Core Computing with Transactional Memory Johannes Schneider and Prof. Roger Wattenhofer 1 Overview Introduction Difficulties with parallel (multi-core) programming A (partial) solution: Transactional
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
Page 1. Challenges" Concurrency" CS162 Operating Systems and Systems Programming Lecture 4. Synchronization, Atomic operations, Locks"
CS162 Operating Systems and Systems Programming Lecture 4 Synchronization, Atomic operations, Locks" January 30, 2012 Anthony D Joseph and Ion Stoica http://insteecsberkeleyedu/~cs162 Space Shuttle Example"
The New Java Technology Memory Model
The New Java Technology Memory Model java.sun.com/javaone/sf Jeremy Manson and William Pugh http://www.cs.umd.edu/~pugh 1 Audience Assume you are familiar with basics of Java technology-based threads (
Problem. Context. Hash table
Problem In many problems, it is natural to use Hash table as their data structures. How can the hash table be efficiently accessed among multiple units of execution (UEs)? Context Hash table is used when
Lecture 10: Multi-Object Synchronization
CS 422/522 Design & Implementation of Operating Systems Lecture 10: Multi-Object Synchronization Zhong Shao Dept. of Computer Science Yale University Acknowledgement: some slides are taken from previous
CSE 153 Design of Operating Systems
CSE 153 Design of Operating Systems Winter 19 Lecture 7/8: Synchronization (1) Administrivia How is Lab going? Be prepared with questions for this weeks Lab My impression from TAs is that you are on track
CSE 451: Operating Systems Winter Lecture 7 Synchronization. Steve Gribble. Synchronization. Threads cooperate in multithreaded programs
CSE 451: Operating Systems Winter 2005 Lecture 7 Synchronization Steve Gribble Synchronization Threads cooperate in multithreaded programs to share resources, access shared data structures e.g., threads
Lecture: Consistency Models, TM. Topics: consistency models, TM intro (Section 5.6)
Lecture: Consistency Models, TM Topics: consistency models, TM intro (Section 5.6) 1 Coherence Vs. Consistency Recall that coherence guarantees (i) that a write will eventually be seen by other processors,
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)
Spin Locks and Contention Management
Chapter 7 Spin Locks and Contention Management 7.1 Introduction We now turn our attention to the performance of mutual exclusion protocols on realistic architectures. Any mutual exclusion protocol poses
Design of Parallel and High-Performance Computing Fall 2015 Lecture: Locks and Lock-Free continued
Design of Parallel and High-Performance Computing Fall 2015 Lecture: Locks and Lock-Free continued Motivational video: https://www.youtube.com/watch?v=-7bpo1quxyw Instructor: Torsten Hoefler & Markus Püschel
Lecture 23 Database System Architectures
CMSC 461, Database Management Systems Spring 2018 Lecture 23 Database System Architectures These slides are based on Database System Concepts 6 th edition book (whereas some quotes and figures are used
CMSC Computer Architecture Lecture 15: Memory Consistency and Synchronization. Prof. Yanjing Li University of Chicago
CMSC 22200 Computer Architecture Lecture 15: Memory Consistency and Synchronization Prof. Yanjing Li University of Chicago Administrative Stuff! Lab 5 (multi-core) " Basic requirements: out later today
Database Management and Tuning
Database Management and Tuning Concurrency Tuning Johann Gamper Free University of Bozen-Bolzano Faculty of Computer Science IDSE Unit 8 May 10, 2012 Acknowledgements: The slides are provided by Nikolaus
Understanding Hardware Transactional Memory
Understanding Hardware Transactional Memory Gil Tene, CTO & co-founder, Azul Systems @giltene 2015 Azul Systems, Inc. Agenda Brief introduction What is Hardware Transactional Memory (HTM)? Cache coherence
10/17/ Gribble, Lazowska, Levy, Zahorjan 2. 10/17/ Gribble, Lazowska, Levy, Zahorjan 4
Temporal relations CSE 451: Operating Systems Autumn 2010 Module 7 Synchronization Instructions executed by a single thread are totally ordered A < B < C < Absent synchronization, instructions executed
CSE 374 Programming Concepts & Tools
CSE 374 Programming Concepts & Tools Hal Perkins Fall 2017 Lecture 22 Shared-Memory Concurrency 1 Administrivia HW7 due Thursday night, 11 pm (+ late days if you still have any & want to use them) Course
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
CSE332: Data Abstractions Lecture 23: Programming with Locks and Critical Sections. Tyler Robison Summer 2010
CSE332: Data Abstractions Lecture 23: Programming with Locks and Critical Sections Tyler Robison Summer 2010 1 Concurrency: where are we Done: The semantics of locks Locks in Java Using locks for mutual
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
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
Implementing caches. Example. Client. N. America. Client System + Caches. Asia. Client. Africa. Client. Client. Client. Client. Client.
N. America Example Implementing caches Doug Woos Asia System + Caches Africa put (k2, g(get(k1)) put (k2, g(get(k1)) What if clients use a sharded key-value store to coordinate their output? Or CPUs use
Advanced Topic: Efficient Synchronization
Advanced Topic: Efficient Synchronization Multi-Object Programs What happens when we try to synchronize across multiple objects in a large program? Each object with its own lock, condition variables Is
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
Cache-Aware Lock-Free Queues for Multiple Producers/Consumers and Weak Memory Consistency
Cache-Aware Lock-Free Queues for Multiple Producers/Consumers and Weak Memory Consistency Anders Gidenstam Håkan Sundell Philippas Tsigas School of business and informatics University of Borås Distributed
Today: Synchronization. Recap: Synchronization
Today: Synchronization Synchronization Mutual exclusion Critical sections Example: Too Much Milk Locks Synchronization primitives are required to ensure that only one thread executes in a critical section
Parallel Programming: Background Information
1 Parallel Programming: Background Information Mike Bailey mjb@cs.oregonstate.edu parallel.background.pptx Three Reasons to Study Parallel Programming 2 1. Increase performance: do more work in the same
Parallel Programming: Background Information
1 Parallel Programming: Background Information Mike Bailey mjb@cs.oregonstate.edu parallel.background.pptx Three Reasons to Study Parallel Programming 2 1. Increase performance: do more work in the same
Lecture #7: Implementing Mutual Exclusion
Lecture #7: Implementing Mutual Exclusion Review -- 1 min Solution #3 to too much milk works, but it is really unsatisfactory: 1) Really complicated even for this simple example, hard to convince yourself
CSE 153 Design of Operating Systems Fall 2018
CSE 153 Design of Operating Systems Fall 2018 Lecture 5: Threads/Synchronization Implementing threads l Kernel Level Threads l u u All thread operations are implemented in the kernel The OS schedules all
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,
Outline. Database Tuning. Ideal Transaction. Concurrency Tuning Goals. Concurrency Tuning. Nikolaus Augsten. Lock Tuning. Unit 8 WS 2013/2014
Outline Database Tuning Nikolaus Augsten University of Salzburg Department of Computer Science Database Group 1 Unit 8 WS 2013/2014 Adapted from Database Tuning by Dennis Shasha and Philippe Bonnet. Nikolaus
CSE 451: Operating Systems Winter Lecture 7 Synchronization. Hank Levy 412 Sieg Hall
CSE 451: Operating Systems Winter 2003 Lecture 7 Synchronization Hank Levy Levy@cs.washington.edu 412 Sieg Hall Synchronization Threads cooperate in multithreaded programs to share resources, access shared
A Sophomoric Introduction to Shared-Memory Parallelism and Concurrency Lecture 5 Programming with Locks and Critical Sections
A Sophomoric Introduction to Shared-Memory Parallelism and Concurrency Lecture 5 Programming with Locks and Critical Sections Dan Grossman Last Updated: May 2012 For more information, see http://www.cs.washington.edu/homes/djg/teachingmaterials/
Reagent Based Lock Free Concurrent Link List Spring 2012 Ancsa Hannak and Mitesh Jain April 28, 2012
Reagent Based Lock Free Concurrent Link List Spring 0 Ancsa Hannak and Mitesh Jain April 8, 0 Introduction The most commonly used implementation of synchronization is blocking algorithms. They utilize
NON-BLOCKING DATA STRUCTURES AND TRANSACTIONAL MEMORY. Tim Harris, 14 November 2014
NON-BLOCKING DATA STRUCTURES AND TRANSACTIONAL MEMORY Tim Harris, 14 November 2014 Lecture 6 Introduction Amdahl s law Basic spin-locks Queue-based locks Hierarchical locks Reader-writer locks Reading
Pre- and post- CS protocols. CS 361 Concurrent programming Drexel University Fall 2004 Lecture 7. Other requirements for a mutual exclusion algorithm
CS 361 Concurrent programming Drexel University Fall 2004 Lecture 7 Bruce Char and Vera Zaychik. All rights reserved by the author. Permission is given to students enrolled in CS361 Fall 2004 to reproduce
Chapter 20: Database System Architectures
Chapter 20: Database System Architectures Chapter 20: Database System Architectures Centralized and Client-Server Systems Server System Architectures Parallel Systems Distributed Systems Network Types
Operating Systems. Synchronization
Operating Systems Fall 2014 Synchronization Myungjin Lee myungjin.lee@ed.ac.uk 1 Temporal relations Instructions executed by a single thread are totally ordered A < B < C < Absent synchronization, instructions