ReadWrite Memory and Set Consensus as an Affine Task
Abstract
The waitfree readwrite memory model has been characterized as an iterated Immediate Snapshot (IS) task. The IS task is affine—it can be defined as a (sub)set of simplices of the standard chromatic subdivision. It is known that the task of Weak Symmetry Breaking (WSB) cannot be represented as an affine task. In this paper, we highlight the phenomenon of a “natural” model that can be captured by an iterated affine task and, thus, by a subset of runs of the iterated immediate snapshot model. We show that the readwrite memory model in which, additionally, setconsensus objects can be used is, unlike WSB, “natural” by presenting the corresponding simple affine task captured by a subset of round IS runs. Our results imply the first combinatorial characterization of models equipped with abstractions other than readwrite memory that applies to generic tasks.
1 Introduction
A principal challenge in distributed computing is to devise protocols that operate correctly in the presence of failures, given that system components (processes) are asynchronous.
The most extensively studied waitfree model of computation [20] makes no assumptions about the number of failures that can occur, no process should wait for other processes to move for making progress. In particular, in a waitfree solution of a distributed task, a process participating in the computation should be able to produce an output regardless of the behavior of other processes.
Topology of waitfreedom. Waitfree task solvability in the readwrite sharedmemory model has been characterized in a very elegant way through the existence of a specific continuous map from geometrical structures describing inputs and outputs of the task [23, 21]. A task is waitfree solvable using reads and writes if and only if there exists a simplicial, chromatic map from a subdivision of the input simplicial complex to the output simplicial complex, satisfying the specification of . Thus, using the iterated standard chromatic subdivision [21] (one such iteration of the standard simplex , denoted by , is depicted in Figure 1), we obtain a combinatorial representation of the waitfree model. Iterations of this subdivision capture precisely rounds of the iterated immediate snapshot (IIS) model [5, 23].
This characterization can be interpreted as follows: the persistent waitfree readwrite model can be captured, regarding task solvability, by an iterated (oneshot) Immediate Snapshot task. Immediate Snapshot is, in turn, captured by the chromatic simplex agreement task [5, 23] on .
Beyond waitfreedom: concurrency and set consensus. Unfortunately, very few tasks are solvable waitfree in the readwrite sharedmemory model [3, 23, 29], so a lot of efforts have been applied to characterizing task solvability in various restrictions of the waitfree model.
A straightforward way to define such a restriction is to bound the concurrency level of runs [13]: in the model of concurrency, at most processes can be concurrently active, i.e., after the invocation of a task and before terminating it. This is a powerful abstraction known, when it comes to solving tasks, to be equivalent to the waitfree model in which processes, in addition to readwrite shared memory, can access set consensus objects [12]. Also, the concurrent task solvability proved to be a good way to measure the power of sharedmemory models equipped with failure detectors [8].
Can we represent the model of readwrite memory and set consensus as an iterated task?
Iterated tasks for set consensus. We show that the model of readwrite memory and set consensus objects can be captured by an iterated affine task [15]. The task is defined via a simplicial complex , a specific subset of simplices of the second chromatic subdivision [21] in which, intuitively, at most processes concurrently contend. (Examples of and for the process system are given in Figure 3.) We show that the set of IIS runs corresponding to iterations of this subcomplex , denoted allows for solving precisely the same set of tasks as the model of set consensus does.
Interestingly, our definition of what it means to solve a task in requires every process to output. This contrasts with the conventional definition of task solvability (e.g., using setconsensus), where a failure may prevent a process from producing an output and, thus, only correct processes can be required to output. Indeed, does not account for process failures: every process takes infinitely many steps in every run, but, because of the use of iterated memory, a “slow” process may not be seen by “faster” ones from some point. The requirement that every process outputs is indispensable in an iterated characterization of generic (colored) task solvability that may not allow one process to “adopt” an output of another process. Indeed, even if “fast” processes output, the “slow” ones should be able to continue in order to enable every correct process to output in the corresponding setconsensus model. For example, task solvability with consensus objects is captured by the “total order” subcomplex (depicted for processes in the left part of Figure 3) in which, intuitively, every subset of processes should be able to solve consensus.
Our result is established by the existence of two algorithms. The first algorithm solves the simplex agreement task [23] on in the model concurrency. By iterating this solution, we can implement and, thus, solve any task solvable in . Then, by showing that the set consensus model solves every task that the concurrency model solves, we derive that the former model also solves every task solvable in . The second algorithm simulates runs of a given algorithm using readwrite memory and setconsensus objects in . The simulation is quite interesting in its own right. Compared to simulations in [22, 17, 14, 7, 16], our algorithm ensures that every process eventually outputs in , assuming that the simulated algorithm ensures that every correct process eventually outputs.
Thus, a task is solvable using iterations of if and only if it can be solved solvable waitfree using setconsensus objects or, equivalently, concurrently. Therefore, the setconsensus model has a bounded representation as an iterated affine task: processes simply sequentially invoke instances of for a bounded number of times, until they assemble enough knowledge to produce an output for the task they are solving.
Our results suggest a separation between “natural” models that have a matching affine task and, thus, can be captured precisely by a subset of IIS runs and less “natural” ones, like WSB, having a manifold structure that is not affine [18]. We conjecture that such a combinatorial representation can also be found for a large class of restrictions of the waitfreedom, beyond concurrency and set consensus. The claim is supported by a recent derivation of the resilience affine task [30].
Related work. There have been several attempts to extend the topological characterization of [23] to models beyond waitfree [22, 14, 16]. However, these results either only concern the special case of colorless tasks [22], consider weaker forms of solvability [14], or also introduce a new kind of infinite subdivisions [16].
In particular, Gafni et al. [16] characterized task solvability in models represented as subsets of IIS runs via infinite subdivisions of input complexes. This result assumes a limited notion of task solvability in the iterated model that only guarantees outputs to “fast” processes [10, 27, 7] that are “seen” by every other process infinitely often.
In contrast with the earlier work, this paper studies the inherent combinatorial properties of general (colored) tasks and assumes the conventional notion of task solvability. In a sense, our results for the first time truly capture the combinatorial structure of a model of computation beyond the waitfree one.
Roadmap. The rest of the paper is organized as follows. Section 2 gives model definitions, briefly overviews the topological representation of iterated sharedmemory models. In Section 3, we present the definition of corresponding to the concurrency model. In Section 4, we show that can be implemented in the setconsensus model and that any task solvable in the setconsensus model can be solved by iterating . Section 5 discusses related models and open questions.
2 Preliminaries
Let be a system composed of asynchronous processes, . We consider two models of communication: (1) atomic snapshots [1] equipped with set consensus objects and (2) iterated immediate snapshots [5, 23].
Atomic snapshots and set consensus. The atomicsnapshot (AS) memory is represented as a vector of shared variables, where processes are associated to distinct vector positions, and exports two operations: update and snapshot. An update operation performed by replaces the shared variable at position with a new value and a snapshot returns the current state of the vector.
The model in which only AS can be invoked is called the AS model. The model in which can be invoked, in addition to AS, also set consensus objects, for some fixed , is called the set consensus model.
Iterated immediate snapshots. In the iterated immediate snapshot (IIS) model [5], processes goes through the ordered sequence of independent memories , , . Each memory is accessed by a process with a single immediate snapshot operation [4]: the operation performed by takes a value and returns a set of values submitted by other processes (w.l.o.g, we assume that values submitted by different processes are distinct), so that the following properties are satisfied: (selfinclusion) ; (containment) ; and (immediacy) .
In the IIS communication model, we assume that processes run the fullinformation protocol: the first value each process writes is its input value. For each , the outcome of the immediate snapshot operation on memory is submitted as the value for the immediate snapshot operation on memory . After a certain number of such (asynchronous) rounds, a process may gather enough information to decide, i.e., to produce an irrevocable non output value. A run of the IIS communication model is thus a sequence , and , determining the outcome of the immediatesnapshot operation for every process and each iterated memory .
Failures and participation. In the AS or set consensus model, a process that takes only finitely many steps of the fullinformation protocol in a given run is called faulty, otherwise it is called correct. A process is called participating if it took at least one step in the computation. We assume that in its first step, a process writes its input in the shared memory. The set of participating processes in a given run is called the participating set. Note that, since every process writes its input value in its first step, the inputs of participating processes are eventually known to every process that takes sufficiently many steps.
In contrast, the IIS model does not have the notion of a faulty process. Instead, a process may appear “slow” [27, 9], i.e., be late in accessing iterated memories from some point on so that some “faster” processes do not see them.
Tasks. In this paper, we focus on distributed tasks [23]. A process invokes a task with an input value and the task returns an output value, so that the inputs and the outputs across the processes which invoked the task, respect the task specification. Formally, a task is defined through a set of input vectors (one input value for each process), a set of output vectors (one output value for each process), and a total relation that associates each input vector with a set of possible output vectors. An input denotes a not participating process and an output value denotes an undecided process. Check [21] for more details on the definition.
Protocols and runs. A protocol is a distributed automaton that, for each local state of a process, stipulates which sharedmemory operation and which state transition the process is allowed to perform in its next step. We assume here deterministic protocols, where only one operation and state transition is allowed in each state. A run of a protocol is defined as a sequence of states and sharedmemory operations.
A process is called active at the end of a finite run if it participates in but did not returned at the end of . Let denote the set of all processes that are active at the end of .
A run is concurrent () if at most processes are concurrently active in , i.e., R. The concurrency model is the set of concurrent AS runs.
Solving a task. A protocol solves a task in the setconsensus model (resp., concurrently) if it ensures that in every run of the setconsensus model (resp., every concurrent AS run) in which processes start with an input vector , (1) all decided values form a vector such that , and (2) every correct process decides.
It is known that the concurrency model is equivalent to the setconsensus model [12]^{3}^{3}3In fact, this paper contains a selfcontained proof of this equivalence result.: any task that can be solved concurrently can also be solved in the setconsensus model, and vice versa.
Standard chromatic subdivision and IIS. To give a combinatorial representation of the IIS model, we use the language of simplicial complexes [31, 21]. In short, a simplicial complex is defined as a set of vertices and an inclusionclosed set of vertex subsets, called simplices. The dimension of a simplex is is the number of vertices in it minus one. Any subset of these vertices is called a face of the simplex. A simplicial complex is pure (of dimension ) if each its simplices are contained in a simplex of dimension .
A simplicial complex is chromatic if it is equipped with a coloring noncollapsing map from its vertices to the standard simplex of vertices, in onetoone correspondence with colors . All simplicial complexes we consider here are pure and chromatic.
Refer to Appendix A for more details on the formalism.
For a chromatic complex , we let be the subdivision of obtained by replacing each simplex in with its chromatic subdivision [23, 24, 25]. The vertices of are pairs , where is a vertex of and is a simplex of containing . vertices , , form a simplex if all are distinct and all satisfy the properties of immediate snapshots. Subdivision for the dimensional simplex is given in Figure 1. Each vertex represents a local state of one of the three processes , and (red for , blue for and white for ) after it takes a single immediate snapshot. Each triangle (simplex) represents a possible state of the system. A corner vertex corresponds to a local state in which the corresponding process only sees itself (it took its snapshot before the other two processes moved). An interior vertex corresponds to a local state in which the process sees all three processes. The vertices on the dimensional faces capture the snapshots of size .
If we iterate this subdivision times, each time applying the same subdivision to each of the simplices, we obtain the chromatic subdivision, . It turns out that precisely captures the round (fullinformation) IIS model, denoted IS [23]. Each run of IS corresponds to a simplex in . Every vertex of is thus defined as , where each is interpreted as the set of processes appearing in the IS iteration obtained by in the corresponding run. The carrier of vertex is then defined as the set of all processes seen by in this run, possibly through the views of other processes: it is the smallest face of that contains in its geometric realization [21] (Appendix A).
Simplex agreement. As we show in this paper, the model of concurrency can be captured by an iterated simplex agreement task [5, 23].
Let be a subcomplex of . In the simplex agreement task, every process starts with the vertex of of its color as an input and finishes with a vertex of as an output, so that all outputs constitute a simplex of contained in the face of constituted by the participating processes.
Formally, the task is defined as , where, for every face , . By running iterations of this task, we obtain , a subcomplex of , corresponding to a subset of runs (each iteration includes two IS rounds).
3 The complex of set consensus
We now define , a subcomplex of , that precisely captures the ability of set consensus (and readwrite memory) to solve tasks. The definition of is expressed via a restriction on the simplices of that bounds the size of contention sets. Informally, a contention set of a simplex (or, equivalently, of an run) is a set of processes that “see each other”. When a process starts its execution after another process terminates, must observe ’s input, but not vice versa. Thus, a set of processes that see each others’ inputs must have been concurrently active at some point. Note that processes can be active at the same time but the immediate snapshots outputs might not permit to detect it.
Topologically speaking, a contention set of a simplex is a set of processes in sharing the same carrier, i.e., a minimal face that contains their vertices. Thus, for a given simplex , the set of contention sets is defined as follows:
Definition 1 (Contention sets)
Contention sets for simplices of in a process system are depicted in Figure 2: for each simplex , every face of that constitutes a red simplex is a contention set of . In an interior simplex, every set of processes are contention sets. Every “total order” simplex (shown in blue in Figure 3), matching a run in which processes proceed, one by one, in the same order in both and , has only three singleton as contending sets. All other simplices include a contention set of two processes which consists of the vertices at the boundary.
Now is defined as the set of all simplices in , in which the contention sets of have cardinalities at most :
Definition 2 (Complex )
It is immediate that the set of simplices in constitutes a simplicial complex: every face of is also in .
4 From set consensus to and back
We show that any task solvable with set consensus (and readwrite shared memory) can be solved in , and vice versa. The main result is then established via simulations: a run of an algorithm solving a task in one model is simulated in the other.
4.1 From set consensus to concurrency
We first show that a concurrent shared memory system is equivalent, regarding task solvability, to a shared memory system enhanced with set consensus objects. The result has been stated in a technical report [12], but no explicit proof has been given available in the literature until now, and we fill the gap below. For the sake of completeness and to make referencing simpler, we propose here a direct simulation with proofs.
Simulating a process shared memory system. We employ generalized state machines (proposed in [13] and extended in [28]) that allow for simulating a process readwrite memory system in the setconsensus model. To ensure consistency of simulated read and write operations, we use commitadopt objects [10] that can be implemented using reads and writes. A commitadopt object exports one operation that takes a parameter in an arbitrary range and returns a couple , where flag can be either commit or adopt and where is a previously proposed value. Moreover, if a process returns a commit flag, then every process must return the same value. Further, if no two processes propose different values, then all returned flags must be commit.
Liveness of the simulation relies on calls to simultaneous consensus objects [2]. To access a simultaneous consensus object, a process proposes a vector of inputs, one for each of the consensus instances, , and the object returns a couple , where index belongs to and is a value proposed by some process at index . It ensures that no two processes obtain different values with the same index. Moreover, if distinct input vectors are proposed then only values at indices can be output. The simultaneous consensus object is equivalent to setconsensus in a readwrite sharedmemory system [2].
Our simulation is described in Algorithm 1. We use three shared abstractions: an infinite array of simultaneous consensus objects , an infinite array of arrays of indexed commitadopt objects , and a singlewriter multireader memory with slots.
In every round, processes use the corresponding simultaneous consensus object first (line 1) and then go through the set of commitadopt objects (lines 1–1), starting with the index output by the simultaneous consensus object (line 1). It is guaranteed that at least one process commits, in particular, process that is the first to return from its first commitadopt invocation in this round (on a commitobject ), because any other process with a different proposal must access a different commitadopt object first and, thus, must invoke after returns. To ensure that a unique written value is selected, processes replace their current proposal values with the value adopted by the commitadopt objects (lines 1–1). Note that the processes do not select values corresponding to an older round of simulation, to ensure that processes do not alternate committing and adopting the same value indefinitely.
In the simulation, the simulating processes propose snapshot results for the simulated processes. Once a proposed snapshot has been committed, a process stores in the shared memory the value that the simulated process must write in its next step (based on its simulated algorithm), equipped with the corresponding write counter (line 1). The write counter is then incremented and a new snapshot proposal is computed (line 1). To compute a simulated snapshot, for each process, we select the most recent value available in the memory by comparing the write counters (auxiliary function CurWrites at lines 1–1).
Lemma 1
Algorithm 1 provides a nonblocking simulation of a process readwrite sharedmemory system in the set consensus model. Moreover, if there are active processes, then one of the first simulated processes is guaranteed to make progress.
The proof of Lemma 1 can be found in Appendix B. The proof is constructed by showing that: (1) No two different written values are computed for the same simulated process and the same write counter; (2) At every round of the simulation, at least one simulator commits a new simulated operation; (3) Every committed simulated snapshot operation can be linearized at the moment when the actual snapshot operation which served for its computation took place; and (4) Every simulated write operation can be linearized to the linearization time of the first actual write performed by a simulator with the corresponding value.
Using the extended BGsimulation to simulate a concurrent execution. We have shown that a process readwrite shared memory system can be simulated in the setconsensus model. Now we show that this simulated system can be used to simulate concurrency. The idea is to make the obtained process system run a BGsimulation protocol [3, 6], so that at most simulated processes are active at a time.
The BGsimulation technique allows processes , called BGsimulators, to waitfree simulate a resilient execution of any protocol on processes (). The simulation guarantees that each simulated step of every process is either agreed upon by all simulators, or one less simulator participates further in the simulation for each step which is not agreed on (in this, we say that the step simulation is blocked because of the faulty or slow simulator).
The technique was later turned into extended BGsimulation [11]. The core of this technique is the Extended Agreement (EA) algorithm, which ensures safety of consensus but not necessarily liveness: it may block if some process has slowed down in the middle of its execution. Additionally, the EA protocol exports an abort operation that, when applied to a blocked EA instance, reinitializes it so that it can move forward until an output is computed or another process makes it block again.
Our simulation is quite simple. Before running the process simulation using Algorithm 1, processes write their input states in the memory. The process simulation is used to run an extended BGsimulation that executes the code of the task solution for the simulated initial processes. Once a task output for a simulated process is available in the shared memory, the process stops participating in the process simulation. A process that completed its initial write but has not yet been provided with a task output is called active, i.e., this process is both available to be simulated by the BGsimulators and is participating in the simulation of the BGsimulators.
In our case, we use the extended BGsimulation in a slightly different manner than in the original paper [11]. Instead of running processes in lockstep as much as possible, by selecting the least advanced available process (breadthfirst selection), the BGsimulators run the processes with as low concurrency as possible by selecting the most advanced available process (depthfirst selection). To prevent simulators from getting blocked on all active processes, a BGsimulator stops participating if the number of active processes is strictly lower than its identifier (the index of the simulated process the BGsimulator is executed on, from to ). If a BGsimulator is blocked on all active simulated processes, but has an identifier lower or equal to their number, it uses the abort mechanism to exclude BGsimulators with large identifiers that should be stopped.
Lemma 2
All tasks solvable in the concurrency model can be solved in the setconsensus model.
Proof. The BGsimulators select the most advanced available (not blocked by
a BGsimulator) process to execute, thus, a
process never simulated yet is selected if and only if all currently
started simulations of active processes are blocked. But
at most simulated codes can be blocked by BGsimulators
(), thus,
at most active processes can be concurrently
simulated and at least of them is not blocked.
Moreover, when there are active processes,
then progress is guaranteed to one of the first BGsimulators,
see Lemma 1. The remaining BGsimulators stop
participating in the simulation and cannot block the
first ones, as they are eventually excluded using the abort
mechanism. The abort mechanism is used only finitely many
times, only once a BGsimulator witnesses that the number of
active processes has decreased (and there are finitely many
processes). Therefore, as long as there are active correct
processes, the BGsimulation makes progress and
eventually every correct process obtains an output in the task solution.
4.2 From concurrency to .
We now show that concurrency can solve , i.e., it can solve the chromatic simplex agreement task on the subcomplex .
Lemma 3
A concurrent execution of two rounds of any immediate snapshot algorithm solves the simplex agreement task on .
Proof. Let us consider a set of outputs provided by a concurrent
execution of any IS algorithm (e.g., [4]):
the set of outputs forms a valid simplex in
[5], as the set of concurrent runs is a subset of the
waitfree runs. Let us consider a contention set containing
two processes and , and let us assume that and were
never executed concurrently during their executions of the two rounds
of immediate snapshots. Without loss of generality, we can consider
that ’s computation was terminated before the activation of , so
cannot be aware of ’s input as it did not perform any operation
before finishes the two rounds of immediate snapshots. Thus,
cannot see , which contradicts the contention set
definition. Therefore all processes in a contention set were
active at the same time during the execution, hence a
concurrent execution implies that contention sets cannot contain more than processes.
It is easy to complete this result by showing that the set consensus model is, regarding task solvability, at least as strong as the model:
Theorem 4
Any task solvable by can be solved in the set consensus model.
Proof. As shown in Lemma 3, the simplex agreement
task on is solvable in the concurrency model. Moreover,
according to
Lemma 2, any task solvable in the concurrency
model can be solved in the set consensus model, and hence in particular, the
simplex agreement task on . Therefore, by iterating a solution to
the simplex agreement task on , a run of can be simulated
in the set consensus model and
used to solve any task solvable in .
4.3 From to set consensus
Now we show how to simulate in any algorithm that uses readwrite memory and setconsensus objects.
set consensus simulation design. Making a nonblocking simulation of readwrite memory can be trivially done in , since the set of runs is a subset of runs, and there exists several algorithms simulating readwrite memory in , e.g., [17].
Solving set agreement is also not very complicated: every iteration of provides a set of at most leaders, i.e., processes with an output containing at most elements, where at least one such leader is visible to every process, i.e., it can be identified as a leader and its input is visible to all. The set of leaders of are shown in figure 4 in red, it is easy to observe that every simplex in has at most two leaders, and that one is visible to every process (every process with a carrier of size at most 2 is a leader). This property gives a very simple set agreement algorithm: every process decides on the value proposed by one of these leaders. We will later show how this property can be derived from the restriction of on the size of contention sets.
The difficulty of the simulation consists mostly in combining the sharedmemory and set agreement simulation, as some processes may be accessing distinct agreement objects while other processes are performing readwrite operations. Indeed, liveness of our setagreement algorithm relies on the participation of visible leaders, i.e., on the fact that the leaders propose values for this instance of set agreement. In this sense, our set agreement algorithm may block if some process is performing a readwrite operation or is involved in a different instance of set agreement. Likewise, the readwrite memory simulation is only nonblocking, so it can be indefinitely blocked by a process waiting to complete an agreement operation.
The solution we propose consists in (1) synchronizing the two simulations, in order to ensure that, eventually, at least one process will complete its pending operation, and (2) ensuring that the processes collaborate by participating in every simulated operation. In our solution, every process tries to propagate every observed proposed value (for a write operation), and every process tries to reach an agreement in every setagreement object accessed by some process. For that, we make the processes participate in both simulation protocols (readwrite and set agreement) in every round, until they decide.
Even though the simulated algorithm executes only one operation at a time and requires the output of the previous operation to compute the input for the following one, we enrich the simulated process with dummy operations that do not alter the simulation result. Then eventually some undecided process is guaranteed to complete both pending operations, where at most one of them is a dummy one. This scheme provides a nonblocking simulation of any algorithm using readwrite shared memory and set agreement objects.
The shared memory simulation from [17] provides progress to the processes with the smallest snapshot output, while our set agreement algorithm provides progress to the leader with the smallest output, i.e., the smallest output. We leverage these properties by running the readwrite simulation only on the outputs of (i.e., in every second round of immediate snapshots). In the dimensional case, the set of processes with the smallest outputs are presented as red simplicies in Figure 4 for . This way we guarantee that at least the leader with the smallest output will make progress in both simulations. Indeed, the definition of implies that the set of processes with the smallest outputs includes a leader. Figure 4 gives an example of an intersection between the set of processes with the smallest output and the set of leaders: here every process with the smallest output has a carrier of size at most and every such process is a leader.
set consensus simulation algorithm. Algorithm 2 provides a simulation of any algorithm using readwrite shared memory (w.l.o.g., atomic snapshots) and setagreement objects. The algorithm is based on the shared memory simulation from [17], applied on outputs of every iteration of , combined with a parallel execution of instances of our set agreement algorithm. The simulation works in rounds that can be decomposed into three stages: communicating through , updating local information, and validating progress.
The first stage consists in accessing the new iteration associated with the round, using information on the ongoing operations as an input (see line 2). For memory operations, two objects are contained in ’s input, an array containing the most recent known write operations for every process, , and a timestamp associated with each process write value, . A single object is used for the agreement operations, , a list of all adopted proposals for all accessed agreement objects. Finally, a value State, set to decided or undecided, is put in ’s input, to indicate whether the process has completed its simulation.
The second stage consists in updating the local information according to the output obtained from (lines 2–2). The input value of each process observed in the second immediate snapshot of is extracted (line 2). These selected inputs are examined in order to replace the local write values with the most recent ones, i.e., associated with the largest write counters (lines 2–2).The variable of every leader, i.e., a process with an output containing at most undecided process inputs (using the variable State), is scanned in order to adopt all its decision estimates (lines 2–2). Moreover, boolean value is used to check if every observed leader transmitted a decision estimate for the pending agreement operation, .
The third stage consists in checking whether pending operations can safely be terminated (lines 2–2), and if so, whether the process has completed its simulation (line 2) or if new operations can be initiated (line 2–2).
Informally, it is safe for a process to decide in line 2, as there are at most Leaders per round, one of which is (1) visible to every process and (2) provides a decision estimate for the pending agreement. Thus every process adopts the decision estimate from a leader of the round, reducing the set of possible distinct decisions to .
A pending memory operation terminates when the round number equals the sum of the currently observed write counters (test at line 2), as in the original algorithm [17]. Indeed, the equality implies that the writes in the estimated snapshot have been observed by every process (line 2). Last, if a process did not terminate, it increments its write counter and, if there is a new operation available, the process selects the operation (see lines 2–2).
If there is a new agreement operation, then the input proposal and the object identifier are selected (line 2) and they are used for the current decision estimate in (line 2), unless a value has already been adopted (line 2). If there is a new write operation then the current write value is simply changed (line 2), a dummy write thus consists in rewriting the same value. ^{4}^{4}4Note that our agreement algorithm is far from efficient for multiple reasons. Progress could be validated at every round and not only when a write is validated. Moreover, processes could also preventively decide the output for objects not yet accessed. Lastly, processes could also adopt proposals from nonleaders when no visible leader has a proposition.
Lemma 5
In , Algorithm 2 provides a nonblocking simulation of any shared memory algorithm with access to setagreement objects.
The proof of Lemma 5 is delegated to Appendix B. The main aspects of the proof are taken from the base algorithm from [17], while the liveness of the agreement objects simulation relies on the restriction provided by and the maximal size of contention sets.
Lemma 5 implies the following result:
Theorem 6
Any task solvable in the setconsensus model can be solved in
Proof. To solve in a task solvable in the setconsensus model, we can simply use Algorithm 2, simulating any given algorithm solving the task in the setconsensus model.
The nonblocking simulation provided by Algorithm 2
ensures, at each point, that at least one live process eventually terminates.
As there are only finitely many processes, every live process eventually terminates.
Lemma 2, Theorem 4, and
Theorem 6 imply the following equivalence result:
Corollary 7
The concurrency model, the setconsensus model, and are equivalent regarding task solvability.
5 Concluding remarks: on minimality of for set consensus
This paper shows that the models of set consensus and concurrency are captured by the same affine task , defined as a subcomplex of . One may wonder if there exists a simpler equivalent affine task, defined as a subcomplex of , the degree of the standard chromatic subdivision. To see that this is in general not possible, consider the case of (consensus) in a process system. We can immediately see that the corresponding subcomplex of must contain all “ordered” simplexes depicted in Figure 5. Indeed, we must account for a waitfree concurrent run in which, say, runs first until it completes (and it must outputs its corner vertex in ), then runs alone until it outputs its vertex in the interior of the face and, finally, must output its interior vertex.
The derived complex is connected. Moreover, any number of its iterations still results in a connected complex. The simple connectivity argument implies that consensus cannot be solved in this iterated model and, thus, the complex cannot capture concurrency.
Interestingly, the complex in Figure 5 precisely captures the model in which, instead of consensus, weaker testandset (TS) objects are used: (1) using TS, one easily make sure that at most one process terminates at an IS level, and (2) in runs defined by this subcomplex, any pair of processes can solve consensus using this complex and, thus, a TS object can be implemented. It is not difficult to generalize this observation to TS objects [26]: the corresponding complex consists of all simplices of , contention sets of which are of size at most . The equivalence (requiring a simple generalization for the backward direction) can be found in [26, 19].
Overall, this raises an intriguing question whether every object, when used in the readwrite system, can be captured via a subcomplex of for some .
References
 [1] Yehuda Afek, Hagit Attiya, Danny Dolev, Eli Gafni, Michael Merritt, and Nir Shavit. Atomic snapshots of shared memory. Journal of the ACM, 40(4):873–890, 1993.
 [2] Yehuda Afek, Eli Gafni, Sergio Rajsbaum, Michel Raynal, and Corentin Travers. The ksimultaneous consensus problem. Distributed Computing, 22(3):185–195, 2010.
 [3] Elizabeth Borowsky and Eli Gafni. Generalized FLP impossibility result for resilient asynchronous computations. In STOC, pages 91–100. ACM Press, May 1993.
 [4] Elizabeth Borowsky and Eli Gafni. Immediate atomic snapshots and fast renaming. In PODC, pages 41–51, New York, NY, USA, 1993. ACM Press.
 [5] Elizabeth Borowsky and Eli Gafni. A simple algorithmically reasoned characterization of waitfree computation (extended abstract). In PODC ’97: Proceedings of the sixteenth annual ACM symposium on Principles of distributed computing, pages 189–198, New York, NY, USA, 1997. ACM Press.
 [6] Elizabeth Borowsky, Eli Gafni, Nancy A. Lynch, and Sergio Rajsbaum. The BG distributed simulation algorithm. Distributed Computing, 14(3):127–146, 2001.
 [7] Zohir Bouzid, Eli Gafni, and Petr Kuznetsov. Strong equivalence relations for iterated models. In OPODIS, pages 139–154, 2014.
 [8] Carole DelporteGallet, Hugues Fauconnier, Eli Gafni, and Petr Kuznetsov. Waitfreedom with advice. Distributed Computing, 28(1):3–19, 2015.
 [9] Eli Gafni. On the waitfree power of iteratedimmediatesnapshots. Unpublished manuscript, http://www.cs.ucla.edu/~eli/eli/wfiis.ps, 1998.
 [10] Eli Gafni. Roundbyround fault detectors (extended abstract): Unifying synchrony and asynchrony. In Proceedings of the 17th Symposium on Principles of Distributed Computing, 1998.
 [11] Eli Gafni. The extended BGsimulation and the characterization of tresiliency. In STOC, pages 85–92, 2009.
 [12] Eli Gafni and Rachid Guerraoui. Simulating few by many: Limited concurrency = set consensus. Technical report, 2009. http://web.cs.ucla.edu/~eli/eli/kconc.pdf.
 [13] Eli Gafni and Rachid Guerraoui. Generalized universality. In Proceedings of the 22nd international conference on Concurrency theory, CONCUR’11, pages 17–27, Berlin, Heidelberg, 2011. SpringerVerlag.
 [14] Eli Gafni and Petr Kuznetsov. Relating LResilience and WaitFreedom via Hitting Sets. In ICDCN, pages 191–202, 2011.
 [15] Eli Gafni, Petr Kuznetsov, and Ciprian Manolescu. A generalized asynchronous computability theorem. In ACM Symposium on Principles of Distributed Computing, PODC ’14, Paris, France, July 1518, 2014, pages 222–231, 2014.
 [16] Eli Gafni, Petr Kuznetsov, and Ciprian Manolescu. A generalized asynchronous computability theorem. In PODC, 2014.
 [17] Eli Gafni and Sergio Rajsbaum. Distributed programming with tasks. In Principles of Distributed Systems  14th International Conference, OPODIS 2010, Tozeur, Tunisia, December 1417, 2010. Proceedings, pages 205–218, 2010.
 [18] Eli Gafni, Sergio Rajsbaum, and Maurice Herlihy. Subconsensus tasks: Renaming is weaker than set agreement. In International Symposium on Distributed Computing, pages 329–338, 2006.
 [19] Eli Gafni, Michel Raynal, and Corentin Travers. Test & set, adaptive renaming and set agreement: a guided visit to asynchronous computability. In SRDS, pages 93–102, 2007.
 [20] Maurice Herlihy. Waitfree synchronization. ACM Transactions on Programming Languages and Systems, 13(1):123–149, January 1991.
 [21] Maurice Herlihy, Dmitry N. Kozlov, and Sergio Rajsbaum. Distributed Computing Through Combinatorial Topology. Morgan Kaufmann, 2014.
 [22] Maurice Herlihy and Sergio Rajsbaum. The topology of sharedmemory adversaries. In PODC, pages 105–113, 2010.
 [23] Maurice Herlihy and Nir Shavit. The topological structure of asynchronous computability. Journal of the ACM, 46(2):858–923, 1999.
 [24] Dmitry N. Kozlov. Chromatic subdivision of a simplicial complex. Homology, Homotopy and Applications, 14(1):1–13, 2012.
 [25] Nati Linial. Doing the IIS. Unpublished manuscript, 2010.
 [26] Achour Mostéfaoui, Michel Raynal, and Corentin Travers. Exploring gafni’s reduction land: From Omega to waitfree adaptive (2p[p/k])renaming via kset agreement. In DISC, pages 1–15, 2006.
 [27] Michel Raynal and Julien Stainer. Increasing the power of the iterated immediate snapshot model with failure detectors. In SIROCCO, pages 231–242, 2012.
 [28] Michel Raynal, Julien Stainer, and Gadi Taubenfeld. Distributed universality. In International Conference on Principles of Distributed Systems, pages 469–484. Springer, 2014.
 [29] Michael Saks and Fotios Zaharoglou. Waitfree kset agreement is impossible: The topology of public knowledge. SIAM J. on Computing, 29:1449–1483, 2000.
 [30] Vikram Saraph, Maurice Herlihy, and Eli Gafni. Asynchronous computability theorems for tresilient systems. In DISC, 2016.
 [31] Edwin H. Spanier. Algebraic topology. McGrawHill Book Co., New York, 1966.
