Concurrent Objects and Concurrent Computaton Linearizability

memory Nir Shavit Subing for N. Lynch object Fall 2003 object

© 2003 Herlihy and Shavit 2

Objectivism FIFO Queue: Enqueue Method

• What is a concurrent object? q.enq( ) – How do we describe one? – How do we implement one? – How do we tell if we’re right?

© 2003 Herlihy and Shavit 3 © 2003 Herlihy and Shavit 4

FIFO Queue: Dequeue Method Sequential Objects

q.deq()/ • 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

© 2003 Herlihy and Shavit 5 © 2003 Herlihy and Shavit 6

1 Pre and PostConditions for Sequential Specifications Dequeue • If (precondition) – the object is in such-and-such a state • Precondition: – before you call the method, – Queue is non-empty • Then (postcondition) • Postcondition: – the method will return a particular value – Returns first item in queue – or throw a particular exception. • Postcondition: • and (postcondition, con’t) – Removes first item in queue – the object will be in some other state • You got a problem with that? – when the method returns, © 2003 Herlihy and Shavit 7 © 2003 Herlihy and Shavit 8

Pre and PostConditions for Why Sequential Specifications Dequeue Totally Rock • Precondition: • Documentation size linear in number –Queue is empty of methods • Postcondition: – Each method described in isolation – Throws Empty exception • Interactions among methods captured • Postcondition: by side-effects on object state – Queue state unchanged – State meaningful between method calls

© 2003 Herlihy and Shavit 9 © 2003 Herlihy and Shavit 10

Why Sequential Specifications Methods Take Time Totally Rock (con’t) • Can add new methods (by subclassing) invocation response 12:00 – Without changing descriptions of old 12:01 methods • These properties are so familiar, we q.enq(...) void don’t think about them –But perhaps we should … Method call

time

© 2003 Herlihy and Shavit 11 © 2003 Herlihy and Shavit 12

2 Concurrent Methods Take Sequential vs Concurrent Overlapping Time • Sequential – Methods take time? Who knew? • Concurrent – Method call is not an event Method call Method call – Method call is an interval. Method call

time

© 2003 Herlihy and Shavit 13 © 2003 Herlihy and Shavit 14

Sequential vs Concurrent Sequential vs Concurrent

• Sequential: • Sequential: – Object needs meaningful state only – Each method described in isolation between method calls • Concurrent • Concurrent – Must characterize all possible – Because method calls overlap, object interactions with concurrent calls might never be between method calls • What if two enqsoverlap? •Two deqs? enq and deq? …

© 2003 Herlihy and Shavit 15 © 2003 Herlihy and Shavit 16

Sequential vs Concurrent The High-Order Bit

• Sequential: • What does it mean for a concurrent – Can add new methods without affecting object to be correct? older methods •What is a concurrent FIFO queue? • Concurrent: – FIFO means strict temporal order – Everything can potentially interactc! with ani – Um, like, that’s why they call it “FIFO?” everything else P – Concurrent means ambiguous temporal order

© 2003 Herlihy and Shavit 17 © 2003 Herlihy and Shavit 18

3 Linearizability Manifesto Comments on Manifesto

• Each method should • Common Sense, not Science – “take effect” • Scientific justification: – Instantaneously – Facilitates reasoning – Between invocation and response events – Nice mathematical properties • Any such concurrent object is • Common-sense justification – Linearizable™ – Preserves real-time order –Matches my intuition (sorry about yours)

© 2003 Herlihy and Shavit 19 © 2003 Herlihy and Shavit 20

More Comments on Manifesto Reasoning

• Proposed in 1990 •People are – Since then accepted almost anywhere – OK with sequential reasoning – Challenged by concurrent reasoning – Don’t leave home without it … • Air traffic control • Not universally adopted • Toddler room in day-care center – Usually for good, but specialized reasons •Most concurrent models – But most feel need to justify why not – Propose some kind of equivalence – Make concurrent problems sequential – Except they sometimes do it wrong …

© 2003 Herlihy and Shavit 21 © 2003 Herlihy and Shavit 22

Concurrent Specifications Example

• Naïve approach: world of pain lin – We must specify unspeakable number of ea possible multi-way interactions ri za •Linearizability: same as it ever was q.enq(x) b q.deq(y) le – Methods still described by pre- and postconditions q.enq(y) q.deq(x)

time

© 2003 Herlihy and Shavit 23 (6) © 2003 Herlihy and Shavit 24

4 Example Example no t li li nea ne r ar iz iz ab ab q.enq(x) q.deq(y) le q.enq(x) le

