Atomic snapshots of shared memory
Journal of the ACM (JACM)
Generalized FLP impossibility result for t-resilient asynchronous computations
STOC '93 Proceedings of the twenty-fifth annual ACM symposium on Theory of computing
Impossibility of distributed consensus with one faulty process
Journal of the ACM (JACM)
Unreliable failure detectors for reliable distributed systems
Journal of the ACM (JACM)
The weakest failure detector for solving consensus
Journal of the ACM (JACM)
The decidability of distributed decision tasks (extended abstract)
STOC '97 Proceedings of the twenty-ninth annual ACM symposium on Theory of computing
Round-by-round fault detectors (extended abstract): unifying synchrony and asynchrony
PODC '98 Proceedings of the seventeenth annual ACM symposium on Principles of distributed computing
Structured derivations of consensus algorithms for failure detectors
PODC '98 Proceedings of the seventeenth annual ACM symposium on Principles of distributed computing
Three-Processor Tasks Are Undecidable
SIAM Journal on Computing
The BG distributed simulation algorithm
Distributed Computing
Anti-Ω: the weakest failure detector for set agreement
Proceedings of the twenty-seventh ACM symposium on Principles of distributed computing
The disagreement power of an adversary
DISC'09 Proceedings of the 23rd international conference on Distributed computing
DISC'09 Proceedings of the 23rd international conference on Distributed computing
On asymmetric progress conditions
Proceedings of the 29th ACM SIGACT-SIGOPS symposium on Principles of distributed computing
The topology of shared-memory adversaries
Proceedings of the 29th ACM SIGACT-SIGOPS symposium on Principles of distributed computing
The computational structure of progress conditions
DISC'10 Proceedings of the 24th international conference on Distributed computing
Simultaneous consensus tasks: a tighter characterization of set-consensus
ICDCN'06 Proceedings of the 8th international conference on Distributed Computing and Networking
Subconsensus tasks: renaming is weaker than set agreement
DISC'06 Proceedings of the 20th international conference on Distributed Computing
Obstruction-Free algorithms can be practically wait-free
DISC'05 Proceedings of the 19th international conference on Distributed Computing
Relating L-resilience and wait-freedom via hitting sets
ICDCN'11 Proceedings of the 12th international conference on Distributed computing and networking
A survey on some recent advances in shared memory models
SIROCCO'11 Proceedings of the 18th international conference on Structural information and communication complexity
Brief announcement: on the meaning of solving a task with a failure detector
DISC'11 Proceedings of the 25th international conference on Distributed computing
PODC '12 Proceedings of the 2012 ACM symposium on Principles of distributed computing
| Hi-index | 0.00 |
A liveness contract is an agreement between the specifier of a system and a task to solve, and the programmer who makes her living by delivering protocols. In a shared-memory system, a liveness contract specifies infinite suffixes of executions in which the programmer is required to solve a distributed task. If the behavior of the system does not comply with the specification, no output is required. A convenient way to describe a large class of liveness contracts was recently proposed by Delporte et al. For a system Π of n processes, an adversary is a set A of subsets of Π. The system is required to make progress only in executions in which the set of correct processes is in A. Given an adversary A and a task T, should the programmer sign the contract? Can she deliver? In this paper, we give a very simple resolution of this question for colorless tasks that contrasts with more involved arguments of the original paper of Delpote et al. More importantly, our resolution is constructive -- it tells the programmer how to use A to solve T, when it is solvable. Our framework naturally generalizes to systems enriched with more powerful objects than read-write registers. We determine necessary and sufficient conditions for an adversary A to solve consensus using j-process consensus objects and read-write registers, which resolves an open question raised recently by Taubenfeld.