Appendix A Simplicial complexes
We review now several notions from topology. For more detailed coverage of the topic please refer to [31, 21].
A simplicial complex is a set , together with a collection of finite nonempty subsets of such that:

For any , the oneelement set is in ;

If and , then .
The elements of are called vertices, and the elements of are called simplices. We usually drop from the notation, and refer to the simplicial complex as .
A subset of a simplex is called a face of that simplex.
A subcomplex of is a subset of that is also a simplicial complex.
The dimension of a simplex is its cardinality minus one. The skeleton of a complex , denoted , is the subcomplex formed of all simplices of of dimension or less.
A simplicial complex is called pure of dimension if has no simplices of dimension , and every dimensional simplex of (for ) is a face of an dimensional simplex of .
Let and be simplicial complexes. A map is called simplicial if it is induced by a map on vertices; that is, maps vertices to vertices, and for any , we have
A simplicial map is called noncollapsing (or dimensionpreserving) if for all .
Any simplicial complex has an associated geometric realization , defined as follows: Let be the set of vertices in . As a set, we let be the subset of consisting of all functions such that and . For each , we set Each is in onetoone correspondence with a subset of of the form We put a metric on by
A nonempty complex is called connected if, for each , any continuous map of the sphere into can be extended to a continuous map over the disk.
A subdivision of a simplicial complex is a simplicial complex such that:

