DOLEV, D., DWORK, C., AND STOCKMEYER, L. 1987. On the minimal synchrony needed for distributed consensus. J. ACM 34, 1 (Jan.), 77--97.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....two processes. Fkch of the processes Pi, i 0, 1) has a register which it can write and the other can read. Here and elsewhere, we let denote the index of the other process, i.e. 1 i. Due to the asynchrony in the system it is impossible to have processes agree on one of the input values (see [17, 21, 33]) Thus, our algorithm has them .gradually converge from the input values x0 and xl to values that are only e apart. A process pi repeatedt y does the following: It writes its value vi (initially the input value xl) into its register, and then reads p s register. If Pi reads .l. from vr, it must ....

D. Dolev, C. Dwork and L. Stockmeyer, "On the Minimal Synchrony Needed for Distributed Consensus," Journal of the ACM, Vol. 34, No. I (January 1987), pp. 77-97.

....the performance of the algorithm if there is a crash: the crash detection time will be long, and the algorithm will be blocked in the meantime. Two other system models have been defined, which are between the asynchronous and the synchronous system models: the partially synchronous system model [ 11,14] and the asynchronous model augmented with failure detectors (which we will simply refer to as the failure detector model) 5] Consensus is solvable in these two system models. The partially synchronous model assumes that bounds exist, but they are not known and hold only eventually. The ....

D.Dolev, C. Dwork, and L. Stockmeyer. On the minimal synchrony needed for distributed consensus. Journal of ACM, 34(1):77--97, January 1987.

....of fault tolerant distributed systems. Consensus, atomic broadcast, and group membership are examples of agreement problems. One of the key issues when solving an agreement problem is the choice of the system model. Many system models have been proposed in the past years: synchronous models [11, 15, 16, 6], partially synchronous models [12] asynchronous models with failure detectors [9, 8, 2, 3] timed asynchronous models [10] etc. Despite the diversity of these models, almost all algorithms that have been proposed to solve agreement problems have the common point of being Crash Detection Based ....

D. Dolev, C. Dwork, and L. Stockmeyer. On the minimal synchrony needed for distributed consensus. Journal of ACM, 34(1):77--97, January 1987.

....data types, including stacks, priority queues, fetch add registers [16] and others. This argument also yields lower bounds for decision problems that solve strong renaming, including assignment [4] and order preserving renaming [2] Elsewhere [14] a similar kind of reduction (to consensus [6, 10]) was used to derive impossibility results for wait free concurrent objects in the asynchronous shared memory model. Our results here show that reduction to a decision problem can be adapted to yield complexity as well as impossibility results. How tight are these lower bounds for concurrent ....

D. Dolev, C. Dwork, and L. Stockmeyer. On the minimal synchrony needed for distributed consensus. Journal of the ACM, 34(1):77--97, January 1987.

....rise to the problem, that in an asynchronous system a very slow process and a crashed process cannot be distinguished [54] This creates a problem in implementing fault tolerant systems as the failure detectors cannot be accurate. Atomic broadcast (which is same as total ordering) and Consensus [64], which are very important abstractions in building distributed systems, cannot be solved in such an asynchronous distributed system [54] Atomic broadcast is equivalent to Consensus in an asynchronous system (irrespective of the existence of failure detectors) If we have an algorithm for atomic ....

....not only the state transitions and outputs that must occur in response to operation invocation but also a real time interval within which such state transitions and outputs must be observed. This allows clients of a services to associate timeout delays with each of the provided operation. [64, 65] study partially synchronous systems. The fundamental problem in implementing distributed systems is occurrence of partial failures and the inability to detect accurately the state of a system. Distributed systems need failure detectors (or a health checker) in some form for implementation. In ....

D. Dolev, C. Dwork, and L. Stockmeyer, "On the minimal synchrony needed for distributed consensus," Journal of the ACM, vol. 34, pp. 77--97, January 1987.

....objects and multiprocessor synchronization primitives based on the values of n for which they solve n process consensus in a wait free manner. For example, it is impossible to solve n process consensus using read write registers for n 1 or using read write registers and swap registers, for n 2 [2, 15, 16, 20, 26]. It has been shown that this separation does not hold in a randomized setting; that is, even read write registers suffice to solve n process consensus [2, 15] This is a rather fortunate outcome, since it opens the possibility of using randomization to implement concurrent objects without ....

D. Dolev, C. Dwork and L. Stockmeyer, "On the Minimal Synchrony Needed for Distributed Consensus," Journal of the ACM, vol. 34, no. 1, January 1987, pp. 77-- 97.

