# Failure Detectors, and Non-Blocking Atomic Commit

DevFeed: [Failure Detectors, and Non-Blocking Atomic Commit](<https://devfeed.tech/articles/failure-detectors-and-non-blocking-atomic-commit-12455.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2014/04/14/failure-detectors.html>)

Author: Marc Brooker

Published: 2014-04-14T00:00:00Z

Content type: article

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [distributed-systems](<https://devfeed.tech/topics/distributed-systems.md>), [systems](<https://devfeed.tech/topics/systems.md>), [Processes](<https://devfeed.tech/topics/processes.md>), [Replication](<https://devfeed.tech/topics/replication.md>)

Tags: [distributed-systems](<https://devfeed.tech/tags/distributed-systems.md>), [process](<https://devfeed.tech/tags/process.md>), [processes](<https://devfeed.tech/tags/processes.md>), [systems](<https://devfeed.tech/tags/systems.md>)

## AI overview

The article introduces failure detectors as a practical way to address impossibility results in asynchronous distributed systems. It explains unreliable, distributed failure detectors, where each process locally tracks suspected failures and may make false suspicions or miss actual failures. It also relates these ideas to consensus and atomic commit.

## Source excerpt

Failure Detectors, and Non-Blocking Atomic Commit Non-blocking atomic commit is harder than uniform consensus. Why would that be? Many of the most interesting results in distributed systems have come from looking at problems known to be impossible under one set of constraints, and finding how little those constraints can be relaxed before the problem becomes possible. One great example is how adding a random Oracle to the asynchronous system model used by FLP makes consensus possible. That result is very interesting, but not as practically important as the idea of failure detectors. The theoretical importance of detecting failures in the asynchronous model dates back to work in the 1980s from Dolev, Dwork and Stockmeyer and Dwork, Lynch and Stockmeyer. The latter of these papers is very interesting, because it describes what can be argued is the first practical consensus algorithm before the publication of Viewstamped Replication and Paxos. More on that another time. A great, detailed, description and characterization of failure detectors can be found in Unreliable Failure Detectors for Reliable Distributed Systems by Chandra and Toueg. They also introduced the concept of unreliable failure detectors: In this paper, we propose an alternative approach to circumvent such impossibility results, and to broaden the applicability of the asynchronous model of computation. Since impossibility results for asynchronous systems stem from the inherent difficulty of determining whether a process has actually crashed or is only "very slow," we propose to augment the asynchronous model of computation with a model of an external failure detection mechanism that can make mistakes. In particular, we model the concept of unreliable failure detectors for systems with crash failures. The failure detectors that Chandra and Toueg describe are distributed, rather than global, failure detectors. Each process uses local state to keep a list of other processes that it suspects have failed, an