The vertices of are points of .

For any , there exists such that .

The piecewise linear map mapping each vertex of to the corresponding point of is a homeomorphism.
Chromatic complexes. We now turn to the chromatic complexes used in distributed computing, and recall some notions from [23].
Fix . The standard simplex has vertices, in onetoone correspondence with colors . A face of is specified by a collection of vertices from . We view as a complex, with its simplices being all possible faces .
A chromatic complex is a simplicial complex together with a noncollapsing simplicial map . Note that can have dimension at most . We usually drop from the notation. We write for the union of over all vertices . Note that if is a subcomplex of a chromatic complex, it inherits a chromatic structure by restriction.
In particular, the standard simplex is a chromatic complex, with being the identity.
Every chromatic complex has a standard chromatic subdivision . Let us first define for the standard simplex . The vertices of are pairs , where and is a face of containing . We let . Further, is characterized by its simplices; these are the tuples such that:

For all and , one is a face of the other;

If , then .
The geometric realization of can be taken to be the set with the vertex corresponding to the point with coordinates and the other coordinates . Then, we can identify a vertex of with the point
where is the cardinality of . Thus, becomes a subdivision of and the geometric realizations are identical: .
Next, given a chromatic complex , we let be the subdivision of obtained by replacing each simplex in with its chromatic subdivision. Thus, the vertices of are pairs , where is a vertex of and is a simplex of containing . If we iterate this process times we obtain the chromatic subdivision, .
Let and be chromatic complexes. A simplicial map is called a chromatic map if for all vertices , we have . Note that a chromatic map is automatically noncollapsing. A chromatic map has chromatic subdivisions . Under the identifications of topological spaces the continuous maps and are identical.
Appendix B Omitted proofs
Lemma 1
Algorithm 1 provides a nonblocking simulation of a process readwrite sharedmemory system in the set consensus model. Moreover, if there are active processes, then one of the first simulated processes is guaranteed to make progress.
Proof. We derive correctness of the simulation in Algorithm 1 from the following three properties: (1) every simulated process follows a unique sequence of operations, (2) simulated snapshots and updates are linearizable, and (3) at least one simulated process, with an associated identifier lower or equal to the number of active processes, takes an infinite number of steps.
Let us first prove two useful simple claims:

