Hundreds of impossibility results for distributed computing

Faith Fich, Eric Ruppert
<span title="2003-09-01">2003</span> <i title="Springer Nature"> <a target="_blank" rel="noopener" href="" style="color: black;">Distributed computing</a> </i> &nbsp;
We survey results from distributed computing that show tasks to be impossible, either outright or within given resource bounds, in various models. The parameters of the models considered include synchrony, fault-tolerance, di erent communication media, and randomization. The resource bounds refer to time, space and message complexity. These results are useful in understanding the inherent di culty of individual problems and in studying the power of di erent models of distributed computing.
more &raquo; ... is a strong emphasis in our presentation on explaining the wide variety of techniques that are used to obtain the results described. 14 Conclusions 48 References 48 Index 64 150]. Why are impossibility results important for distributed computing? They help us understand the nature of distributed computing: what makes certain problems hard, what makes a model powerful, and how di erent models compare. They tell us when to stop looking for better solutions or, at least, which approaches will not work. If we have a problem that we need to solve, despite an impossibility result, the impossibility proof may indicate ways to adjust the problem speci cation or the modelling of the environment to allow reasonable solutions. Impossibility results have also in uenced real systems, for example, the design of network le systems 84], the architecture of fault tolerant systems for safety-critical applications 275], the design of programming languages 59], the speci cations of group membership services 97], and the de nition and study of failure detectors and systems based on them 88]. Finally, trying to prove impossibility results can suggest new and di erent algorithms, especially when attempts to prove impossibility fail. As John Cage wrote, \If someone says'can't', that shows you what to do" 82]. We begin in Sections 2 and 3 with brief descriptions of the models, terminology, and problems that are discussed throughout the paper. Section 4 discusses how to approach impossibility results and gives an overview of the major proof techniques for impossibility results in distributed computing. The rest of the paper presents a wide variety of results. Section 5 describes unsolvability results for the consensus problem and some similar process-coordination tasks. The use of impossibility results to study relationships between di erent models is addressed in Section 6. A systematic approach to studying computability for distributed systems is to characterize the models that can solve a particular problem. Alternatively, one can characterize the set of problems solvable in a given model. Results of both these types are described in Section 7. Further characterizations of problems solvable in speci c models appear in Section 8, which discusses applications of topology to proving impossibility results in distributed computing. Section 9 examines the question of whether weak shared object types can become more powerful when they are used in combination with other weak types. The next three sections consider complexity results. Each focuses on a di erent complexity measure: space, time, and the number of messages. Section 13 discusses impossibility results for randomized algorithms. An index of problems and proof techniques appears at the end of the paper. This survey builds on Lynch's excellent survey paper, \A Hundred Impossibility Proofs for Distributed Computing" 233], which covers results up to 1989. A shorter, preliminary version of our survey, emphasizing results from 1990 onwards, appeared in 137]. Models There are a number of very good descriptions of distributed models of computation, including motivation and formal de nitions 47, 224, 234]. Here, we shall only brie y mention some aspects of these models which are necessary for the results we present. A distributed system consists of a collection of n processes that run concurrently. Each process executes a sequential algorithm and can communicate with other processes. There are di erent ways processes can communicate. In message-passing models, processes send messages to one another via communication channels. This is modelled by a graph, with processes represented by nodes, bidirectional channels represented by undirected edges, and unidirectional channels represented by directed edges. A correct channel behaves as a (FIFO) queue, with the sender enqueuing its messages and the receiver dequeueing them. If the queue is empty, the receiver gets a special empty queue message. If message delivery is not instantaneous, the messages in the queue will not be immediately available to the receiver. In shared-memory models, processes communicate by performing operations on shared data structures, called objects, of various types. The typewriter font is used to denote object types. Each type describes the set of possible states of an object of that type, the set of operations that can be performed on the object, and the responses the object can return. At any time, an object has a state and, when a process performs an operation on the object, the object can change into a new state and return a response to the process. For example, a stack object stores a sequence of values in its state and supports the operations push and pop. A basic type of object is the register, which stores a value that can be read or written by all processes. A single-writer register is a restricted type of register to which only a single, xed process can write.
<span class="external-identifiers"> <a target="_blank" rel="external noopener noreferrer" href="">doi:10.1007/s00446-003-0091-y</a> <a target="_blank" rel="external noopener" href="">fatcat:4m7ylsvxxfdpjdpc26bfdcncaa</a> </span>
<a target="_blank" rel="noopener" href="" title="fulltext PDF download" data-goatcounter-click="serp-fulltext" data-goatcounter-title="serp-fulltext"> <button class="ui simple right pointing dropdown compact black labeled icon button serp-button"> <i class="icon ia-icon"></i> Web Archive [PDF] <div class="menu fulltext-thumbnail"> <img src="" alt="fulltext thumbnail" loading="lazy"> </div> </button> </a> <a target="_blank" rel="external noopener noreferrer" href=""> <button class="ui left aligned compact blue labeled icon button serp-button"> <i class="external alternate icon"></i> </button> </a>