Brief Announcement: On the Impossibility of Detecting Concurrency

LIPICS - Leibniz International Proceedings in Informatics, Sep 2018

We identify a general principle of distributed computing: one cannot force two processes running in parallel to see each other. This principle is formally stated in the context of asynchronous processes communicating through shared objects, using trace-based semantics. We prove that it holds in a reasonable computational model, and then study the class of concurrent specifications which satisfy this property. This allows us to derive a Galois connection theorem for different variants of linearizability.

A PDF file should load here. If you do not see its contents the file may be temporarily unavailable at the journal website or you do not have a PDF plug-in installed and enabled in your browser.

Alternatively, you can download the file locally and open with any standalone PDF reader:

http://drops.dagstuhl.de/opus/volltexte/2018/9839/pdf/LIPIcs-DISC-2018-50.pdf

Brief Announcement: On the Impossibility of Detecting Concurrency

LIPIcs.DISC. Brief Announcement: On the Impossibility of Detecting Concurrency ?ric Goubault ?cole Polytechnique Palaiseau France J?r?my Ledent ?cole Polytechnique Palaiseau France Samuel Mimram ?cole Polytechnique Palaiseau France We identify a general principle of distributed computing: one cannot force two processes running in parallel to see each other. This principle is formally stated in the context of asynchronous processes communicating through shared objects, using trace-based semantics. We prove that it holds in a reasonable computational model, and then study the class of concurrent specifications which satisfy this property. This allows us to derive a Galois connection theorem for different variants of linearizability. 2012 ACM Subject Classification Theory of computation ? Concurrency and phrases concurrent specification; concurrent object; linearizability Introduction A common setting to study distributed computing is the one of asynchronous processes communicating through shared objects. In this context, the question of how to formally specify the behavior of the shared objects arises: what we want is an abstract, high-level specification, that does not refer to a particular implementation of the object. This is easy to achieve when the objects that we consider are concurrent versions of sequential data structures, such as lists or queues. Namely, we can simply take the usual sequential specification of the object, and extend it to a concurrent setting using one of the many correctness criteria found in the literature: atomicity [8], sequential consistency [5], serializability [10], causal consistency [11], or linearizability [4]. However, we also want to be able to specify objects with an intrinsically concurrent nature, such as those found in the area of distributed computability [3]: consensus and set-agreement objects, immediate snapshot. Another example is Java?s Exchanger object: two processes that call the Exchanger object concurrently can swap values. A process calling the Exchanger alone fails and receives an error value. A very general way of specifying such objects was proposed by Lamport [6]. The specification of a concurrent object is simply the set of all the execution traces that we consider correct for this object. For example, a correct execution trace of the Exchanger object is depicted below: P0 P1 P2 Exchange(4) Exchange(6) T The trace T consists of invocation events iix meaning that the object was called by process i with input x, and response events riy meaning that process i returned with output value y. This trace can be seen as an abstraction of the real-time execution pictured above, where the horizontal axis represents global time. Formally, for a fixed set V of values and n processes, the set of actions is: A = {iix | 0 ? i < n and x ? V} ? {riy | 0 ? i < n and y ? V} A trace is a word T ? A? such that for every process i, the projection of T on i starts with an invocation and alternates between invocations and responses. We write T for the set of all traces. Then, a concurrent specification in the sense of [6] is simply a subset of T . This notion of concurrent specification is not convenient to use when reasoning about distributed systems. In fact, the correctness criteria such as linearizability can be regarded as more convenient ways of defining such concurrent specifications: starting from a sequential specification ?, we obtain Lin(?) ? T which is the set of all the traces that are linearizable w.r.t. ?. The advantage of this is that sequential specifications are much easier to describe than general concurrent specifications. To specify objects with a more concurrent flavor, variants of linearizability have been described: set-linearizability [9] (a.k.a. concurrency-aware linearizability [2]) and interval-linearizability [1]. The last one is the most expressive: it captures all the distributed tasks, in the sense of [3]. Contribution. In the following, we restrict to a class of concurrent specifications: those satisfying the undetectability of concurrency property. As it turns out, they correspond exactly to the concurrent specifications definable using interval-linearizability. We show that these are the only relevant concurrent specifications, and prove a theorem showing how the different notions of linearizability relate to this property. 2 Results A concurrent specification ? ? T satisfies the undetectability of concurrency property if the following two conditions hold, where a is an action of some process j 6= i. ( 1 ) invocations commute to the left: if T ? a ? iix ? T 0 ? ?, then T ? iix ? a ? T 0 ? ?, (2) responses commute to the right: if T ? riy ? a ? T 0 ? ?, then T ? a ? riy ? T 0 ? ?. Such properties come up in Lipton?s reduction proof technique [7]: ( 1 ) and (2) assert that invocations and responses are left/right movers, respectively. Pictorially, these two properties mean that if we take a correct execution trace (a) and ?expand? the intervals, then the resulting trace (b) must also be considered correct. Intuitively, in (b), the two processes failed to see each other and acted as in the sequential trace (a). (a) Exchange(4) P0 P1 Fail Exchange(7) Fail (b) Exchange(4) P0 P1 Exchange(7) Fail Fail As a naive attempt at specifying the Exchanger object, we might have wanted to allow (a) and forbid (b). But implementing such a specification would have been hopeless, as we show in a reasonable trace-based computational model: I Theorem 1. The semantics JP K of any program P satisfies properties ( 1 ) and (2). Intuitively, the reason why Theorem 1 holds is that calling an object or returning a value does not communicate any information to the other processes. If a process idles right after invoking, or just before returning, it is invisible to the other processes. The undetectability of concurrency property is naturally enforced by the usual specification techniques such as linearizability, so by using these tools we do not have to worry about this property: we get it for free. I Proposition 2. Let ? be a sequential specification. Then Lin(?), the set of all linearizable traces, satisfies properties ( 1 ) and (2). We now write SSpec for the set of sequential specifications, and CSpec for the set of concurrent specifications which satisfy the undetectability of concurrency. Proposition 2 says that we can view Lin as a map from SSpec to CSpec. Conversely, there is also a map in the other direction U : CSpec ? SSpec which, given a concurrent specification, forgets about all the concurrent behaviors and keeps only the sequential ones. I Theorem 3. The functions Lin and U are monotonous w.r.t. inclusions, and form a Galois connection, i.e., for every ? ? SSpec and ? ? CSpec, Lin(?) ? ? ?? ? ? U(? ). The fact that we imposed the undetectability of concurrency property on CSpec is crucial in order to establish Theorem 3. This theorem can be understood as follows: given a sequential specification ?, we want to extend it to a concurrent one. Then any ? ? CSpec that contains ? must also contain Lin(?), i.e., Lin(?) is the smallest extension of ? which is in CSpec. Thus, Lin(?) can be described as follows: we start with the set of all sequential traces of ?, then close it under the two properties ( 1 ) and (2). Finally, note that analogues of Proposition 2 and Theorem 3 still hold when we replace linearizability by set- or interval-linearizability. In particular, Theorem 3 for intervallinearizability gives us the following characterization of interval-linearizable objects: I Corollary 4. The concurrent specifications which are definable using interval-linearizability are exactly the ones satisfying the undetectability of concurrency. 6 7 8 9 10 11 1 2 3 4 5 Armando Casta?eda , Sergio Rajsbaum, and Michel Raynal . Specifying Concurrent Problems: Beyond Linearizability and up to Tasks . In DISC 2015, Proceedings , pages 420 - 435 , 2015 . Nir Hemed , Noam Rinetzky, and Viktor Vafeiadis . Modular Verification of ConcurrencyAware Linearizability . In DISC 2015, Proceedings , pages 371 - 387 , 2015 . Maurice Herlihy , Dmitry Kozlov, and Sergio Rajsbaum . Distributed Computing Through Combinatorial Topology . Morgan Kaufmann Publishers Inc., 2013 . Maurice Herlihy and Jeannette M. Wing . Linearizability: A Correctness Condition for Concurrent Objects . ACM Transactions on Programming Languages and Systems , 12 ( 3 ): 463 - 492 , 1990 . L. Lamport . How to make a multiprocessor computer that correctly executes multiprocess programs . IEEE Transactions on Computers , 28 ( 9 ): 690 - 691 , 1979 . Leslie Lamport . On interprocess communication . Distributed Computing , 1 ( 2 ): 77 - 85 , 1986 . Richard J Lipton. Reduction : A method of proving properties of parallel programs . Communications of the ACM , 18 ( 12 ): 717 - 721 , 1975 . Brookes , Andrew William Roscoe, and Glynn Winskel, editors, Seminar on Concurrency , pages 96 - 110 . Springer Berlin Heidelberg, 1985 . Gil Neiger. Set-Linearizability. In Proceedings of the Thirteenth Annual ACM Symposium on Principles of Distributed Computing, page 396 , 1994 . Christos H. Papadimitriou . The serializability of concurrent database updates . Journal of the ACM , 26 ( 4 ): 631 - 653 , 1979 . M. Raynal , G. Thia-Kime , and M. Ahamad . From serializable to causal transactions for collaborative applications . In Proceedings of the 23rd EUROMICRO , pages 314 - 321 , 1997 .


This is a preview of a remote PDF: http://drops.dagstuhl.de/opus/volltexte/2018/9839/pdf/LIPIcs-DISC-2018-50.pdf

\'Eric Goubault, J\'er\'emy Ledent, Samuel Mimram. Brief Announcement: On the Impossibility of Detecting Concurrency, LIPICS - Leibniz International Proceedings in Informatics, 2018, 50:1-50:4, DOI: 10.4230/LIPIcs.DISC.2018.50