The write counter of a simulated process never decreases: A write counter can only be modified by incrementing it in line 1 or by adopting it from the result of a commitadopt operation in lines 1 or 1. Moreover, the write counter and the associated value are only updated when the write counter obtained from a commitadopt object is not smaller than the current one.

If a process has a write counter equal to , then at least one write/snapshot operation has been validated, i.e., a simulator passed the test in line 1, for every write counter , : Let us prove this property by induction. Initially, all write counters are set to and, thus, the property is trivially verified. Assume that the property holds for value , and consider a state in which some process has a write counter equal to . Consider the first time a process updates its write counter to , it can only be the result of line 1, as adopting the write counter from another process would result in a contradiction (this process must have updated it to first).
Using these claims, let us show our three required properties:

For every couple , where is a simulated process and is a write counter, all validated writes are identical. According to the structure of Algorithm 1, an operation is validated if and only if it is returned from a call to a commitadopt object with a commit flag (line 1). Consider the smallest round in which some process obtains a commit flag with a write counter equal to from a commitadopt object associated to . According to the specification of commitadopt, every process obtains the same output value at round from this commitadopt object, , possibly with an adopt flag. According to Claim 2, if no process validated a write for , then no write counter can be greater than . Thus, every process replaces its current proposal value with the same couple .
By contradiction, assume that a process validates a different write value for . By Claim 1, this process must have modified its snapshot estimate without ever increasing its write counter. The first process that modified the estimate could only do it by adopting the proposition from another process, but no other process changed yet its proposal value, which results in a contradiction.

