concurrent objects
DESCRIPTION
Concurrent Objects. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Modified by Pavol Černý , Programming Paradigms for Concurrency, Fall 2010, IST Austria. Concurrent Computation. memory. object. object. Objectivism. - PowerPoint PPT PresentationTRANSCRIPT
Concurrent Objects
Companion slides forThe Art of Multiprocessor Programming
by Maurice Herlihy & Nir Shavit
Modified by Pavol Černý, Programming Paradigms for
Concurrency, Fall 2010, IST Austria
Art of Multiprocessor Programming
2
Concurrent Computation
memory
object object
Art of Multiprocessor Programming
3
Objectivism
• What is a concurrent object?– How do we describe one?– How do we implement one?– How do we tell if we’re right?
Art of Multiprocessor Programming
4
Objectivism
• What is a concurrent object?– How do we describe one?
– How do we tell if we’re right?
Art of Multiprocessor Programming
5
FIFO Queue: Enqueue Method
q.enq( )
Art of Multiprocessor Programming
6
FIFO Queue: Dequeue Method
q.deq()/
Art of Multiprocessor Programming
7
A Lock-Based Queue
class LockBasedQueue<T> { int head, tail; T[] items; Lock lock; public LockBasedQueue(int capacity) { head = 0; tail = 0; lock = new ReentrantLock(); items = (T[]) new Object[capacity]; }
Art of Multiprocessor Programming
8
A Lock-Based Queue
class LockBasedQueue<T> { int head, tail; T[] items; Lock lock; public LockBasedQueue(int capacity) { head = 0; tail = 0; lock = new ReentrantLock(); items = (T[]) new Object[capacity]; }
0 1capacity-1
2
head tail
y z
Queue fields protected by single shared lock
Art of Multiprocessor Programming
9
A Lock-Based Queue
class LockBasedQueue<T> { int head, tail; T[] items; Lock lock; public LockBasedQueue(int capacity) { head = 0; tail = 0; lock = new ReentrantLock(); items = (T[]) new Object[capacity]; }
0 1capacity-1
2
head tail
y z
Initially head = tail
Art of Multiprocessor Programming
10
Implementation: Deq
public T deq() throws EmptyException { lock.lock(); try { if (tail == head) throw new EmptyException(); T x = items[head % items.length]; head++; return x; } finally { lock.unlock(); } }
0 1capacity-1
2
head tail
y z
Art of Multiprocessor Programming
11
Implementation: Deq
public T deq() throws EmptyException { lock.lock(); try { if (tail == head) throw new EmptyException(); T x = items[head % items.length]; head++; return x; } finally { lock.unlock(); } }
Method calls mutually exclusive
0 1capacity-1
2
head tail
y z
Art of Multiprocessor Programming
12
Implementation: Deq
public T deq() throws EmptyException { lock.lock(); try { if (tail == head) throw new EmptyException(); T x = items[head % items.length]; head++; return x; } finally { lock.unlock(); } }
If queue emptythrow exception
0 1capacity-1
2
head tail
y z
Art of Multiprocessor Programming
13
Implementation: Deq
public T deq() throws EmptyException { lock.lock(); try { if (tail == head) throw new EmptyException(); T x = items[head % items.length]; head++; return x; } finally { lock.unlock(); } }
Queue not empty:remove item and
update head
0 1capacity-1
2
head tail
y z
Art of Multiprocessor Programming
14
Implementation: Deq
public T deq() throws EmptyException { lock.lock(); try { if (tail == head) throw new EmptyException(); T x = items[head % items.length]; head++; return x; } finally { lock.unlock(); } }
Return result
0 1capacity-1
2
head tail
y z
Art of Multiprocessor Programming
15
Implementation: Deq
public T deq() throws EmptyException { lock.lock(); try { if (tail == head) throw new EmptyException(); T x = items[head % items.length]; head++; return x; } finally { lock.unlock(); } }
Release lock no matter what!
0 1capacity-1
2
head tail
y z
Art of Multiprocessor Programming
16
Implementation: Deq
public T deq() throws EmptyException { lock.lock(); try { if (tail == head) throw new EmptyException(); T x = items[head % items.length]; head++; return x; } finally { lock.unlock(); } }
Should be correct because
modifications are mutually
exclusive…
List-Based SetInterface:
Unordered collection of items, No duplicates
add(x) put x in setremove(x) take x out of setcontains(x) tests if x in set
3 5 …
Implementation:
-∞
∞
Concurrent lists
Concurrent lists“lock what you modify”
3 5 7 9
P1: remove(7)
P2: remove(5)
Step 1
prev
curr
currprev
Concurrent lists
Concurrent lists“lock what you modify”
3 5 7 9
P1: remove(7)
P2: remove(5)
prev
curr
currprev
prev.next:=
curr.next
Concurrent lists“lock what you modify”
3 5 7 9
P1: remove(7)
P2: remove(5)
Step 2
Concurrent lists
Concurrent lists“lock what you modify”
3 5 7 9
P1: remove(7)
P2: remove(5)
Step 3
Concurrent lists
Concurrent lists“lock what you modify”
3 5 7 9
P1: remove(7)
P2: remove(5)
Step 4
Concurrent lists
Concurrent lists“lock what you modify”
3 5 7 9
P1: remove(7)
P2: remove(5)
Step 5
Concurrent lists
Concurrent lists“lock what you modify”
3 5 7 9
P1: remove(7)
P2: remove(5)
Concurrent lists
public boolean remove(T item) {
while (true) {
(pred,curr) = find(head, key);
if (curr.key != key) {// the key not present
return false;
} else {// the key present
Node succ = curr.next.getReference();
snip = curr.next.attemptMark(succ, true);
if (!snip) continue;
pred.next.compareAndSet(curr, succ, false, false);
return true;
}
}
}
Lock-free listLock-free linked list from [Herlihy-Shavit]
p.attemptMark(T expRef, bool b)If p==expRef, update the mark
p.compareAndSet(T expRef, T newRef,bool expMark, bool newMark)
If p==expRef, p.mark==expMark, update the mark
Lock-free list remove
3 5 7 9
remove(7)
currprev
succ
snip = curr.next.attemptMark(succ, true);
M
…
snip = pred.next.compareAndSet(curr,succ, false, false);
Art of Multiprocessor Programming
27
Defining concurrent implementations
• Need a way to specify a concurrent queue (concurrent list) object
• Need a way to prove that an algorithm implements the object’s specification
• Lets talk about object specifications …
Correctness and Progress
• In a concurrent setting, we need to specify both the safety and the liveness properties of an object
• Need a way to define – when an implementation is correct– the conditions under which it
guarantees progress
Art of Multiprocessor Programming
28
Lets begin with correctness
Art of Multiprocessor Programming
29
Sequential Objects
• Each object has a state– Usually given by a set of fields– Queue example: sequence of items
• Each object has a set of methods– Only way to manipulate state– Queue example: enq and deq methods
Art of Multiprocessor Programming
30
Sequential Specifications
• If (precondition) – the object is in such-and-such a state– before you call the method,
• Then (postcondition)– the method will return a particular
value– or throw a particular exception.
• and (postcondition, con’t)– the object will be in some other state– when the method returns,
Art of Multiprocessor Programming
31
Pre and PostConditions for Dequeue
• Precondition:– Queue is non-empty
• Postcondition:– Returns first item in queue
• Postcondition:– Removes first item in queue
Art of Multiprocessor Programming
32
Pre and PostConditions for Dequeue
• Precondition:– Queue is empty
• Postcondition:– Throws Empty exception
• Postcondition:– Queue state unchanged
Art of Multiprocessor Programming
33
Why Sequential Specifications Totally Rock
• Interactions among methods captured by side-effects on object state– State meaningful between method calls
• Documentation size linear in number of methods– Each method described in isolation
• Can add new methods– Without changing descriptions of old methods
Art of Multiprocessor Programming
34
What About Concurrent Specifications ?
• Methods? • Documentation?• Adding new methods?
Art of Multiprocessor Programming
35
Methods Take Time
timetime
Art of Multiprocessor Programming
36
Methods Take Time
time
invocation 12:00
q.enq(...
)
time
Art of Multiprocessor Programming
37
Methods Take Time
time
Method call
invocation 12:00
q.enq(...
)
time
Art of Multiprocessor Programming
38
Methods Take Time
time
Method call
invocation 12:00
q.enq(...
)
time
Art of Multiprocessor Programming
39
Methods Take Time
time
Method call
invocation 12:00
q.enq(...
)
time
void
response 12:01
Art of Multiprocessor Programming
40
Sequential vs Concurrent
• Sequential– Methods take time? Who knew?
• Concurrent– Method call is not an event– Method call is an interval.
Art of Multiprocessor Programming
41
time
Concurrent Methods Take Overlapping Time
time
Art of Multiprocessor Programming
42
time
Concurrent Methods Take Overlapping Time
time
Method call
Art of Multiprocessor Programming
43
time
Concurrent Methods Take Overlapping Time
time
Method call
Method call
Art of Multiprocessor Programming
44
time
Concurrent Methods Take Overlapping Time
time
Method call Method call
Method call
Art of Multiprocessor Programming
45
Sequential vs Concurrent
• Sequential:– Object needs meaningful state only
between method calls• Concurrent
– Because method calls overlap, object might never be between method calls
Art of Multiprocessor Programming
46
Sequential vs Concurrent
• Sequential:– Each method described in isolation
• Concurrent– Must characterize all possible
interactions with concurrent calls • What if two enqs overlap?• Two deqs? enq and deq? …
Art of Multiprocessor Programming
47
Sequential vs Concurrent
• Sequential:– Can add new methods without affecting
older methods• Concurrent:
– Everything can potentially interact with everything else
Art of Multiprocessor Programming
48
Sequential vs Concurrent
• Sequential:– Can add new methods without affecting
older methods• Concurrent:
– Everything can potentially interact with everything else
Panic!
Art of Multiprocessor Programming
49
The Big Question
• What does it mean for a concurrent object to be correct?– What is a concurrent FIFO queue?– FIFO means strict temporal order– Concurrent means ambiguous temporal
order
Art of Multiprocessor Programming
50
Intuitively…
public T deq() throws EmptyException { lock.lock(); try { if (tail == head) throw new EmptyException(); T x = items[head % items.length]; head++; return x; } finally { lock.unlock(); } }
Art of Multiprocessor Programming
51
Intuitively…
public T deq() throws EmptyException { lock.lock(); try { if (tail == head) throw new EmptyException(); T x = items[head % items.length]; head++; return x; } finally { lock.unlock(); } }
All modifications of queue are done mutually exclusive
Art of Multiprocessor Programming
52
time
Intuitively
q.deq
q.enq
enq deq
lock() unlock()
lock() unlock() Behavior is “Sequential”
enq
deq
Lets capture the idea of describing the concurrent via the sequential
Art of Multiprocessor Programming
53
Linearizability
• Each method should– “take effect”– Instantaneously– Between invocation and response
events• Object is correct if this “sequential”
behavior is correct• Any such concurrent object is
– Linearizable™
Art of Multiprocessor Programming
54
Is it really about the object?• Each method should
– “take effect”– Instantaneously– Between invocation and response
events• Sounds like a property of an
execution…• A linearizable object: one all of
whose possible executions are linearizable
Art of Multiprocessor Programming
55
Example
timetime
(6)
Art of Multiprocessor Programming
56
Example
time
q.enq(x)
time
(6)
Art of Multiprocessor Programming
57
Example
time
q.enq(x)
q.enq(y)
time
(6)
Art of Multiprocessor Programming
58
Example
time
q.enq(x)
q.enq(y) q.deq(x)
time
(6)
Art of Multiprocessor Programming
59
Example
time
q.enq(x)
q.enq(y) q.deq(x)
q.deq(y)
time
(6)
Art of Multiprocessor Programming
60
Example
time
q.enq(x)
q.enq(y) q.deq(x)
q.deq(y)
linearizableq.enq(x)
q.enq(y) q.deq(x)
q.deq(y)
time
(6)
Art of Multiprocessor Programming
61
Example
time
q.enq(x)
q.enq(y) q.deq(x)
q.deq(y)
Valid?q.enq(x)
q.enq(y) q.deq(x)
q.deq(y)
time
(6)
Art of Multiprocessor Programming
62
Example
time
(5)
Art of Multiprocessor Programming
63
Example
time
q.enq(x)
(5)
Art of Multiprocessor Programming
64
Example
time
q.enq(x) q.deq(y)
(5)
Art of Multiprocessor Programming
65
Example
time
q.enq(x)
q.enq(y)
q.deq(y)
(5)
Art of Multiprocessor Programming
66
Example
time
q.enq(x)
q.enq(y)
q.deq(y)q.enq(x)
q.enq(y)
(5)
Art of Multiprocessor Programming
67
Example
time
q.enq(x)
q.enq(y)
q.deq(y)q.enq(x)
q.enq(y)
(5)
not
linearizable
Art of Multiprocessor Programming
68
Example
timetime
(4)
Art of Multiprocessor Programming
69
Example
time
q.enq(x)
time
(4)
Art of Multiprocessor Programming
70
Example
time
q.enq(x)
q.deq(x)
time
(4)
Art of Multiprocessor Programming
71
Example
time
q.enq(x)
q.deq(x)
q.enq(x)
q.deq(x)
time
(4)
Art of Multiprocessor Programming
72
Example
time
q.enq(x)
q.deq(x)
q.enq(x)
q.deq(x)
linearizable
time
(4)
Art of Multiprocessor Programming
73
Example
time
q.enq(x)
time
(8)
Art of Multiprocessor Programming
74
Example
time
q.enq(x)
q.enq(y)
time
(8)
Art of Multiprocessor Programming
75
Example
time
q.enq(x)
q.enq(y)
q.deq(y)
time
(8)
Art of Multiprocessor Programming
76
Example
time
q.enq(x)
q.enq(y)
q.deq(y)
q.deq(x)
time
(8)
Art of Multiprocessor Programming
77
q.enq(x)
q.enq(y)
q.deq(y)
q.deq(x)
Example
time
multiple orders
OKlinearizable
Art of Multiprocessor Programming
78
Read/Write Register Example
time
read(1)write(0)
write(1)
write(2)
time
read(0)
(4)
Art of Multiprocessor Programming
79
Read/Write Register Example
time
read(1)write(0)
write(1)
write(2)
time
read(0)write(1) already
happened(4)
Art of Multiprocessor Programming
80
Read/Write Register Example
time
read(1)write(0)
write(1)
write(2)
time
read(0)write(1)write(1) already
happened(4)
Art of Multiprocessor Programming
81
Read/Write Register Example
time
read(1)write(0)
write(1)
write(2)
time
read(0)write(1)write(1) already
happened(4)
not
linearizable
Art of Multiprocessor Programming
82
Read/Write Register Example
time
read(1)write(0)
write(1)
write(2)
time
read(1)write(1) already
happened(4)
Art of Multiprocessor Programming
83
Read/Write Register Example
time
read(1)write(0)
write(1)
write(2)
time
read(1)write(1)
write(2)
(4)
write(1) already
happened
Art of Multiprocessor Programming
84
Read/Write Register Example
time
read(1)write(0)
write(1)
write(2)
time
read(1)write(1)
write(2)
not
linearizable
(4)
write(1) already
happened
Art of Multiprocessor Programming
85
Read/Write Register Example
time
write(0)
write(1)
write(2)
time
read(1)
(4)
Art of Multiprocessor Programming
86
Read/Write Register Example
time
write(0)
write(1)
write(2)
time
read(1)write(1)
write(2)
(4)
Art of Multiprocessor Programming
87
Read/Write Register Example
time
write(0)
write(1)
write(2)
time
read(1)write(1)
write(2)
linearizable
(4)
Art of Multiprocessor Programming
88
Read/Write Register Example
time
read(1)write(0)
write(1)
write(2)
time
read(1)
(2)
Art of Multiprocessor Programming
89
Read/Write Register Example
time
read(1)write(0)
write(1)
write(2)
time
read(1)write(1)
(2)
Art of Multiprocessor Programming
90
Read/Write Register Example
time
read(1)write(0)
write(1)
write(2)
time
read(1)write(1)
write(2)
(2)
Art of Multiprocessor Programming
91
Read/Write Register Example
time
read(1)write(0)
write(1)
write(2)
time
read(2)write(1)
write(2)
Not
linearizable
(2)
Art of Multiprocessor Programming
92
Talking About Executions
• Why?– Can’t we specify the linearization point
of each operation without describing an execution?
• Not Always– In some cases, linearization point
depends on the execution
Art of Multiprocessor Programming
93
Formal Model of Executions
• Define precisely what we mean– Ambiguity is bad when intuition is weak
• Allow reasoning
Art of Multiprocessor Programming
94
Split Method Calls into Two Events
• Invocation– method name & args– q.enq(x)
• Response– result or exception– q.enq(x) returns void– q.deq() returns x– q.deq() throws empty
Art of Multiprocessor Programming
95
Invocation Notation
A q.enq(x)
(4)
Art of Multiprocessor Programming
96
Invocation Notation
A q.enq(x)
thread
(4)
Art of Multiprocessor Programming
97
Invocation Notation
A q.enq(x)
thread method
(4)
Art of Multiprocessor Programming
98
Invocation Notation
A q.enq(x)
thread
object(4)
method
Art of Multiprocessor Programming
99
Invocation Notation
A q.enq(x)
thread
object
method
arguments(4)
Art of Multiprocessor Programming
100
Response Notation
A q: void
(2)
Art of Multiprocessor Programming
101
Response Notation
A q: void
thread
(2)
Art of Multiprocessor Programming
102
Response Notation
A q: void
thread result
(2)
Art of Multiprocessor Programming
103
Response Notation
A q: void
thread
object
result
(2)
Art of Multiprocessor Programming
104
Response Notation
A q: void
thread
object
result
(2)
Met
hod
is
impl
icit
Art of Multiprocessor Programming
105
Response Notation
A q: empty()
thread
object(2)
Met
hod
is
impl
icit
exception
Art of Multiprocessor Programming
106
History - Describing an Execution
A q.enq(3)A q:voidA q.enq(5)B p.enq(4)B p:voidB q.deq()B q:3
Sequence of invocations and
responses
H =
Art of Multiprocessor Programming
107
Definition
• Invocation & response match if
A q.enq(3)
A q:void
Thread names agree
Object names agree
Method call
(1)
Art of Multiprocessor Programming
108
Object Projections
A q.enq(3)A q:voidB p.enq(4)B p:voidB q.deq()B q:3
H =
Art of Multiprocessor Programming
109
Object Projections
A q.enq(3)A q:voidB p.enq(4)B p:voidB q.deq()B q:3
H|q =
Art of Multiprocessor Programming
110
Thread Projections
A q.enq(3)A q:voidB p.enq(4)B p:voidB q.deq()B q:3
H =
Art of Multiprocessor Programming
111
Thread Projections
A q.enq(3)A q:voidB p.enq(4)B p:voidB q.deq()B q:3
H|B =
Art of Multiprocessor Programming
112
Complete Subhistory
A q.enq(3)A q:voidA q.enq(5)B p.enq(4)B p:voidB q.deq()B q:3
An invocation is pending if it has
no matching respnse
H =
Art of Multiprocessor Programming
113
Complete Subhistory
A q.enq(3)A q:voidA q.enq(5)B p.enq(4)B p:voidB q.deq()B q:3
May or may not have taken effect
H =
Art of Multiprocessor Programming
114
Complete Subhistory
A q.enq(3)A q:voidA q.enq(5)B p.enq(4)B p:voidB q.deq()B q:3
discard pending invocations
H =
Art of Multiprocessor Programming
115
Complete Subhistory
A q.enq(3)A q:void B p.enq(4)B p:voidB q.deq()B q:3
Complete(H) =
Art of Multiprocessor Programming
116
Sequential Histories
A q.enq(3)A q:voidB p.enq(4)B p:voidB q.deq()B q:3A q:enq(5)
(4)
Art of Multiprocessor Programming
117
Sequential Histories
A q.enq(3)A q:voidB p.enq(4)B p:voidB q.deq()B q:3A q:enq(5)
match
(4)
Art of Multiprocessor Programming
118
Sequential Histories
A q.enq(3)A q:voidB p.enq(4)B p:voidB q.deq()B q:3A q:enq(5)
match
match
(4)
Art of Multiprocessor Programming
119
Sequential Histories
A q.enq(3)A q:voidB p.enq(4)B p:voidB q.deq()B q:3A q:enq(5)
match
match
match
(4)
Art of Multiprocessor Programming
120
Sequential Histories
A q.enq(3)A q:voidB p.enq(4)B p:voidB q.deq()B q:3A q:enq(5)
match
match
match
Final pending invocation OK
(4)
Art of Multiprocessor Programming
121
Sequential Histories
A q.enq(3)A q:voidB p.enq(4)B p:voidB q.deq()B q:3A q:enq(5)
match
match
match
Final pending invocation OK
(4)
Method calls of
different threads
do not interleave
Art of Multiprocessor Programming
122
Well-Formed Histories
H=
A q.enq(3)B p.enq(4)B p:voidB q.deq()A q:voidB q:3
Art of Multiprocessor Programming
123
Well-Formed Histories
H=
A q.enq(3)B p.enq(4)B p:voidB q.deq()A q:voidB q:3
H|B=B p.enq(4)B p:voidB q.deq()B q:3
Per-thread projections sequential
Art of Multiprocessor Programming
124
Well-Formed Histories
H=
A q.enq(3)B p.enq(4)B p:voidB q.deq()A q:voidB q:3
H|B=B p.enq(4)B p:voidB q.deq()B q:3
A q.enq(3)A q:void
H|A=
Per-thread projections sequential
Art of Multiprocessor Programming
125
Equivalent Histories
H=
A q.enq(3)B p.enq(4)B p:voidB q.deq()A q:voidB q:3
Threads see the same thing in both
A q.enq(3)A q:voidB p.enq(4)B p:voidB q.deq()B q:3
G=
H|A = G|AH|B = G|B
Art of Multiprocessor Programming
126
Sequential Specifications
• A sequential specification is some way of telling whether a– Single-thread, single-object history– Is legal
• For example:– Pre and post-conditions– But plenty of other techniques exist …
Art of Multiprocessor Programming
127
Legal Histories
• A sequential (multi-object) history H is legal if– For every object x– H|x is in the sequential spec for x
Art of Multiprocessor Programming
128
Precedence
A q.enq(3)B p.enq(4)B p.voidA q:voidB q.deq()B q:3
A method call precedes another if
response event precedes invocation
event
Method call Method call
(1)
Art of Multiprocessor Programming
129
Non-Precedence
A q.enq(3)B p.enq(4)B p.voidB q.deq()A q:voidB q:3
Some method calls overlap one
anotherMethod call
Method call
(1)
Art of Multiprocessor Programming
130
Notation
• Given – History H– method executions m0 and m1 in H
• We say m0 H m1, if– m0 precedes m1
• Relation m0 H m1 is a– Partial order – Total order if H is sequential
m0 m1
Art of Multiprocessor Programming
131
Linearizability
• History H is linearizable if it can be extended to G by– Appending zero or more responses to
pending invocations– Discarding other pending invocations
• So that G is equivalent to– Legal sequential history S – where G S
Art of Multiprocessor Programming
132
What is G S
time
a
b
time
(8)
G
S
cG
G = {ac,bc}
S = {ab,ac,bc}
A limita
tion on th
e
Choice of S
!
Art of Multiprocessor Programming
133
Remarks
• Some pending invocations– Took effect, so keep them– Discard the rest
• Condition G S
– Means that S respects “real-time order” of G
Art of Multiprocessor Programming
134
A q.enq(3)B q.enq(4)B q:voidB q.deq()B q:3B q:enq(6)
Example
time
B.q.enq(4)
A. q.enq(3)
B.q.deq(4) B. q.enq(6)
Art of Multiprocessor Programming
135
Example
Complete this pending
invocation
time
B.q.enq(4) B.q.deq(3) B. q.enq(6)
A q.enq(3)B q.enq(4)B q:voidB q.deq()B q:3B q:enq(6)
A. q.enq(3)
Art of Multiprocessor Programming
136
Example
Complete this pending
invocation
time
B.q.enq(4) B.q.deq(4) B. q.enq(6)
A.q.enq(3)
A q.enq(3)B q.enq(4)B q:voidB q.deq()B q:3B q:enq(6)A q:void
Art of Multiprocessor Programming
137
Example
time
B.q.enq(4) B.q.deq(4) B. q.enq(6)
A.q.enq(3)
A q.enq(3)B q.enq(4)B q:voidB q.deq()B q:3B q:enq(6)A q:void
discard this one
Art of Multiprocessor Programming
138
Example
time
B.q.enq(4) B.q.deq(4)
A.q.enq(3)
A q.enq(3)B q.enq(4)B q:voidB q.deq()B q:3
A q:void
discard this one
Art of Multiprocessor Programming
139
A q.enq(3)B q.enq(4)B q:voidB q.deq()B q:3A q:void
Example
time
B.q.enq(4) B.q.deq(4)
A.q.enq(3)
Art of Multiprocessor Programming
140
A q.enq(3)B q.enq(4)B q:voidB q.deq()B q:3A q:void
Example
time
A q.enq(3)A q:voidB q.enq(4)B q:voidB q.deq()B q:3
B.q.enq(4) B.q.deq(4)
A.q.enq(3)
Art of Multiprocessor Programming
141
B.q.enq(4) B.q.deq(4)
A.q.enq(3)
A q.enq(3)B q.enq(4)B q:voidB q.deq()B q:4A q:void
Example
time
A q.enq(3)A q:voidB q.enq(4)B q:voidB q.deq()B q:3
Equivalent sequential history
Unlinearizable execution
Concurrent lists“lock what you modify”
3 5 7 9
P1: remove(7)
P2: remove(5)
Step 6
Unlinearizable
execution !!
Art of Multiprocessor Programming
143
Reasoning About Lineraizability: Locking
public T deq() throws EmptyException { lock.lock(); try { if (tail == head) throw new EmptyException(); T x = items[head % items.length]; head++; return x; } finally { lock.unlock(); } }
0 1capacity-1
2
head tail
y z
Art of Multiprocessor Programming
144
Reasoning About Lineraizability: Locking
public T deq() throws EmptyException { lock.lock(); try { if (tail == head) throw new EmptyException(); T x = items[head % items.length]; head++; return x; } finally { lock.unlock(); } }
Linearization pointsare when locks are
released
Art of Multiprocessor Programming
145
Strategy
• Identify one atomic step where method “happens”– Critical section– Machine instruction
• Doesn’t always work– Might need to define several different
steps for a given method
Art of Multiprocessor Programming
146
Linearizability: Summary
• Powerful specification tool for shared objects
• Allows us to capture the notion of objects being “atomic”
• There is a lot of ongoing research in verification community to build tools that can verify/debug concurrent implementations wrt linearizability
Art of Multiprocessor Programming
147
Alternative: Sequential Consistency
• History H is Sequentially Consistent if it can be extended to G by– Appending zero or more responses to
pending invocations– Discarding other pending invocations
• So that G is equivalent to a– Legal sequential history S – Where G S
Differs from linearizability
Art of Multiprocessor Programming
148
Alternative: Sequential Consistency
• No need to preserve real-time order– Cannot re-order operations done by
the same thread– Can re-order non-overlapping
operations done by different threads• Often used to describe
multiprocessor memory architectures
Art of Multiprocessor Programming
149
Example
time
(5)
Art of Multiprocessor Programming
150
Example
time
q.enq(x)
(5)
Art of Multiprocessor Programming
151
Example
time
q.enq(x) q.deq(y)
(5)
Art of Multiprocessor Programming
152
Example
time
q.enq(x)
q.enq(y)
q.deq(y)
(5)
Art of Multiprocessor Programming
153
Example
time
q.enq(x)
q.enq(y)
q.deq(y)q.enq(x)
q.enq(y)
(5)
Art of Multiprocessor Programming
154
Example
time
q.enq(x)
q.enq(y)
q.deq(y)q.enq(x)
q.enq(y)
(5)
not
linearizable
Art of Multiprocessor Programming
155
Example
time
q.enq(x)
q.enq(y)
q.deq(y)q.enq(x)
q.enq(y)
(5)
Yet
Sequentially
Consistent
Art of Multiprocessor Programming
156
Theorem
Sequential Consistency is not a local property
(and thus we lose composability…)
Art of Multiprocessor Programming
157
FIFO Queue Example
time
p.enq(x) p.deq(y)q.enq(x)
time
Art of Multiprocessor Programming
158
FIFO Queue Example
time
p.enq(x) p.deq(y)q.enq(x)
q.enq(y) q.deq(x)p.enq(y)
time
Art of Multiprocessor Programming
159
FIFO Queue Example
time
p.enq(x) p.deq(y)q.enq(x)
q.enq(y) q.deq(x)p.enq(y)
History H
time
Art of Multiprocessor Programming
160
H|p Sequentially Consistent
time
p.enq(x) p.deq(y)
p.enq(y)
q.enq(x)
q.enq(y) q.deq(x)
time
Art of Multiprocessor Programming
161
H|q Sequentially Consistent
time
p.enq(x) p.deq(y)q.enq(x)
q.enq(y) q.deq(x)p.enq(y)
time
Art of Multiprocessor Programming
162
Ordering imposed by p
time
p.enq(x) p.deq(y)q.enq(x)
q.enq(y) q.deq(x)p.enq(y)
time
Art of Multiprocessor Programming
163
Ordering imposed by q
time
p.enq(x) p.deq(y)q.enq(x)
q.enq(y) q.deq(x)p.enq(y)
time
Art of Multiprocessor Programming
164
p.enq(x)
Ordering imposed by both
time
q.enq(x)
q.enq(y) q.deq(x)
time
p.deq(y)
p.enq(y)
Art of Multiprocessor Programming
165
p.enq(x)
Combining orders
time
q.enq(x)
q.enq(y) q.deq(x)
time
p.deq(y)
p.enq(y)
Art of Multiprocessor Programming
166
Composability Theorem
• History H is linearizable if and only if– For every object x– H|x is linearizable
Art of Multiprocessor Programming
167
Why Does Composability Matter?
• Modularity • Can prove linearizability of objects in
isolation• Can compose independently-
implemented objects
Art of Multiprocessor Programming
168
Critical Sections
• Easy way to implement linearizability– Take sequential object– Make each method a critical section
• Problems– Blocking– No concurrency
Art of Multiprocessor Programming
169
Linearizability
• Linearizability– Operation takes effect instantaneously
between invocation and response– Uses sequential specification, locality
implies composablity– Good for high level objects
Art of Multiprocessor Programming
170
Correctness: Linearizability
• Sequential Consistency– Not composable– Harder to work with– Good way to think about hardware
models• We will use linearizability as in the
remainder of this course unless stated otherwise
Progress
• We saw an implementation whose methods were lock-based (deadlock-free)
• We saw an implementation whose methods did not use locks
• How do they relate?
Art of Multiprocessor Programming
171
Progress Conditions
• Deadlock-free: some thread trying to acquire the lock eventually succeeds.
• Starvation-free: every thread trying to acquire the lock eventually succeeds.
• Lock-free: some thread calling a method eventually returns.
• Wait-free: every thread calling a method eventually returns.
Art of Multiprocessor Programming
172
Progress Conditions
Art of Multiprocessor Programming
173
Wait-free
Lock-free
Starvation-free
Deadlock-free
Everyone makes progress
Non-Blocking Blocking
Someone makes progress
Art of Multiprocessor Programming
174
Summary
• We will look at linearizable blocking and non-blocking implementations of objects.