.... Lynch and Paterson result proving that consensus is not solvable in an asynchronous system 1 if a single process may crash (the so called FLP impossibility result) 9] Apart from this result, many solutions to the consensus problem have been described in other system models (synchronous [6], partially synchronous [7] asynchronous Copyright 1997 IEEE. Published in the Proceedings of FTDCS 97, October 29 31, 1997. Personal use of this material is permitted. However, permission to reprint republish this material for advertising or promotional purposes or for creating new ....

....mechanism can easily be implemented based on a (purely local) logical time: the logical time of process p i can be defined as the number of instructions that p i has executed. In other words, adding time outs to the asynchronous system model is not enough to overcome the FLP impossibility result [6]. The heart of the FLP result is the impossibility to distinguish crashed processes from those that are slow or connected via slow links. Understanding that time outs are not enough to overcome the FLP impossibility result, does not lead implementors to care about it. The usual argument is the ....

D.Dolev, C. Dwork, and L. Stockmeyer. On the minimal synchrony needed for distributed consensus. Journal of ACM, 34(1):77--97, January 1987.

....of the processes p i ; i 2 f0; 1g has a register which it can write and the other can read. Here and elsewhere, we let denote the index of the other process, i.e. 1 Gamma i. Due to the asynchrony in the system, it is impossible to have processes agree on one of the input values (see [18, 22, 34]) Thus, our algorithm has them gradually converge from the input values x 0 and x 1 to values that are only apart. A process p i repeatedly does the following: it writes its value v i (initially the input value x i ) into its register, and then reads p s register. If p i reads from v ....

D. Dolev, C. Dwork and L. Stockmeyer, "On the Minimal Synchrony Needed for Distributed Consensus," Journal of the ACM, Vol. 34, No. 1 (January 1987), pp. 77--97.

.... Lynch and Paterson result proving that consensus is not solvable in an asynchronous system 1 if a single process may crash (the so called FLP impossibility result) 9] Apart from this result, many solutions to the consensus problem have been described in other system models (synchronous [6], partially synchronous [7] asynchronous with failure detectors [3] etc) While the consensus problem has attracted much attention in the theoretical distributed systems community, it has been largely ignored by systems implementors. Implementors usually consider the consensus problem to be ....

....mechanism can easily be implemented based on a (purely local) logical time: the logical time of process p i can be defined as the number of instructions that p i has executed. In other words, adding time outs to the asynchronous system model is not enough to overcome the FLP impossibility result [6]. The heart of the FLP result is the impossibility to distinguish crashed processes from those that are slow or connected via slow links. Understanding that time outs are not enough to overcome the FLP impossibility result, does not lead implementors to care about it. The usual argument is the ....

D.Dolev, C. Dwork, and L. Stockmeyer. On the minimal synchrony needed for distributed consensus. Journal of ACM, 34(1):77--97, January 1987.

....approaches used by virtual synchrony and extended virtual synchrony to achieve an approximation to the property that a message is not delivered unless it is delivered by all members of the configuration. Perfection is not possible as it would require distributed consensus or common knowledge [8, 9, 10]. The virtual synchrony approach achieves this approximation in uniform multicast by extending the history using the EXTEND mechanism, which assumes that the last few events in a failed process are lost forever and, thus, delivery of a uniform multicast message can be imputed to a failed process. ....

D. Dolev, C. Dwork and L. Stockmeyer, "On the minimal synchrony needed for distributed consensus," Journal of the ACM 34, 1 (January 1987), pp. 77--97.

....and provides all the services over a single broadcast domain. However, it differs from the upper level membership and message ordering services they provide. The problem of maintaining processor set membership in the face of processor faults and joins is described in [10] As noted by others ([12, 11, 16]) solving the membership problem (or the equivalent problem of total ordering of messages) in an asynchronous environment with faults is impossible. Transis contains a new membership algorithm that handles any form of detachment and re connection of processors, based on causally ordered messages. ....

....dynamically go up and down, and the CCS reflects these changes through a series of configuration changes. The membership problem is to maintain the CCS in agreement by all its members throughout these changes. This problem is provably impossible to solve in asynchronous environments with faults([12, 11]) Our membership algorithm circumvents these results by allowing the extraction of live (but not active) processors unjustfully. Consequently, the membership algorithm never allows blocking, and operates within the regular flow of messages. The sections bellow give the essentials of the algorithm ....

