1 / 42

Designing Correct Concurrent Applications: An Algorithmic View

Designing Correct Concurrent Applications: An Algorithmic View. Hagit Attiya Technion. Concurrent Systems. Concurrent Systems. Programming Languages ( PL ). Distributed Computing ( DC ). Hard to design correct (& efficient!) applications. Main Admin Issues. Mandatory participation

haines
Download Presentation

Designing Correct Concurrent Applications: An Algorithmic View

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. Designing Correct Concurrent Applications: An Algorithmic View Hagit AttiyaTechnion

  2. Concurrent Systems seminar in distributed algorithm (236825)

  3. Concurrent Systems Programming Languages (PL) Distributed Computing (DC) Hard to design correct (& efficient!) applications seminar in distributed algorithm (236825)

  4. seminar in distributed algorithm (236825)

  5. Main Admin Issues • Mandatory participation • 1 absentee w/o explanation • List of papers published later this week • First come first serve • Student lectures start after Passover (in 3 weeks) • Slides in English (encouraged…) seminar in distributed algorithm (236825)

  6. Algorithmic View of Concurrent Systems A collection of processes Each a sequential thread of execution Communicating through shared data structures seminar in distributed algorithm (236825)

  7. data Abstract Data Types (ADT) • Cover most concurrent applications • At least encapsulate their data needs • An object-oriented programming point of view • Abstract representation of data& set of methods (operations) for accessing it • Signature • Specification seminar in distributed algorithm (236825)

  8. Implementing High-Level ADT data data seminar in distributed algorithm (236825)

  9. Implementing High-Level ADT data data Using lower-level ADTs & methods ------------------ ------------------- ------------------ ---------------- ---------------- --------------- ------------------ ------------------- seminar in distributed algorithm (236825)

  10. Lower-Level Operations • High-level operations translate into primitives on base objects • Obvious: read, write (restrictions?) • Common: compare&swap (CAS) • LL/SC, Double-CAS (2CAS, DCAS), kCAS, … • Generic: read-modify-write (RMW), kRMW • Low-level operations are often implemented from more primitive operations • A hierarchy of implementations seminar in distributed algorithm (236825)

  11. Executing Operations invocation response P1 P2 P3 seminar in distributed algorithm (236825)

  12. Interleaving Operations Concurrent (interleaved) execution seminar in distributed algorithm (236825)

  13. Interleaving Operations (External) behavior seminar in distributed algorithm (236825)

  14. Interleaving Operations, or Not Almost complete non-interleaved execution seminar in distributed algorithm (236825)

  15. Interleaving Operations, or Not Sequential behavior: invocations & response alternate and match (on process & object) Sequential Specification: All the legal sequential behaviors, satisfying the semantics of the ADT • E.g., for a (LIFO) stack: pop returns the last item pushed seminar in distributed algorithm (236825)

  16. Correctness: Sequential consistency [Lamport, 1979] • For every concurrent execution there is a sequential execution that • Contains the same operations • Is legal (obeys the sequential specification) • Preserves the order of operations by the same process seminar in distributed algorithm (236825)

  17. push(4) pop():4 push(7) push(4) pop():4 push(7) Sequential Consistency: Examples Concurrent (LIFO) stack  First Out Last In  seminar in distributed algorithm (236825)

  18. push(4) pop():7 push(7) Sequential Consistency: Examples Concurrent (LIFO) stack  First Out Last In seminar in distributed algorithm (236825)

  19. Example 1: Treiber’s stack … val val val Top next next next • Pop(Stack S) • do forever • top := S.top • if top = null • return empty • if compare&swap(S, top, top.next) • return top.val • od seminar in distributed algorithm (236825)

  20. Treiber’s Stack: Proof • Create sequential execution: • Place popoperations in the order of their successful compare&swap primitives • Pop(Stack S) • do forever • top := S.top • if top = null • return empty • if compare&swap(S, top, top.next) • return top.val • od May get stuck & uses CAS seminar in distributed algorithm (236825)

  21. Example 2: Multi-Writer Registers Using (multi-reader) single-writer registers Add logical time (Lamport timestamps) to values Write(v,X) read TS1,..., TSn TSi = max TSj+1 write v,TSi Read only own value Read(X) read v,TSi return v Once in a while read TS1,..., TSn and write to TSi Need to ensure writes are eventually visible seminar in distributed algorithm (236825)

  22. Timestamps Write(v,X) read TS1,..., TSn TSi = max TSj+1 write v,TSi The timestamps of two write operations by the same process are ordered If a write operation completes before another one starts, it has a smaller timestamp seminar in distributed algorithm (236825)

  23. Multi-Writer Registers: Proof Write(v,X) read TS1,..., TSn TSi = max TSj+1 write v,TSi Read(X) read v,TSi return v Once in a while read TS1,..., TSn and write to TSi • Create sequential execution: • Place writes in timestamp order • Insert reads after the appropriate write seminar in distributed algorithm (236825)

  24. Multi-Writer Registers: Proof • Create sequential execution: • Place writes in timestamp order • Insert reads after the appropriate write • Legality is immediate • Per-process order is preserved since a read returns a value (with timestamp) larger than the preceding write by the same process seminar in distributed algorithm (236825)

  25. The Happened-Before Relation a  bmeans that event a happened before event b: • If aand bare events by the same process and aoccurs before b, then a b • If event b obtains information from event athen a b • Usually defined through message passing • But can be extended to read / write • Transitive closure: If a  b and b cthen a c If events a and b by different processes do not exchange information then neither a  b nora  b are true

  26. Timestamps Capture the Happened-Before Relation For timestamps generated as in previous algorithm, we have • If a  b then TS(a) < TS(b) But not vice versa… can have TS(a) < TS(b)but not a  b Need to use vectortimestamps

  27. Causality Captures the Essence of the Computation / / If two executions have the same happened-before relation • Disagree only on the order of events a and b such that neither a  b nor a  b  The executions are indistinguishable to the processes • Each process obtains the same results when invoking primitives on the base objects seminar in distributed algorithm (236825)

  28. enq(Q1,R) enq(Q2,R) deq(Q1,G) enq(Q2,G) enq(Q1,G) deq(Q2,R) Sequential Consistency is not Composable The execution is not sequentially consistent seminar in distributed algorithm (236825)

  29. enq(Q1,R) deq(Q1,G) enq(Q1,G) enq(Q2,R) enq(Q2,G) deq(Q2,R) Sequential Consistency is not Composable Must have common object brokerage Not modular The execution projected on each object is sequentially consistent seminar in distributed algorithm (236825)

  30. Correctness: Linearizability [Herlihy & Wing, 1990] • For every concurrent execution there is a sequential execution that • Contains the same operations • Is legal (obeys the specification of the ADTs) • Preserves the real-time order of non-overlapping operations • Each operation appears to takes effect instantaneously at some point between its invocation and its response (atomicity) seminar in distributed algorithm (236825)

  31. push(4) pop():4 push(7) push(4) pop():4 push(7) Linearizability: Examples Concurrent (LIFO) stack  First Out Last In  seminar in distributed algorithm (236825)

  32. Example 3: Linearizable Multi-Writer Registers [Vitanyi & Awerbuch, 1987] Add logical time to values Write(v,X) read TS1,..., TSn TSi = max TSj+1 write v,TSi Read(X) read TS1,...,TSn return value with max TS Using (multi-reader) single-writer registers seminar in distributed algorithm (236825)

  33. Multi-writer registers: Linearization order Write(v,X) read TS1,..., TSn TSi = max TSj+1 write v,TSi • Create linearization: • Place writes in timestamp order • Insert each read after the appropriate write Read(X) read TS1,...,TSn return value with max TS seminar in distributed algorithm (236825)

  34. Multi-Writer Registers: Proof • Create linearization: • Place writes in timestamp order • Insert each read after the appropriate write • Legality is immediate • Real-time order is preserved since a read returns a value (with timestamp) larger than all preceding operations seminar in distributed algorithm (236825)

  35. Linearizability is Composable The whole system is linearizable  each object is linearizable Allows to implement and verify each object separately seminar in distributed algorithm (236825)

  36. Example 4: Atomic Snapshot update scan v1,…,vn ok n components Update a single component Scan all the components “at once” (atomically) Provides an instantaneous view of the whole memory seminar in distributed algorithm (236825)

  37. Atomic Snapshot Algorithm [Afek, Attiya, Dolev, Gafni, Merritt, Shavit, JACM 1993] double collect Update(v,k) A[k] = v,seqi,i • Scan() • repeat • read A[1],…,A[n] • read A[1],…,A[n] • if equal • return A[1,…,n] • Linearize: • Updates with their writes • Scans inside the double collects seminar in distributed algorithm (236825)

  38. read A[1],…,A[n] read A[1],…,A[n] write A[j] Atomic Snapshot: Linearizability Double collect (read a set of values twice) If equal, there is no write between the collects • Assuming each write has a new value (seq#) Creates a “safe zone”, where the scan can be linearized seminar in distributed algorithm (236825)

  39. Liveness Conditions (Eventual) • Wait-free: every operation completes within a finite number of (its own) steps • no starvation for mutex • Nonblocking: some operation completes within a finite number of (some other process) steps • deadlock-freedom for mutex • Obstruction-free: an operation (eventually) running solo completes within a finite number of (its own) steps • Also called solo termination wait-free  nonblocking  obstruction-free seminar in distributed algorithm (236825)

  40. Liveness Conditions (Bounded) • Wait-free: every operation completes within a bounded number of (its own) steps • no starvation for mutex • Nonblocking: some operation completes within a bounded number of (some other process) steps • deadlock-freedom for mutex • Obstruction-free: an operation (eventually) running solo completes within a bounded number of (its own) steps • Also called solo termination Bounded wait-free  bounded nonblocking  bounded obstruction-free seminar in distributed algorithm (236825)

  41. Wait-free Atomic Snapshot Update(v,k) V = scan A[k] = v,seqi,i,V • Scan() • repeat • read A[1],…,A[n] • read A[1],…,A[n] • if equal • return A[1,…,n] • else record diff • if twice pj • return Vj direct scan • Linearize: • Updates with their writes • Direct scans as before • Borrowed scans in place borrowedscan [Afek, Attiya, Dolev, Gafni, Merritt, Shavit, JACM 1993] Embed a scan within the Update. seminar in distributed algorithm (236825)

  42. embedded scan read A[j] read A[j] read A[j] read A[j] … … … … … … … … write A[j] write A[j] Atomic Snapshot: Borrowed Scans seminar in distributed algorithm (236825) Interference by process pj And another one… • pjdoes a scan inbeteween Linearizing with the borrowed scan is OK.

More Related