Simulated snapshots and updates are linearizable. A simulated snapshot is the result of applying the auxiliary function CurWrites (lines 1–1) on the snapshot result of . The auxiliary function simply selects, for each simulated process, the write value with the greater write counter. By the previous property, all validated writes updated to with the same counter are identical, and so, only the first completed write value may change the result of the simulated snapshot computation. Indeed, a validated write can only be overwritten by a more recent write value, i.e., a write value associated with a greater write counter, as the write counter strictly increases during a validation and can never decrease afterwards (Claim 1).
Therefore, for a given simulated process, the first write updating for a given write counter will be selected in any later snapshot until a write associated to a larger write counter is performed. Now we select the linearization point of a simulated write to be the linearization point of the first validated update (line 1) performed with it. A simulated snapshot is linearized to the linearization point of the corresponding validated snapshot operation on . The simulated snapshots and updates ordered by their linearization points constitute a legal sequential history. It is easy to see that a validated snapshot operation, the one which served for the simulated write computation, is linearized after the preceding write operations of the simulated process. Indeed, a simulated snapshot is computed only by the processes which validated the preceding write (line 1) and only after the update was made to (on line 1), thus, always after the first update was made for the associated write counter.
Finally, we prove liveness of the simulation:

A simulated process with an identifier smaller or equal to the number of active processes takes infinitely number of steps. This result directly follows from the properties of simultaneous consensus objects. With the number of active processes equal to , processes are provided with an output value where and every process with the same index obtains the same value. As processes first access the commitadopt object associated with the obtained index , some process must obtain a commit flag for its index. Indeed, the first process to obtain an output for its first commitadopt object in a round, may only have witness other processes with the same proposal. As a commitadopt object must return a commit flag when every proposed values are identical, this first process must obtain a commit flag associated to its index. Thus, this process validates the corresponding write value and increases its write counter.
By Claim 1, write counters can never decrease. Also, in every round, at least one simulator increases the write counter associated with a simulated process with an identifier smaller or equal to the number of active processes, . Therefore, after an infinite number of rounds, the write counters associated with such a simulated process have been incremented an infinite number of times. But there are only finitely many of them, one per process and simulated process. Thus, the write counter of one of them is incremented an infinite number of times. Using Claim 2, an infinitely incremented write counter implies a simulated process taking an infinite number of simulation steps.
Lemma 5
In , Algorithm 2 provides a nonblocking simulation of any shared memory algorithm with access to setagreement objects.
Proof. We prove correctness of Algorithm 2 in three steps: (1) The readwrite simulation is safe, i.e., the writesnapshot operations are atomic; (2) the setagreement algorithm is safe, i.e., processes decide on at most distinct proposed values for the same agreement object; and (3) the simulation is nonblocking, i.e., there is a nonterminated process which completes an infinite number of simulated operations.

