In search of lost time

Charron-Bost, Bernadette; Hutle, Martin; Widder, Josef

doi:10.1016/j.ipl.2010.07.017

Cited by 10 publications

(18 citation statements)

References 11 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Therefore, if a failure detector D is the weakest to solve a problem P , then a natural question follows: is the synchronism encoded in the outputs of D the minimal synchronism necessary to solve P in a crashprone partially synchronous system? Work to date suggests that the answer is affirmative for some problems [19,22] and negative for others [6]. To our knowledge, there is no characterization of the problems for which the aforementioned question is answered in the affirmative or in the negative.…”

Section: Background and Motivationmentioning

confidence: 93%

“…In contrast, in the failuredetector model, only the failure-detector behavior is constrained by real time, whereas the behavior of all other entities is asynchronous. The differences between the two styles of models have been the subject of recent work [6,17] which has brought the theory of failure detectors under additional scrutiny. We discuss five aspects of failure-detector theory that remain unresolved: self-implementability, interaction mechanism, the kind of information provided by a failure detector, comparing failure-detector strengths, and the relationship between weakest failure detectors and partial synchrony.…”

Section: Background and Motivationmentioning

confidence: 99%

“…Whether or not failure detectors can provide information about events other than process crashes has a significant impact on the weakest failure detectors for problems such as Non-Blocking Atomic Commit [14,15] and Uniform Reliable Broadcast [1,16]. In order to restrict failure detectors to the ones that give 1 For example, consider the instantaneously perfect failure detector P + [6] which always outputs the exactly the set of crashed processes and the perfect failure detector P [5] which never suspects live processes and eventually and permanently suspects crashed processes. Under the definition of "implementing a failure detector" from [17], an implementation of P + is indistinguishable from an implementation of P.…”

Section: Background and Motivationmentioning

confidence: 99%

See 2 more Smart Citations

Asynchronous failure detectors

Conrejo

Lynch

Sastry

2012

Proceedings of the 2012 ACM Symposium on Principles of Distributed Computing

View full text Add to dashboard Cite

Failure detectors -oracles that provide information about process crashes -are an important abstraction for crash tolerance in distributed systems. Although current failuredetector theory provides great generality and expressiveness, it also poses significant challenges in developing a robust hierarchy of failure detectors. We address some of these challenges by proposing a variant of failure detectors called asynchronous failure detectors and an associated modeling framework. Unlike the traditional failure-detector framework, our framework eschews real time completely. We show that asynchronous failure detectors are sufficiently expressive to include several popular failure detectors. Additionally, we show that asynchronous failure detectors satisfy many desirable properties: they are self-implementable, guarantee that stronger asynchronous failure detectors solve more problems, and ensure that their outputs encode no information other than process crashes. We introduce the notion of a failure detector being representative of a problem to capture the idea that some problems encode the same information about process crashes as their weakest failure detectors do. We show that a large class of problems, called finite problems, do not have representative failure detectors.

show abstract

Section: Background and Motivationmentioning

confidence: 93%

Section: Background and Motivationmentioning

confidence: 99%

Section: Background and Motivationmentioning

confidence: 99%

See 1 more Smart Citation

Asynchronous failure detectors

Conrejo

Lynch

Sastry

2012

Proceedings of the 2012 ACM Symposium on Principles of Distributed Computing

View full text Add to dashboard Cite

show abstract

“…For instance, in this framework, the oracles are self-implementable, in contrast with the traditional failure detectors' frameworks [11].…”

Section: Run Behaviour Oracle and Implementationmentioning

confidence: 99%

Self-stabilizing Leader Election in Population Protocols over Arbitrary Communication Graphs

Beauquier

Blanchard

Burman

2013

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract. This paper considers the fundamental problem of self-stabilizing leader election (SSLE) in the model of population protocols. In this model, an unknown number of asynchronous, anonymous and nite state mobile agents interact in pairs over a given communication graph. SSLE has been shown to be impossible in the original model. This impossibility can been circumvented by a modular technique augmenting the system with an oracle -an external module abstracting the added assumption about the system. Fischer and Jiang have proposed solutions to SSLE, for complete communication graphs and rings, using an oracle Ω?, called the eventual leader detector. In this work, we present a solution for arbitrary graphs, using a composition of two copies of Ω?. We also prove that the di culty comes from the requirement of self-stabilization, by giving a solution without oracle for arbitrary graphs, when an uniform initialization is allowed. Finally, we prove that there is no self-stabilizing implementation of Ω? using SSLE, in a sense we de ne precisely.

show abstract

“…In order for this information to be useful to the asynchronous algorithm, from some time on, the oracle has to provide reliable information forever [38,39]. Chandra and Toueg also showed that such oracles can be implemented in a generalization of the partially synchronous systems of [8].…”

Section: Asynchronous System With a Failure Detectormentioning

confidence: 99%

Consensus in the presence of mortal Byzantine faulty processes

et al. 2011

Self Cite

View full text Add to dashboard Cite

We consider the problem of reaching agreement in distributed systems in which some processes may deviate from their prescribed behavior before they eventually crash. We call this failure model "mortal Byzantine". After discussing some application examples where this model is justified, we provide matching upper and lower bounds on the number of faulty processes, and on the required number of rounds in synchronous systems. We then continue our study by varying different system parameters. On the one hand, we consider the failure model under weaker timing assumptions, namely for partially synchronous systems and asynchronous systems with unreliable failure detectors. On the other hand, we vary the failure model in that we limit the occurrences of faulty steps that actually lead to a crash in synchronous systems.

show abstract

In search of lost time

Cited by 10 publications

References 11 publications

Asynchronous failure detectors

Asynchronous failure detectors

Self-stabilizing Leader Election in Population Protocols over Arbitrary Communication Graphs

Consensus in the presence of mortal Byzantine faulty processes

Contact Info

Product

Resources

About