Unifying Concurrent Objects and Distributed Tasks

Abstract

Tasks and objects are two predominant ways of specifying distributed problems where processes should compute outputs based on their inputs. Roughly speaking, a task specifies, for each set of processes and each possible assignment of input values, their valid outputs. In contrast, an object is defined by a sequential specification. Also, an object can be invoked multiple times by each process, while a task is a one-shot problem. Each one requires its own implementation notion, stating when an execution satisfies the specification. For objects, linearizability is commonly used, while tasks implementation notions are less explored. The article introduces the notion of interval-sequential object, and the corresponding implementation notion of interval-linearizability , to encompass many problems that have no sequential specification as objects. It is shown that interval-sequential specifications are local , namely, one can consider interval-linearizable object implementations in isolation and compose them for free, without sacrificing interval-linearizability of the whole system. The article also introduces the notion of refined tasks and its corresponding satisfiability notion. In contrast to a task, a refined task can be invoked multiple times by each process. Also, objects that cannot be defined using tasks can be defined using refined tasks. In fact, a main result of the article is that interval-sequential objects and refined tasks have the same expressive power and both are complete in the sense that they are able to specify any prefix-closed set of well-formed executions. Interval-linearizability and refined tasks go beyond unifying objects and tasks; they shed new light on both of them. On the one hand, interval-linearizability brings to task the following benefits: an explicit operational semantics, a more precise implementation notion, a notion of state, and a locality property. On the other hand, refined tasks open new possibilities of applying topological techniques to objects.

60 Years of Mastering Concurrent Computing through Sequential Thinking

“…Fast mutual exclusion 1977, 1983 1993, 1997 Shared memory on top of asynchronous message-passing systems Peterson [71] Ben-Or [6], Rabin [73] Alpern, Schneider [1] Herlihy [44] Lamport [58] Pease, Shostak, Lamport [70] Fischer, Lynch, Paterson [34] Herlihy, Moss [46], Shavit, Touitou [85] Attiya, Bar Noy, Dolev [3] Chandra, Hadzilacos, Toueg [17] Nakamoto [66] 1965…”

“…Finally, another fundamental limitation to the approach of mastering concurrency through sequential reasoning is that not all concurrent problems of interest have sequential specifications. Many examples are discussed in [17]. Thus, the need for a formalism that extends the usual way of specifying a concurrent object through an automaton, to one that specifies the output of the object also in concurrent invocations of operations.…”

“…An interval-sequential automaton generalizes the usual sequential automaton, and interval-linearizability is the corresponding notion, that associates concurrent executions to the specification defined by the interval-automaton. This is the formalism described in [17], that generalizes linearizability to arbitrary concurrent specifications.…”

Mastering concurrent computing through sequential thinking

“…Finally, another fundamental limitation to the approach of mastering concurrency through sequential reasoning is that not all concurrent problems of interest have sequential specifications. Many examples are discussed in [11], where a generalization of linearizability to arbitrary concurrent specifications is proposed.…”

Tasks in Modular Proofs of Concurrent Algorithms

“…Recently it was observed in [9] that some natural tasks specify concurrency dependencies that are beyond the set-linearizability and concurrency-aware formalisms, hence that paper proposed interval linearizability. In an interval-sequential object not only sets of operations can occur concurrently but some of these operations might be pending and then overlap operations in the next transition; thus each operation corresponds to an interval instead of a single point.…”