The readwrite simulation is safe: The structure of the simulation is taken from an analogous simulation in [17], therefore, this part of the proof is also directly inspired from the one in [17].
In Algorithm 2, memory operations are reduced to a single write/snapshot operation. It is easy to see that any readwrite algorithm can be executed in this way by rewriting the same value again to discard a write or by ignoring all or part of the snapshot result to discard read operations. Nevertheless, even if a single write/snapshot operation is provided, it is not an immediate snapshot, i.e., the write and the snapshot operations cannot be linearized together by batches. We will show that the set of new written values returned in some simulated snapshot during round , , and the set of processes returning this snapshot, , can be linearized firstly according to the associated round number and secondly, for operations in the same round, by linearizing the write operations before the read operations.

Claim 2: The sum of the write counters of an undecided process is greater or equal to the round number. Let us show this claim with a trivial induction on the round number. The property is true for the first round, , as the write counter associated to the processes own is initially set to while the rest is set to . Assume the property is true at round . Then either the sum result is strictly greater than the round number and thus the property is true for round , as write counters can only increase (Claim 1), or otherwise the sum is equal to the round number. In the later case the equality test made on line 2 is verified and if the process is still undecided it does not pass the test on line 2 and thus it increments its own write counter on line 2 and the sum becomes, and stays (Claim 1), greater or equal to .