[Article contains additional citation context not shown here]

D. Dolev, C. Dwork, and L. Stockmeyer. On the minimal synchrony needed for distributed consensus. J. ACM, 34(1):77--97, Jan. 1987.

....a consensus at one level or another. Fischer Lynch and Paterson ( 14] were the first to point out that there is no way to reach consensus in an asynchronous distributed system, when faults may occur. Moreover the asynchrony that produces the difficulty can be very limited, as can be seen in [11]. The basic idea behind all these impossibility results is that there is no way to distinguish between a very slow machine and a failed one. Since any nontrivial coordination problems should be determined on the fly according to the initial inputs to the individual machines, there should always ....

D. Dolev, C. Dwork, and L. Stockmeyer. On the minimal synchrony needed for distributed consensus. J. ACM, 34(1):77--97, Jan. 1987.

....by which processors, which processors are currently connected, and what is the global message order. A good membership algorithm provides this knowledge, even in the presence of processor crashes, processors recovery, network partitions and merges, and booting of new processors. It is a known fact [13, 8] that the membership problem in a dynamic asynchronous environment, when faults may exist, is unsolvable. The problem is the inability to distinguish between a slow machine and one that has crashed. A number of approaches to bypassing this obstruction exist [1] In practical asynchronous systems ....

D. Dolev, C. Dwork, and L. Stockmeyer. On the minimal synchrony needed for distributed consensus. J. ACM, 34(1):77--97, Jan. 1987.

....that the complete merging of the partitioned histories is application dependent and therefore is not handled by the membership protocol. The final section of the paper presents applications that can benefit from the support of continuous operation despite partitions. As noted by others ([8, 7, 11]) solving the membership problem in an asynchronous environment when faults may be present is impossible. There are various approaches for circumventing this difficulty ( 6, 15, 5, 13, 12] Our approach never allows indefinite blocking but rarely extracts from the membership live (but inactive) ....

D. Dolev, C. Dwork, and L. Stockmeyer. On the minimal synchrony needed for distributed consensus. J. ACM, 34(1):77--97, Jan. 1987.

....The CCS undergoes changes during operation: processors dynamically go up and down, and the CCS reflects these changes through a series of configuration changes. The problem of maintaining processor set membership in the face of processor faults and joins is described in [9] As noted by others ([12, 11, 14]) solving the membership problem in an asynchronous environ ment when faults may be present is impossible. Transis contains a new membership protocol that handles any form of detachment and re connection of processors, based on causally ordered messages. This extends the membership protocol of ....

....broadcast. Our preliminary implementation over a heterogeneous network of Sun 4 and Sun 3 machines shows promising results. Over more than three machines, performance is already better than standard point to point protocols. Fischer, Lynch and Paterson ( 12] and later Dolev, Dwork and Stockmeyer, [11]) have shown that without some sort of synchronization no agreement is possible. Our membership algorithm circumvents these results by introducing a dynamic local group upon which agreement is based. It is true that in some extreme cases, processors may wrongly decide that another processor has ....

D. Dolev, C. Dwork, and L. Stockmeyer. On the minimal synchrony needed for distributed consensus. J. ACM, 34(1):77--97, Jan. 1987.

No context found.

DOLEV, D., DWORK, C., AND STOCKMEYER, L. 1987. On the minimal synchrony needed for distributed consensus. J. ACM 34, 1 (Jan.), 77--97.

No context found.

D. Dolev, C. Dwork, and L. Stockmeyer. On the minimal synchrony needed for distributed consensus. Journal of ACM, 34(1):77--97, January 1987.

No context found.

D.Dolev, C. Dwork, and L. Stockmeyer. On the minimal synchrony needed for distributed consensus. Journal of ACM, 34(1):77--97, January 1987. 44

No context found.

D. Dolev, C. Dwork, and L. Stockmeyer. On the minimal synchrony needed for distributed consensus. Journal of the ACM, 34(1):7797, January 1987.

No context found.

D. Dolev, C. Dwork, and L. Stockmeyer. On the minimal synchrony needed for distributed consensus. Journal of ACM, 34(1):77--97, January 1987.

No context found.

D. Dolev, C. Dwork, L. Stockmeyer, On the minimal synchrony needed for distributed consensus, J. ACM 34(1) (1987) 77--97.

No context found.

D. Dolev, C. Dwork, L. Stockmeyer, On the minimal synchrony needed for distributed consensus, J. of the ACM, vol. 34 (1), pp. 77-97, January 1987.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC