Universal constructions that ensure disjoint-access parallelism and wait-freedom

Ellen, Faith; Fatourou, Panagiota; Kosmas, Eleftherios; Milani, Alessia; Travers, Corentin

doi:10.1007/s00446-015-0261-8

Cited by 10 publications

(7 citation statements)

References 40 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Most claims refer to the state of the execution of Q in specific points in the execution, described by a corresponding line in the algorithm given in Figure 1. These claims are proved by induction, where the induction variable is the iteration number of the main loop (lines [3][4][5][6][7][8][9][10][11][12][13][14][15][16]. The induction hypothesis is that claims (4.5-4.16) are correct.…”

Section: Remark 44 (3) Is Not Needed In the Proof But Is Stated Fmentioning

confidence: 96%

“…OBSERVATION 4.6. The order between op1 and op2 cannot be decided during the inner loop (lines [5][6][7][8][9][10][11][12].…”

Section: Remark 44 (3) Is Not Needed In the Proof But Is Stated Fmentioning

confidence: 99%

“…Previous work identifies relations of other properties of implementations to the possibility of being wait-free. For example, no universal construction can be wait-free and satisfy disjoint-access parallelism [6].…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Help!

Censor-Hillel

Petrank

Timnat

2015

Proceedings of the 2015 ACM Symposium on Principles of Distributed Computing

View full text Add to dashboard Cite

A fundamental challenge in designing concurrent data structures is obtaining efficient wait-free implementations, in which each operation completes regardless of the behavior of other operations in the system. The most common paradigm for guaranteeing waitfreedom is to employ a helping mechanism, in which, intuitively, fast processes help slow processes complete their operations. Curiously, despite its abundant use, to date, helping has not been formally defined nor was its necessity rigorously studied.In this paper we initiate a rigorous study of the interaction between wait-freedom and helping. We start with presenting a formal definition of help, capturing the intuition of one thread helping another to make progress. Next, we present families of object types for which help is necessary in order to obtain wait-freedom. In other words, we prove that for some types there are no linearizable wait-free help-free implementations. In contrast, we show that other, simple types, can be implemented in a linearizable wait-free manner without employing help. Finally, we provide a universal strong primitive for implementing wait-free data structures without using help. Specifically, given a wait-free help-free fetch&cons object, one can implement any type in a wait-free help-free manner.

show abstract

Section: Remark 44 (3) Is Not Needed In the Proof But Is Stated Fmentioning

confidence: 96%

“…OBSERVATION 4.6. The order between op1 and op2 cannot be decided during the inner loop (lines [5][6][7][8][9][10][11][12].…”

Section: Remark 44 (3) Is Not Needed In the Proof But Is Stated Fmentioning

confidence: 99%

See 1 more Smart Citation

Help!

Censor-Hillel

Petrank

Timnat

2015

Proceedings of the 2015 ACM Symposium on Principles of Distributed Computing

View full text Add to dashboard Cite

show abstract

“…As an example, a universal construction is presented in [8], where "processes operating on different parts of an implemented object do not interfere with each other by accessing common base objects". Several additional properties have been addressed in [2,9].…”

Section: Categories and Subject Descriptorsmentioning

confidence: 99%

Brief announcement

Raynal

Stainer

Taubenfeld

2014

Proceedings of the 2014 ACM Symposium on Principles of Distributed Computing

View full text Add to dashboard Cite

show abstract

“…For example, it is impossible to implement a consensus shared object using only asynchronous read/write shared memory while ensuring both wait-freedom, a liveness property, and agreement and validity, a safety property [8,28]. The history of distributed computing is full of such trade-offs [7,19,37,22,13,14,6,12,4].…”

Section: Introductionmentioning

confidence: 99%

Safety-Liveness Exclusion in Distributed Computing

Bushkov

Guerraoui

2015

Proceedings of the 2015 ACM Symposium on Principles of Distributed Computing

View full text Add to dashboard Cite

The history of distributed computing is full of trade-offs between safety and liveness. For instance, one of the most celebrated results in the field, namely the impossibility of consensus in an asynchronous system basically says that we cannot devise an algorithm that deterministically ensures consensus agreement and validity (i.e., safety) on the one hand, and consensus wait-freedom (i.e., liveness) on the other hand.The motivation of this work is to study the extent to which safety and liveness properties inherently exclude each other. More specifically, we ask, given any safety property S, whether we can determine the strongest (resp. weakest) liveness property that can (resp. cannot) be achieved with S. We show that, maybe surprisingly, the answers to these safety-liveness exclusion questions are in general negative. This has several ramifications in various distributed computing contexts. In the context of consensus for example, this means that it is impossible to determine the strongest (resp. the weakest) liveness property that can (resp. cannot) be ensured with linearizability.However, we present a way to circumvent these impossibilities and answer positively the safetyliveness question by considering a restricted form of liveness. We consider a definition that gathers generalized forms of obstruction-freedom and lock-freedom while enabling to determine the strongest (resp. weakest) liveness property that can (resp. cannot) be implemented in the context of consensus and transactional memory.

show abstract

Universal constructions that ensure disjoint-access parallelism and wait-freedom

Cited by 10 publications

References 40 publications

Help!

Help!

Brief announcement

Safety-Liveness Exclusion in Distributed Computing

Contact Info

Product

Resources

About