1 / 110

Computing with Concurrent Objects

Computing with Concurrent Objects. speaker sara tucci piergiovanni institution università di roma “la sapienza” dipartimento di informatica e sistemistica midlab laboratory. Outline. Concurrent Objects Definition The “outside” view-point”

alana-ochoa
Télécharger la présentation

Computing with Concurrent Objects

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. Computing with Concurrent Objects speaker sara tucci piergiovanni institution università di roma “la sapienza” dipartimento di informatica e sistemistica midlab laboratory

  2. Outline • Concurrent Objects Definition • The “outside” view-point” Linearizability: what makes a concurrent object a “meaningful” programming abstraction • The “inside” view-point Wait-free implementation: what makes a concurrent object a “possible” programming abstraction • A “global” look to the universe of concurrent objects Object hierarchy: what makes happy a “would-be theoretician” like me  Seminars in Distributed Computing - Computing with Concurrent Objects

  3. Lecture1: the “outside” view-point speaker sara tucci piergiovanni institution università di roma “la sapienza” dipartimento di informatica e sistemistica midlab laboratory

  4. What is an object? • An objectin languages such as Java and C++ is a container for data. • Each object provides a set of methods that are the only way to manipulate that object’s state. • Each object has a class which describes how its methods behave • Object description • The application programmer interface (API) • pre-condition (describing the object’s state before invoking the method) • post-condition, describing the object’s state and return value after the method returns. • For example, if the FIFO queue object is non-empty (pre-condition), then the deq() method will remove and return the first element (post-condition), and otherwise it will throw an exception (another pre- and post-condition). Seminars in Distributed Computing - Computing with Concurrent Objects

  5. Pre and Post Conditions • Defining objects in terms of pre-conditions and post-conditions makes perfect sense in a sequential model computation where a single thread manipulates a collection of objects. • In this case methods are called once at a time, each method invocation is followed by the corresponding return and a sequence of method calls can be defined method invocation exception p enq(a;ok) enq(b;ok) deq( ;a) deq( ;b) deq() time method response Seminars in Distributed Computing - Computing with Concurrent Objects

  6. Concurrent Model • If an object’s methods can be invoked by concurrent threads, then the method executions can overlap in time, and it no longer makes sense to talk about the order of method calls. • What does it mean, in a multithreaded program, if a and b are enqueued on a FIFO queue during overlapping intervals? Which will be dequeued first? where is the trick? p method call enq(a;ok) deq( ;?) enq(a;ok) queue’s state a a a a a a a at the end of the invocation, the queue surely contains a, but during the invocation what did it happen? God knows deq( ;?) q enq(b;ok) Seminars in Distributed Computing - Computing with Concurrent Objects

  7. The Linearizability Manifesto • The Linearizability Manifesto. Each method call should appear to “take effect” instantaneously at some moment between its invocation and response. p enq(a;ok) deq( ;b) deq( ;a) q enq(b;ok) time S a a b b Seminars in Distributed Computing - Computing with Concurrent Objects

  8. Linearizability: scenario • Again, is this execution linearizable? ...try to put a point for each method call... p enq(a;ok) enq(b;ok) deq( ;a) q deq( ;c) r enq(c;ok) deq( ;b) S c c a a c b a a b Seminars in Distributed Computing - Computing with Concurrent Objects

  9. Linearizability: scenario • Again, is this execution linearizable? ...try to put a point for each method call... p enq(b;ok) enq(c;ok) q enq(a;ok) deq( ;a) r deq( ;b) deq( ;c) S b b b no way... c c a Seminars in Distributed Computing - Computing with Concurrent Objects

  10. Formalizing Linearizability • Until now we had fun by putting points here and there...now the play is getting harder...we should formalize what putting points would mean  -------------------------------- Definitions and Basic Notation ---------------------------------------- • An execution of a concurrent system is modeled by a history H, which is a finite sequence of method invocationand responseevents. • A method invocation event is denoted as < inv (op(args), X) p> • A method response event is denoted as < res (op(res), X) p> where op is the name of the method, args is a list of input arguments, res is a list of results (ok for void) , X is the name of the object, p the name of the process. -------------------------------------------------------------------------------------------------------------------- p enq(a;ok) t res (enq(ok), X) p H: inv (enq(a), X) p Seminars in Distributed Computing - Computing with Concurrent Objects

  11. Formalizing Linearizability • Concurrent execution example and related History p enq(a;ok) deq( ;a) deq( ;b) q enq(b;ok) H: inv(enq(a),X)p, res(enq(ok)X)p, inv(enq(b)X)q, res(enq(ok)X)q, inv(deq()X)p, res(deq(a)X)p, inv(deq()X)q, res (deq(b)X)q Seminars in Distributed Computing - Computing with Concurrent Objects

  12. Formalizing Linearizability • Concurrent execution example and related History p enq(a;ok) deq( ;a) deq( ;b) q enq(b;ok) H: inv(enq(a),X)p, inv(enq(b)X)q, res(enq(ok)X)p, res(enq(ok)X)q, inv(deq()X)p, inv(deq()X)q, res(deq(a)X)p res (deq(b)X)q Seminars in Distributed Computing - Computing with Concurrent Objects

  13. Formalizing Linearizability -------------------------------------------- Definitions --------------------------------------------- • A response matches an invocation if their objects names agree and their process names agree. • An invocation is pendingin a history if no matching response follows the invocation. • If H is a history, complete(H) is the maximal subsequence of H consisting only of invocations and matching responses. ----------------------------------------------------------------------------------------------------------------------- Seminars in Distributed Computing - Computing with Concurrent Objects

  14. Formalizing Linearizability • Concurrent execution example and related History p enq(a;ok) deq( ; deq( ;) q enq(b;ok) H: inv(enq(a),X)p, inv(enq(b)X)q, res(enq(ok)X)p, res(enq(ok)X)q, inv(deq()X)p, inv(deq()X)q complete(H): inv(enq(a),X)p, inv(enq(b)X)q, res(enq(ok)X)p, res(enq(ok)X)q matching matching pending pending Seminars in Distributed Computing - Computing with Concurrent Objects

  15. FormalizingLinearizability ----------------------------------------- Definitions ----------------------------------------- • A history H is sequential if • (1) The first event of H is an invocation. • (2) Each invocation, except possibly the last, is immediately followed by a matching response. A history that is not sequential is concurrent. • A process subhistory, H|p (H at p), of a history H is the subsequence of all events in H whose process names are p. (An object subhistory H|X is similarly defined for an object X.) • Two histories H and H’ are equivalentif for every process p, H|p = H’|p. • A history H is well-formed if each process subhistory H|p of H issequential (in the following we will assume well-formed subhistories) ----------------------------------------------------------------------------------------------------------------------------------------------------- Seminars in Distributed Computing - Computing with Concurrent Objects

  16. Formalizing Linearizability • Sequential History H p enq(a;ok) deq( ;a) deq( ;b) q enq(b;ok) H: inv(enq(a),X)p, res(enq(ok)X)p, inv(enq(b)X)q, res(enq(ok)X)q, inv(deq()X)p, res(deq(a)X)p, inv(deq()X)q, res (deq(b)X)q H|p: inv(enq(a),X)p, res(enq(ok)X)p, inv(deq()X)p, res(deq(a)X)p H|q: inv(enq(b)X)q, res(enq(ok)X)q, inv(deq()X)q, res (deq(b)X)q well-formed subhistories Seminars in Distributed Computing - Computing with Concurrent Objects

  17. Formalizing Linearizability • Concurrent History H’ p enq(a;ok) deq( ;a) deq( ;b) q enq(b;ok) H’: inv(enq(a),X)p, inv(enq(b)X)q, res(enq(ok)X)p, res(enq(ok)X)q, inv(deq()X)p, inv(deq()X)q, res(deq(a)X)p, res (deq(b)X)q H’|p: inv(enq(a),X)p, res(enq(ok)X)p, inv(deq()X)p, res(deq(a)X)p H’|q: inv(enq(b)X)q, res(enq(ok)X)q, inv(deq()X)q, res (deq(b)X)q H and H’ are equivalent Seminars in Distributed Computing - Computing with Concurrent Objects

  18. Formalizing Linearizability ---------------------------------- Definitions --------------------------------------------------- • A history H induces an irreflexive partial order  Hon methods: op1  H op2 if res(op1) precedes inv(op2) in H. • If H is sequential, then  His a total order. ----------------------------------------------------------------------------------------------------------------------- p enq(a;ok) deq( ;a) deq( ;b) q enq(b;ok) H’: inv(enq(a),X)p, inv(enq(b)X)q, res(enq(ok)X)p, res(enq(ok)X)q, inv(deq()X)p, inv(deq()X)q, res(deq(a)X)p, res (deq(b)X)q enq(a)  H’deq(a) enq(a)  H’deq(b) enq(b)  H’deq(b) enq(b)  H’deq(a) Seminars in Distributed Computing - Computing with Concurrent Objects

  19. FormalizingLinearizability ---------------------------------- Definitions ----------------------------------------------------- • A set S of histories is prefix-closedif whenever H is in S, every prefix of H is also in S. • A sequential specificationfor an object is a prefix-closed set of sequential histories for the object. • A sequential history H is legalif each object subhistory H|X belongs to the sequential specification for X. ----------------------------------------------------------------------------------------------------------------------- Linearizability A history H is linearizable if it can be extended to a history H’ (by appending zero or more response events to H) such that: L1 : complete(H’) is equivalent to some legal sequential history S, and L2 : H’ S. Seminars in Distributed Computing - Computing with Concurrent Objects

  20. Linearizability • Informally, extending H to H’ captures the idea that some pending invocations may have taken effect even though their responses have not yet been returned to the caller. This is visible when some successive method call returns a value set by a pending invocation. • Extending H to H’ while restricting attention to complete(H’) makes it possible to complete pending methods, or just to ignore them. • L1 states that complete(H’) is equivalent to an apparent sequential interleaving of method calls that does not violate the specification of the object. • L2 states that this apparent sequential interleaving respects the precedence ordering of methods. Seminars in Distributed Computing - Computing with Concurrent Objects

  21. Linearizability • Then, let’s try to find S... p enq(a; deq( ; deq( ; b) deq( ; a) q enq(b;ok) H: inv(enq(a),X)p, inv(enq(b)X)q, res(enq(ok)X)q, inv(deq()X)p, inv(deq()X)q, res (deq(b)X)q, inv(deq()X)q, res (deq(a)X)q step1: extending... H’: inv(enq(a),X)p, res(enq(ok)X)p, inv(enq(b)X)q, res(enq(ok)X)p, inv(deq()X)p, inv(deq()X)q, res (deq(b)X)q, inv(deq()X)q, res (deq(a)X)q Seminars in Distributed Computing - Computing with Concurrent Objects

  22. Linearizability step2: completing... complete(H’): inv(enq(a),X)p, res(enq(ok)X)p, inv(enq(b)X)q, res(enq(ok)X)p, inv(deq()X)p, inv(deq()X)q, res (deq(b)X)q, inv(deq()X)q, res (deq(a)X)q p enq(a;ok) deq( ; b) deq( ; a) q enq(b;ok) step3: let me see the partial order... enq(a)  H’deq(b)  H’deq(a) enq(b)  H’deq(b)  H’deq(a) step4: ordering what is not yet ordered... S: enq(b)  Senq(a)  S deq(b)  Sdeq(a) we got it! Seminars in Distributed Computing - Computing with Concurrent Objects

  23. To do... • Linearizability has the following property: Theorem : H is linearizable if and only if for each object x, H|x is linearizable. • To investigate if locality holds for the following alternative correctness criteria: • Sequential consistency: only L1 • Serizability: A history is serializable if it is equivalent to one in which transactions appear to execute sequentially, that is, without interleaving. Transaction: finite sequence of methods to a set of objects Seminars in Distributed Computing - Computing with Concurrent Objects

  24. Lecture 2: the “inside” view-point speaker sara tucci piergiovanni institution università di roma “la sapienza” dipartimento di informatica e sistemistica midlab laboratory

  25. Objects Implementation • So, let us suppose now to have a concurrent object to implement, e.g. stack, queue, etc. • how can we implement it? to get a linearizable execution, we can try to use some form of synchronization, e.g. to rule the access of the object by using of locks, mutex to define critical sections • The only one that can release the lock is the one who acquired the lock • but we want also cope with failures...we want that a process gets a response in a finite time, no matter the failures of others... • So, if a process in the critical section fails? Seminars in Distributed Computing - Computing with Concurrent Objects

  26. Wait-free object implementation • The meaning of wait-free computing is exaclty the following: each process (that does not crash) calling a method must be able to get a response in a finite time no matter of how slow other proccesses are and failures of other processes • To introduce wait-free computing we will consider the wait-free implementation of two concurrent objects • A renaming object allows the processes to acquire new names from a smaller name space despite possible process crashes • A snapshot object provides the processes with an array-like data structure (with one entry per process) offering two operations. The write operation allows a process to update its own entry. The snapshot operation allows a process to read all the entries in such a way that the reading of the whole array appears as it is was an atomic operation. Seminars in Distributed Computing - Computing with Concurrent Objects

  27. Setting • We consider n processes, up to f are faulty (stop prematurely by crashing) • We will consider to use as building blocks for our implementation some basic concurrent objects, called atomic registers, that behave like registers accessed sequentially (so, we are implicitly assuming that the implementation of registers has been already done...later we will come back on this point) • Then processes can access these registers by invoking write() and read() operations Seminars in Distributed Computing - Computing with Concurrent Objects

  28. M-Renaming Problem • Let us assume that the n processes have arbitrarily large (and distinct) initial names id1, . . . , idn  [0, . . . , N − 1], where n <<< N. In the M-renaming problem, each process pi knows only its initial name idi, and the processes are required to get new names in such a way that the new names belong to the set {0, . . . , M − 1}, M<< N, and no two processes obtain identical names. • More formally, the problem is defined by the three following properties: Termination. Each correct process decides a new name. Validity.A decided name belongs to [0, . . . , M − 1]. Agreement.No two processes decide the same name. Seminars in Distributed Computing - Computing with Concurrent Objects

  29. Implementation • Note that the renaming problem is a problem of allocation (one process for each name) • We assume the presence of MultiWriterMultiReader registers • We will see a simple and elegant algo by Moir–Anderson. • It uses a mechanism called splitter that is particularly suited to wait-free computing (the splitter has been used to implement wait-free mutual exclusion) The renaming problem is trivial when no process can commit a crash failure. Differently, it has been shown that there is no wait-free solution to the M-renaming problem when M < n+ f , where f is an upper bound on the number of processes that can crash Seminars in Distributed Computing - Computing with Concurrent Objects

  30. Wait-free Splitter X=undefined Y=false stop= empty right=emtpy down=empty Seminars in Distributed Computing - Computing with Concurrent Objects

  31. Splitter X=green Y=false stop= empty right=emtpy down=empty Seminars in Distributed Computing - Computing with Concurrent Objects

  32. Splitter X=green Y=false stop= empty right=emtpy down=empty Seminars in Distributed Computing - Computing with Concurrent Objects

  33. Splitter X=green Y=false stop= empty right=emtpy down=empty Seminars in Distributed Computing - Computing with Concurrent Objects

  34. Splitter X=green Y=false stop= empty right=emtpy down=empty Seminars in Distributed Computing - Computing with Concurrent Objects

  35. Splitter X=green Y=true stop= empty right=emtpy down=empty Seminars in Distributed Computing - Computing with Concurrent Objects

  36. Splitter X=green Y=true stop= empty right=emtpy down=empty yawn Seminars in Distributed Computing - Computing with Concurrent Objects

  37. Splitter X=red Y=true stop= empty right=emtpy down=empty zzzz Seminars in Distributed Computing - Computing with Concurrent Objects

  38. Splitter X=red Y=true stop= empty right=emtpy down=empty zzzz Seminars in Distributed Computing - Computing with Concurrent Objects

  39. Splitter X=red Y=true stop= empty right={red} down=empty zzzz Seminars in Distributed Computing - Computing with Concurrent Objects

  40. Splitter X=red Y=true stop= empty right={red} down=empty zzzz Seminars in Distributed Computing - Computing with Concurrent Objects

  41. Splitter X=red Y=true stop= empty right={red} down=empty awake! Seminars in Distributed Computing - Computing with Concurrent Objects

  42. Splitter X=red Y=true stop= empty right={red} down=empty Seminars in Distributed Computing - Computing with Concurrent Objects

  43. Splitter X=red Y=true stop= empty right={red} down={green} Seminars in Distributed Computing - Computing with Concurrent Objects

  44. Splitter X=red Y=true stop= empty right={red} down={green} Seminars in Distributed Computing - Computing with Concurrent Objects

  45. Splitter X=red Y=true stop= empty right={red} down={green} Note that green was slow and red was in late, nobody got stop Seminars in Distributed Computing - Computing with Concurrent Objects

  46. Splitter X=undefined Y=false stop= empty right=emtpy down=empty Seminars in Distributed Computing - Computing with Concurrent Objects

  47. Splitter X=green Y=false stop= empty right=emtpy down=empty Seminars in Distributed Computing - Computing with Concurrent Objects

  48. Splitter X=green Y=false stop= empty right=emtpy down=empty Seminars in Distributed Computing - Computing with Concurrent Objects

  49. Splitter X=green Y=false stop= empty right=emtpy down=empty Seminars in Distributed Computing - Computing with Concurrent Objects

  50. Splitter X=green Y=false stop= empty right=emtpy down=empty Seminars in Distributed Computing - Computing with Concurrent Objects

More Related