Claim 3: There is a unique write value associated to each process and write counter, except possibly during the execution of line 2 and lines 2–2. This is a simple observation that the adoption of a write value is always made with its associated write counter on a memory position associated to the corresponding process (see lines 2–2). Otherwise, a write value can only be modified on line 2 by selecting a new write value but this is done only once the associated write counter has been incremented on line 2, a write counter that cannot have been used before, as write counters only increase (Claim 1).

Claim 4: A unique snapshot result can be returned per round. According to the containment property of snapshots operations, the output results of a call to an iteration of can be fully ordered by inclusion, i.e., . As the greatest write counter observed in these sets are adopted (see lines 2–2), a process with a larger output obtains larger or equal write counters. Therefore the sum of the write counters of a process with a larger output is equal to the sum of the write counters of a process with a smaller output if and only if the write counters are equal for every corresponding process. But if processes obtain the same sum of write counters, the set of selected write values are identical (Claim 3). As in any round, a snapshot is returned (at line 2) only if the sum of write counters equals the round number (test on line 2), and so all returned snapshot are identical, if any.

Claim 5: A write value can only be replaced with a more recent value. This is a direct corollary of Claims 1 and 3. Indeed, a write value associated with a given process can only replaced by a write value associated to the same process but with a greater associated write counter. Yet, a more recent write value is always associated with a greater write counter than all previously used ones for the corresponding process.
We therefore are provided with a unique sequence of validated snapshots according to rounds, , …, , , …(Claim 4). We can thus define without ambiguity and , respectively the set of firstly observed write values and the set of processes which returned during round . Moreover, according to Claim 5, a write value can only be replaced by a more recent write value, thus a snapshot returned on a later round can only contain identical or more recent write values. It is obvious that write operations can be safely linearized between the last snapshot which observed an older write value and the first snapshot to return the write value or a more recent one (as processes alternate write and snapshot operations write operations can be linearized in any order in between two snapshots, i.e., there can be at most one write value per process between two consecutively linearized snapshots). Therefore the following is a valid linearization ordering (we leave out the trivial verification that the linearization order respects operations local ordering):