q.enq(y) q.deq(x)

time time

(5) © 2003 Herlihy and Shavit 25 (4) © 2003 Herlihy and Shavit 26

Example Comme ci Example

q.enq(x) q.deq(y) q.enq(x)q.enq(x) q.deq(y)q.deq(y)

q.enq(y) q.deq(x) q.enq(y)q.enq(y) q.deq(x)q.deq(x)

time time

(8) © 2003 Herlihy and Shavit 27 (8) © 2003 Herlihy and Shavit 28

Comme ci Example Comme ci Example Comme ça m u lt ip le o rd er q.enq(x) q.deq(y) q.enq(x) q.deq(y) s O K q.enq(y) q.deq(x) q.enq(y) q.deq(x)

time time

(8) © 2003 Herlihy and Shavit 29 © 2003 Herlihy and Shavit 30

5 Read/Write Variable Example Read/Write Variable Example no no t t li li nea nea r r iz iz ab ab write(0) read(1) write(2) le write(0) read(1) write(2) le

write(1) read(0) write(1) read(1) write(1) already happened time time

(4) © 2003 Herlihy and Shavit 31 (4) © 2003 Herlihy and Shavit 32

Read/Write Variable Example Read/Write Variable Example

lin lin ea ea ri ri za za bl bl write(0) write(2) e write(0) read(1) write(2) e

write(1) read(1) write(1) read(2)

time time

(4) © 2003 Herlihy and Shavit 33 (2) © 2003 Herlihy and Shavit 34

Split Method Calls into Two Formal Model Events • Define precisely what we mean • Invocation – Ambiguity is bad when intuition is weak – method name & args – q.enq(x) • Allow reasoning –Formal •Response –result or exception –But mostly informal – q.enq(x) returns void • In the long run, actually more important – q.deq() returns x •Ask me why! – q.deq() throws empty

© 2003 Herlihy and Shavit 35 © 2003 Herlihy and Shavit 36

6 Invocation Notation Response Notation

A q.enq(x) A q: void

method thread result

object arguments object

(4) © 2003 Herlihy and Shavit 37 (2) © 2003 Herlihy and Shavit 38

Response Notation (cont) History

A q.enq(3) A q: empty() A q:void A q.enq(5) H = B p.enq(4) thread exception B p:void B q.deq() Sequence of B q:3 invocations and object responses

(2) © 2003 Herlihy and Shavit 39 © 2003 Herlihy and Shavit 40

Definition Object Projections

• Invocation & response match if A q.enq(3) Thread Object names A q:void agree names agree H = B p.enq(4) A q.enq(3) B p:void Method call B q.deq() A q:void B q:3

(1) © 2003 Herlihy and Shavit 41 © 2003 Herlihy and Shavit 42

7 Object Projections Thread Projections

A q.enq(3) A q.enq(3) A q:void A q:void B p.enq(4) B p.enq(4) H|q = B p:void H = B p:void B q.deq() B q.deq() B q:3 B q:3

© 2003 Herlihy and Shavit 43 © 2003 Herlihy and Shavit 44

Thread Projections Complete Subhistory

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

© 2003 Herlihy and Shavit 45 © 2003 Herlihy and Shavit 46

Complete Subhistory Complete Subhistory

A q.enq(3) A q.enq(3) A q:void A q:void A q.enq(5) A q.enq(5) H = B p.enq(4) Complete(H)H == B p.enq(4) B p:void B p:void B q.deq() May or may not B q.deq() discard pending B q:3 have taken effect B q:3 invocations

© 2003 Herlihy and Shavit 47 © 2003 Herlihy and Shavit 48

8 Sequential Histories Well-Formed Histories

A q.enq(3) match A q.enq(3) A q:void A q:void A q.enq(5) B p.enq(4) match H = B p.enq(4) B p:void match B p:void B q.deq() B q.deq() B q:3 Final pending B q:3 A q:enq(5) invocation OK

(4) © 2003 Herlihy and Shavit 49 © 2003 Herlihy and Shavit 50

Well-Formed Histories Equivalent Histories

Per-thread B p.enq(4) Threads see the same H|A = G|A projections sequential H|B= B p:void thing in both H|B = G|B A q.enq(3) B q.deq() B p.enq(4) B q:3 A q.enq(3) A q.enq(3) B p:void B p.enq(4) A q:void H= B q.deq() B p:void B p.enq(4) A q:void H= G= A q.enq(3) B q.deq() B p:void B q:3 H|A= A q:void A q:void B q.deq() B q:3 B q:3

