Participant-Restricted Consensus in Asynchronous Crash-Prone Read/Write Systems and Its Weakest Failure Detector

  • Carole Delporte-Gallet
  • Hugues Fauconnier
  • Michel RaynalEmail author
Conference paper
Part of the Lecture Notes in Computer Science book series (LNCS, volume 11657)


A failure detector is a device (object) that provides the processes with information on failures. Failure detectors were introduced to enrich asynchronous systems so that it becomes possible to solve problems (or implement concurrent objects) that are otherwise impossible to solve in pure asynchronous systems where processes are prone to crash failures. The most famous failure detector (which is called “eventual leader” and denoted \(\varOmega \)) is the weakest failure detector which allows consensus to be solved in n-process asynchronous systems where up to \(t=n-1\) processes may crash in the read/write communication model, and up to \(t<n/2\) processes may crash in the message-passing communication model. In these models, all correct processes are supposed to participate in a consensus instance and in particular the eventual leader.

This paper considers the case where some subset of processes that do not crash (not predefined in advance) are allowed not to participate in a consensus instance. In this context \(\varOmega \) cannot be used to solve consensus as it could elect as eventual leader a non-participating process. This paper presents the weakest failure detector that allows correct processes not to participate in a consensus instance.This failure detector, denoted \(\varOmega ^*\), is a variant of \(\varOmega \). The paper presents also an \(\varOmega ^*\)-based consensus algorithm for the asynchronous read/write model, in which any number of processes may crash, and not all the correct processes are required to participate.


Agreement Asynchronous system Atomic read/write register Concurrency Consensus Eventual leadership Failure detector Participating process Process crash Read/write shared memory Snapshot object Weakest information on failures 



This work was partially supported by the French ANR project DESCARTES (16-CE40-0023-03) devoted to layered and modular structures in distributed computing. We want to thank the referees for their constructive comments.


  1. 1.
    Afek, Y., Attiya, H., Dolev, D., Gafni, E., Merritt, M., Shavit, N.: Atomic snapshots of shared memory. JACM 40(4), 873–890 (1993)CrossRefGoogle Scholar
  2. 2.
    Anderson, J.: Multi-writer composite registers. Distrib. Comput. 7(4), 175–195 (1994)MathSciNetCrossRefGoogle Scholar
  3. 3.
    Attiya, H., Welch, J.L.: Distributed Computing: Fundamentals, Simulations and Advanced Topics, 2nd edn. Wiley-Interscience, p. 414 (2004). ISBN 0-471-45324-2Google Scholar
  4. 4.
    Ben-Or, M.: Another advantage of free choice: completely asynchronous agreement protocols. In: Proceedings of 2nd ACM Symposium on Principles of Distributed Computing (PODC 1983), pp. 27–30. ACM Press (1983)Google Scholar
  5. 5.
    Chandra, T., Hadzilacos, V., Toueg, S.: The weakest failure detector for solving consensus. J. ACM 43(4), 685–722 (1996)MathSciNetCrossRefGoogle Scholar
  6. 6.
    Chandra, T., Toueg, S.: Unreliable failure detectors for reliable distributed systems. J. ACM 43(2), 225–267 (1996)MathSciNetCrossRefGoogle Scholar
  7. 7.
    Delporte-Gallet, C., Fauconnier, H., Guerraoui, R.: Tight failure detection bounds on atomic object implementations. J. ACM 57(4), 32 (2010). Article 22MathSciNetzbMATHGoogle Scholar
  8. 8.
    Fernández, A., Jiménez, E., Raynal, M., Trédan, G.: A timing assumption and two \(t\)-resilient protocols for implementing an eventual leader service in asynchronous shared-memory systems. Algorithmica 56(4), 550–576 (2010)MathSciNetCrossRefGoogle Scholar
  9. 9.
    Guerraoui, R., Kapalka, M., Kuznetsov, P.: The weakest failure detectors to boost obstruction-freedom. Distrib. Comput. 20(6), 415–433 (2008)CrossRefGoogle Scholar
  10. 10.
    Fischer, M.J., Lynch, N.A., Paterson, M.S.: Impossibility of distributed consensus with one faulty process. J. ACM 32(2), 374–382 (1985)MathSciNetCrossRefGoogle Scholar
  11. 11.
    Hélary, J.-M., Hurfin, M., Mostéfaoui, A., Raynal, M., Tronel, F.: Computing global functions in asynchronous distributed systems with perfect failure detectors. IEEE Trans. Parallel Distrib. Syst. 11(9), 897–909 (2000)CrossRefGoogle Scholar
  12. 12.
    Lo, W.-K., Hadzilacos, V.: Using failure detectors to solve consensus in asynchronous shared-memory systems. In: Tel, G., Vitányi, P. (eds.) WDAG 1994. LNCS, vol. 857, pp. 280–295. Springer, Heidelberg (1994). Scholar
  13. 13.
    Loui, M., Abu-Amara, H.: Memory requirements for agreement among unreliable asynchronous processes. In: Preparata, F.P. (ed.) Advances in Computing Research, vol. 4, pp. 163–183. JAI Press, Greenwich (1987)Google Scholar
  14. 14.
    Lynch, N.A.: Distributed Algorithms, p. 872. Morgan Kaufmann Pub., San Francisco (1996)zbMATHGoogle Scholar
  15. 15.
    Mostéfaoui, A., Raynal, M.: Solving consensus using Chandra-Toueg’s unreliable failure detectors: a general quorum-based approach. In: Jayanti, P. (ed.) DISC 1999. LNCS, vol. 1693, pp. 49–63. Springer, Heidelberg (1999). Scholar
  16. 16.
    Raynal, M.: Concurrent Programming: Algorithms, Principles, and Foundations, p. 515. Springer, Heidelberg (2013). Scholar
  17. 17.
    Raynal, M.: Fault-Tolerant Message-Passing Distributed Systems: An Algorithmic Approach, p. 492. Springer, Switzerland (2018). Scholar
  18. 18.
    Raynal, M., Travers, C.: In search of the holy grail: looking for the weakest failure detector for wait-free set agreement. In: Shvartsman, M.M.A.A. (ed.) OPODIS 2006. LNCS, vol. 4305, pp. 3–19. Springer, Heidelberg (2006). Scholar
  19. 19.
    Taubenfeld, G.: Synchronization Algorithms and Concurrent Programming, p. 423. Upper Saddle River, Pearson Education/Prentice Hall (2006)Google Scholar

Copyright information

© Springer Nature Switzerland AG 2019

Authors and Affiliations

  • Carole Delporte-Gallet
    • 1
  • Hugues Fauconnier
    • 1
  • Michel Raynal
    • 2
    • 3
    Email author
  1. 1.IRIF, Université Paris 7 DiderotParisFrance
  2. 2.IRISA, Université de RennesRennesFrance
  3. 3.Department of ComputingPolytechnic UniversityHung HomHong Kong

Personalised recommendations