The setagreement is safe: The safety of an agreement operation relies on two properties, validity and agreement. We also show an intermediary result later reused for the liveness property, leader visibility:

Validity: Every decided value is the input proposal of some process: The estimated decision value in is always either initialized to the process own proposal (on line 2), or to a value previously adopted from a leader (on line 2). The estimated decisions values are then never dissociated from their corresponding setagreement object identifier, , in the local memory object . It can further only be replaced in with the current initialized decision estimate, with the same object identifier, from another process (on line 2). Thus deciding on the estimated decision value in (at line 2) always decides on some process input proposal.

leader visibility: For every round, there is an undecided process, with an output containing at most inputs from undecided processes, contained in each undecided process output: This property is directly derived from the definition of restricting the contention sets sizes. Indeed, consider the smallest output obtained by an undecided process from an iteration of , denoted . Such a smallest view exists according to the snapshots containment property. By the containment property also, if contains an output with at most elements from undecided processes, then every output contains it. Moreover, by the selfinclusion property, contains the output of an undecided process.
Now let us assume that contains only outputs from undecided processes containing strictly more than inputs from undecided processes, and let be one of such a set of undecided processes with inputs contained in an output. As is the smallest output of an undecided process, all processes in observed in their output every input from processes in . This implies that forms a contention set, which is a contradiction with the assumption that includes more than processes.

Agreement: At most distinct values can be decided: Consider the first round, , at which some process completes an agreement operation for an agreement object (on line 2). A deciding process must have observed only round leaders, i.e., processes with an output containing at most undecided processes inputs, with a decision estimate for the considered agreement object (). Thus according to the leader visibility property, there is a leader observed by every undecided process with a decision estimate for the considered agreement object. Therefore, during this round , every process adopts the decision estimate of a leader for the considered agreement object (at line 2). Thus every process has a decision estimate in its object from one of the at most round leaders. Moreover, even if processes start a call to this agreement object in a later round, they would discard their own input proposal value directly (see line 2), and therefore the set of decision estimates can only decrease in later rounds.
It is easy to see by combining the selfinclusion and containment properties that at most processes can obtain a snapshot output containing at most inputs. Thus there can be at most leaders in a round, therefore, the set of decided values being bounded by the number of decision estimates adopted at round , at most distinct values can be decided for a given agreement object.


The simulation is nonblocking: A nonblocking simulation means that if undecided processes complete an infinite number of steps, then there is an undecided process which completes an infinite number of simulation operations. Showing this property is equivalent to show that there is no reachable configuration where there are undecided processes never completing any simulation steps during infinitely many algorithm rounds (the algorithm does not include waiting statements or infinite loops).
Let us assume we are in such a state. We will first show that the write counter of an undecided process is increased infinitely many times. This simply results from the previously proven Claim 2 from the safety proof of the read write simulation, stating that the sum of write counters of an undecided process is always greater than the round number. Thus, as there is an undecided process completing an infinite number of simulation rounds, there is a write counter increased infinitely many often. This write counter can only be one of an undecided process as a write counter is never increased after termination (see lines 2 and 2). Thus there is a process passing the test on line 2 infinitely often.
If a process passes the test on line 2, then every undecided process with a smaller output, thus a smaller write counter sum, must pass it as well. Let us consider the undecided process, , which passes this test infinitely often with the smallest output obtained by an undecided process. This process must have a pending active agreement operation as otherwise it would complete its write operation, or terminate, or select a new operation. Without loss of generality, we can take to be indefinitely often a leader seen by every undecided process (see the leader visibility property). Therefore every process must eventually obtain a decision estimate for pending agreement object (at line 2), and thus eventually decides as it eventually only observe leaders with a decision estimate (). This results in a contradiction, thus the simulation is nonblocking.