© 2003 Herlihy and Shavit 51 © 2003 Herlihy and Shavit 52

Sequential Specifications Legal Histories

• A sequential specification is some way • A sequential (multi-object) history H of telling whether a is legal if – Single-thread, single-object history – For every object x –Is legal – H|x is in the sequential spec for x • My favorite way is using – Pre and post-conditions – But plenty of other techniques exist …

© 2003 Herlihy and Shavit 53 © 2003 Herlihy and Shavit 54

9 Method Call Precedence

A q.enq(3) A q.enq(3) B p.enq(4) Interval between B p.enq(4) A method call precedes B p.void invocation and B p.void another if response B q.deq() response events A q:void event precedes A q:void B q.deq() invocation event B q:3 B q:3 Method call Method call Method call

(1) © 2003 Herlihy and Shavit 55 (1) © 2003 Herlihy and Shavit 56

Non-Precedence Notation

•Given A q.enq(3) –History H B p.enq(4) – method executions m0 and m1 in H B p.void Some method calls •We say m Î m , if B q.deq() overlap one another 0 H 1 m m A q:void – m0 precedes m1 0 1 Î B q:3 Method call •Relation m0 H m1 is a – Partial order Method call – Total order if H is sequential

(1) © 2003 Herlihy and Shavit 57 © 2003 Herlihy and Shavit 58

Linearizability Remarks

•History His linearizable if it can be • Some pending invocations extended to G by – Took effect, so keep them – Appending zero or more responses to – Discard the rest pending invocations – Discarding other pending invocations • Condition ÎG ⊂ ÎS • So that G is equivalent to –Means that S respects “real-time order” of G – Legal sequential history S

–where ÎG ⊂ ÎS

© 2003 Herlihy and Shavit 59 © 2003 Herlihy and Shavit 60

10 Example Example

A q.enq(3) A q.enq(3) Complete this B q.enq(4) B q.enq(4) pending B q:void B q:void invocation B q.deq() B q.deq() B q:4 B q:4 B q:enq(6) B q:enq(6) A q:void

© 2003 Herlihy and Shavit 61 © 2003 Herlihy and Shavit 62

Example Example

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

© 2003 Herlihy and Shavit 63 © 2003 Herlihy and Shavit 64

Example Example

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

Equivalent sequential history

© 2003 Herlihy and Shavit 65 © 2003 Herlihy and Shavit 66

11 Concurrency Concurrency

• How much concurrency does • Focus on total methods linearizability allow? – Defined in every state • When must a method invocation •Example: block? – deq() that throws Empty exception –Versus deq() that waits … •Why? – Otherwise, blocking unrelated to synchronization

© 2003 Herlihy and Shavit 67 © 2003 Herlihy and Shavit 68

Concurrency Non-Blocking Theorem If method invocation • Question: When does linearizability A q.inv(…) require a method invocation to block? is pending in history H, then there • Answer: never. exists a response • Linearizability is non-blocking A q:res(…) such that H + A q:res(…) is linearizable

© 2003 Herlihy and Shavit 69 © 2003 Herlihy and Shavit 70

Proof Locality Theorem

• Pick linearization S of H • History H is linearizable if and only if • If S already contains – For every object x – Invocation A q.inv(…) and response, – H|x is linearizable –Then we are done. • We care about objects only! • Otherwise, pick a response such that –(Materialism anyone?) – S + A q.inv(…) + A q:res(…) – Possible because object is total.

© 2003 Herlihy and Shavit 71 © 2003 Herlihy and Shavit 72

12 Why Does Locality Matter? Reasoning About Linearizability

public class Queue { •Modularity int head = 0, tail = 0; Object[QSIZE] items; • Can prove linearizability of objects in public synchronized void enq(Object x) { isolation while (this.tail–this.head == QUEUE_SIZE) this.wait(); •Can compose independently- this.items[tail++ % QUEUE_SIZE] = x; implemented objects this.notifyAll(); } … }}

© 2003 Herlihy and Shavit 73 (2) © 2003 Herlihy and Shavit 74

Reasoning About Linearizability Reasoning About Linearizability

public class Queue { public class Queue { Linearization order is Linearization order is int head = 0, tail = 0; int head = 0, tail = 0; Object[QSIZE] items; order acquired Object[QSIZE] items; order lock acquired

public synchronized void enq(Object x) { public synchronized void enq(Object x) { while (this.tail–this.head == QUEUE_SIZE) while (this.tail–this.head == QUEUE_SIZE) this.wait(); this.wait(); this.items[tail++ % QUEUE_SIZE] = x; this.items[tail++ % QUEUE_SIZE] = x; this.notifyAll(); this.notifyAll(); } } … … Except not exactly because lock }} }} can be released & reacquired …

