POPL '87 Proceedings of the 14th ACM SIGACT-SIGPLAN symposium on Principles of programming languages
Sticky bits and universality of consensus
Proceedings of the eighth annual ACM Symposium on Principles of distributed computing
Linearizability: a correctness condition for concurrent objects
ACM Transactions on Programming Languages and Systems (TOPLAS)
ACM Transactions on Programming Languages and Systems (TOPLAS)
A completeness theorem for a class of synchronization objects
PODC '93 Proceedings of the twelfth annual ACM symposium on Principles of distributed computing
Delimiting the power of bounded size synchronization objects (extended abstract)
PODC '94 Proceedings of the thirteenth annual ACM symposium on Principles of distributed computing
Impossibility of distributed consensus with one faulty process
Journal of the ACM (JACM)
Some Results on the Impossibility, Universality, and Decidability of Consensus
WDAG '92 Proceedings of the 6th International Workshop on Distributed Algorithms
Common2 extended to stacks and unbounded concurrency
Proceedings of the twenty-fifth annual ACM symposium on Principles of distributed computing
Synchronization power depends on the register size
SFCS '93 Proceedings of the 1993 IEEE 34th Annual Foundations of Computer Science
On the power of breakable objects
Theoretical Computer Science
| Hi-index | 0.00 |
What characteristics of an object determine its consensus number? Here we analyze how the consensus power of various objects changes without changing their functionality, but by placing certain restrictions on the object usage. For example it is shown that the consensus number of either a bounded-use queue or stack is 3 while the consensus number of the long-lived bounded-size and unbounded-size versions of either is 2. Similarly we show that the consensus number of restricted versions of Fetch&Add, Swap and Set are infinite (n) while for the unrestricted counterparts it is 2. This paper thus underlines the fact that the consensus number of an object reflects the amount of coordination required in the object implementation and not by its capacity. That is, the more corners, broken edges, and other hard limitations placed on an object, the higher its consensus number tends to be.