1 / 105

Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer

Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer. Lecture 5: Concurrent Objects. Material From. The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit. Concurrent Computation. memory. object. object. Objectivism. What is a concurrent object?

salma
Download Presentation

Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Concurrent Object-Oriented ProgrammingProf. Dr. Bertrand Meyer Lecture 5: Concurrent Objects

  2. Material From • The Art of Multiprocessor Programming • by Maurice Herlihy & NirShavit

  3. Concurrent Computation memory object object

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

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

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

  7. head tail 0 1 y z capacity-1 2 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]; } Queue fields protected by single shared lock Initially head = tail

  8. head tail 0 1 y z capacity-1 2 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 If queue empty throw exception Queue not empty: remove item and update head Should be correct because modifications are mutually exclusive… Return result Release lock no matter what!

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

  10. head tail 0 1 y z capacity-1 2 Wait-free 2-Thread Queue public class WaitFreeQueue { int head = 0, tail = 0; items = (T[]) new Object[capacity]; public void enq(Item x) { while (tail-head == capacity); // busy-wait items[tail % capacity] = x; tail++; } public Item deq() { while (tail == head); // busy-wait Item item = items[head % capacity]; head++; return item; } } Queue is updated without a lock! How do we define “correct” when modifications are not mutually exclusive?

  11. Defining concurrent queue implementation • Need a way to specify a concurrent queue object • Need a way to prove that an algorithm implements the object’s specification • Lets talk about object specifications

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

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

  14. 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,

  15. Pre- and Postcondition for Dequeue • Precondition: • Queue is non-empty • Postcondition: • Returns first item in queue • Postcondition: • Removes first item in queue

  16. Pre- and Postcondition for Dequeue • Precondition: • Queue is empty • Postcondition: • Throws Empty exception • Postcondition: • Queue state unchanged

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

  18. What about concurrent specifications ? • Methods? • Documentation? • Adding new methods?

  19. invocation 12:00 response 12:01 q.enq(. ) void time Methods take time Method call time

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

  21. time Concurrent methods take overlapping time Method call Method call Method call time

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

  23. 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? …

  24. Sequential vs. Concurrent • Sequential: • Can add new methods without affecting older methods • Concurrent: • Everything can potentially interact with everything else Panic!

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

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

  27. unlock() lock() unlock() lock() time enq deq Intuitively… • Lets capture the idea of describing the concurrent via the sequential q.deq deq q.enq enq Behavior is “Sequential”

  28. 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™

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

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

  31. q.enq(x) q.deq(y) q.enq(y) q.deq(x) time Example linearizable q.enq(x) q.deq(y) q.enq(y) q.deq(x) time

  32. time Example q.enq(x) q.enq(x) Valid? q.deq(y) q.deq(y) q.enq(y) q.deq(x) q.enq(y) q.deq(x) time

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

  34. time Example not linearizable q.enq(x) q.deq(y) q.enq(x) q.enq(y) q.enq(y)

  35. time Example q.enq(x) q.deq(x) time

  36. q.enq(x) q.deq(x) time Example linearizable q.enq(x) q.deq(x) time

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

  38. time Example Commeci Commeça q.enq(x) q.deq(y) linearizable q.enq(y) q.deq(x)

  39. Read/Write Register Example write(0) read(1) write(2) read(0) write(1) write(1) already happened time time

  40. write(1) Read/Write Register Example not linearizable write(0) read(1) write(2) read(0) write(1) write(1) already happened time time

  41. Read/Write Register Example write(0) read(1) write(2) read(1) write(1) write(1) already happened time time

  42. write(2) write(1) Read/Write Register Example not linearizable write(0) read(1) write(2) read(1) write(1) write(1) already happened time time

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

  44. write(2) write(1) Read/Write Register Example linearizable write(0) write(2) read(1) write(1) time time

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

  46. Formal Model of Executions • Define precisely what we mean • Ambiguity is bad when intuition is weak • Allow reasoning • Formal • But mostly informal • In the long run, actually more important

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

  48. thread object Response Notation • Method is implicit A q: void result

  49. thread exception object Response Notation • Method is implicit A q: empty()

  50. History - Describing an Execution • Sequence of invocations and responses A q.enq(3) A q:void A q.enq(5) B p.enq(4) B p:void B q.deq() B q:3 H =

More Related