(2) © 2003 Herlihy and Shavit 75 (2) © 2003 Herlihy and Shavit 76

Now for something completely More Reasoning different public class LockFreeQueue { • Let’s try the same thing without int head = 0, tail = 0; Item[QSIZE] items;

• For simplicity, only two threads public void enq(Item x) { please while (tail-head == QSIZE); // busy-wait items[tail % QSIZE] = x; tail++; } public Item deq() { while (tail == head); // busy-wait Item item = items[head % QSIZE]; head++; return item; }}

© 2003 Herlihy and Shavit 77 © 2003 Herlihy and Shavit 78

13 More Reasoning Strategy public class LockFreeQueueLinearization { order is • Identify one atomic step where int head = 0, tail = 0;order head and tail Item[QSIZE] items; fields modified method “happens”

public void enq(Item x) { – Critical section while (tail-head == QSIZE); // busy-wait – Machine instruction items[tail % QSIZE] = x; tail++; } • Doesn’t always work public Item deq() { while (tail == head); // busy-wait –In theory Item item = items[head % QSIZE]; head++; return item; – Usually works in practice }}

© 2003 Herlihy and Shavit 79 © 2003 Herlihy and Shavit 80

Alternative: Sequential Theorem Consistency • History equivalent to some sequential Sequential Consistency is not a history local property • No need to preserve real-time order • Often used to describe multiprocessor memory architectures

© 2003 Herlihy and Shavit 81 © 2003 Herlihy and Shavit 82

FIFO Queue Example H|p Sequentially Consistent

p.enq(x) q.enq(x) p.deq(y) p.enq(x) q.enq(x) p.deq(y)

q.enq(y) p.enq(y) q.deq(x) q.enq(y) p.enq(y) q.deq(x)

History H

time time

© 2003 Herlihy and Shavit 83 © 2003 Herlihy and Shavit 84

14 H|q Sequentially Consistent Ordering imposed by p

p.enq(x) q.enq(x) p.deq(y) p.enq(x) q.enq(x) p.deq(y) q.enq(y) p.enq(y) q.deq(x) q.enq(y) p.enq(y) q.deq(x)

time time

© 2003 Herlihy and Shavit 85 © 2003 Herlihy and Shavit 86

Ordering imposed by q Combining Orderings

p.enq(x) q.enq(x) p.deq(y) p.enq(x) q.enq(x) p.deq(y) q.enq(y) p.enq(y) q.deq(x) q.enq(y) p.enq(y) q.deq(x)

time time

© 2003 Herlihy and Shavit 87 © 2003 Herlihy and Shavit 88

Not Sequentially Consistent

• A transaction is a finite sequence of p.enq(x) q.enq(x) p.deq(y) method calls

q.enq(y) p.enq(y) q.deq(x) • It is serializable if – transactions appear to execute serially • Strictly serializable if – order is compatible with real-time

time • Used in databases

© 2003 Herlihy and Shavit 89 © 2003 Herlihy and Shavit 90

15 Serializability is Blocking Serializability not Local

• Cannot mix, say d ea – Two-phase locking x.read(0) y.write(1) dl – Timestamp synchronization oc k • May serialize transactions at different objects in opposite orders y.read(0) x.write(1)

© 2003 Herlihy and Shavit 91 © 2003 Herlihy and Shavit 92

Comparison Critical Sections

• Serializability appropriate for • Easy way to implement linearizability – Fault-tolerance – Take sequential object – Multi-step transactions – Make each method a critical section • Linearizability appropriate for • Like synchronized methods in Java™ –Single objects •Problems – Multiprocessor synchronization –Blocking – No concurrency

© 2003 Herlihy and Shavit 93 © 2003 Herlihy and Shavit 94

Summary Summary

•Linearizability •Non-Blocking – Operation takes effect instantaneously – Never required to pause method call between invocation and response • Locality • Uses sequential specification – Can verify linearizability per object –No O(n2)interactions – Can compose correctly • Granularity matters

© 2003 Herlihy and Shavit 95 © 2003 Herlihy and Shavit 96

16 Fact

• Any partial order – Never required to pause method call • Locality – Can verify linearizability per object – Can compose correctly • Granularity matters

© 2003 Herlihy and Shavit 97

17