The consensus number for a mutex would be 1. It's trivially clear that a mutex will be wait-free for a single thread. From its definition, it's also clear that a mutex is no longer wait-free for two threads. The consensus number therefore is >=1 and <2, so it must be 1.
Likewise, other synchronization mechanisms that work by halting one thread in favor of another also have consensus number 1, and therefore cannot be used to construct a wait-free object shared by 2 threads.
The answer depends on the supported operations on the mutex or the semaphore. If only blocking locks are supported, the consensus number is 1. If a thread can try to lock the mutex without waiting, the consensus number is 2. That is because if there are two threads, both can try to lock the mutex, both can agree which one got it, so there is consensus. If the mutex can additionally determine, for any number of threads, which thread has locked it, then the consensus number is infinite. I think the situation for semaphores is similar. Mutexes are equivalent to semaphores with the counter 1. I don't think consensus can be reached just with larger counters, it still comes down to the same operations. Pthreads supports non-blocking locks but not queries, so there the answer would be 2.
Signaling a condition variable does nothing if any threads are not waiting for it, so they have consensus number 1.
Perhaps I'm misunderstanding. You say a mutex has a consensus number of 2 - what's your source for that? It's designed to allow any number of threads to share a resource, with the trade-off of blocking.
Atomic test-and-set has a consensus number of 2, but doesn't block.
To clarify: semaphores, mutexes, etc. are primitives that you can simply wrap around a shared resource to make it safe (as long as you do it correctly). They may block, but they will guarantee your data is safe.
The paper you cite is about the primitives needed to protect data without blocking, which is hard. The same primitives may be useful for locks as well, but that's just a nice extra.
From this article alone you can conclude that a semaphore must have a consensus number less than or equal to 2. Here's why:
On the third page of the article they state: "The fetch&add operation is quite flexible: it can be used for semaphores...". Since we know that fetch&add has consensus number equal to 2, Theorem 1 of that paper can then be used to show that a semaphore must have consensus number less than or equal to 2. The proof goes like this:
Proof
Assume that a wait-free implementation of semaphores by fetch&add exists. Further assume that a semaphore has consensus number greater than 2. We know that fetch&add has a consensus number of 2. From Theorem 1 we can conclude that there exists no wait-free implementation of a semaphore by fetch&add in a system of more than 2 processes. This contradicts the assumption that an implementation by fetch&add exists. Therefore, a semaphore must have a consensus number less than or equal to 2.
发布评论
评论（4）
互斥体的共识数为 1。很明显，互斥体对于单个线程来说是无等待的。 从其定义中也可以清楚地看出，互斥锁对于两个线程来说不再是无等待的。 因此，共识编号为 >=1 且 <2，因此它必须为 1。
同样，通过停止一个线程以支持另一个线程来工作的其他同步机制也具有共识编号 1，因此不能用于构造等待- 2 个线程共享的自由对象。
The consensus number for a mutex would be 1. It's trivially clear that a mutex will be wait-free for a single thread. From its definition, it's also clear that a mutex is no longer wait-free for two threads. The consensus number therefore is >=1 and <2, so it must be 1.
Likewise, other synchronization mechanisms that work by halting one thread in favor of another also have consensus number 1, and therefore cannot be used to construct a wait-free object shared by 2 threads.
答案取决于互斥锁或信号量支持的操作。 如果只支持阻塞锁，则共识数为1。如果一个线程无需等待就可以尝试锁定互斥锁，则共识数为2。那是因为如果有两个线程，都可以尝试锁定互斥锁，则都可以同意谁得到了它，所以就有了共识。 如果互斥体可以另外确定对于任意数量的线程，哪个线程锁定了它，那么共识数量是无限的。 我认为信号量的情况类似。 互斥量相当于计数器为 1 的信号量。我认为仅使用更大的计数器无法达成共识，它仍然归结为相同的操作。 Pthreads 支持非阻塞锁，但不支持查询，因此答案为 2。
如果任何线程不等待条件变量，则向条件变量发出信号不会执行任何操作，因此它们的共识编号为 1。
The answer depends on the supported operations on the mutex or the semaphore. If only blocking locks are supported, the consensus number is 1. If a thread can try to lock the mutex without waiting, the consensus number is 2. That is because if there are two threads, both can try to lock the mutex, both can agree which one got it, so there is consensus. If the mutex can additionally determine, for any number of threads, which thread has locked it, then the consensus number is infinite. I think the situation for semaphores is similar. Mutexes are equivalent to semaphores with the counter 1. I don't think consensus can be reached just with larger counters, it still comes down to the same operations. Pthreads supports non-blocking locks but not queries, so there the answer would be 2.
Signaling a condition variable does nothing if any threads are not waiting for it, so they have consensus number 1.
无限，肯定吗？ 但他们并不是闲着等。
或许我理解有误。 你说互斥锁的共识数是 2 - 你的来源是什么？ 它的设计目的是允许任意数量的线程共享资源，但需要权衡阻塞。
Atomic test-and-set 的共识数为 2，但没有t块。
澄清一下：信号量、互斥体等都是原语，您可以简单地包装共享资源以使其安全（只要您做得正确）。 他们可能会阻止，但他们会保证您的数据是安全的。
您引用的论文是关于保护数据所需的原语而不阻塞，即很难。 相同的原语也可能对锁有用，但这只是一个很好的额外功能。
Infinite, surely? But they're not wait free.
Perhaps I'm misunderstanding. You say a mutex has a consensus number of 2 - what's your source for that? It's designed to allow any number of threads to share a resource, with the trade-off of blocking.
Atomic test-and-set has a consensus number of 2, but doesn't block.
To clarify: semaphores, mutexes, etc. are primitives that you can simply wrap around a shared resource to make it safe (as long as you do it correctly). They may block, but they will guarantee your data is safe.
The paper you cite is about the primitives needed to protect data without blocking, which is hard. The same primitives may be useful for locks as well, but that's just a nice extra.
仅从这篇文章中，您就可以得出结论，信号量必须具有小于或等于 2 的共识数。原因如下：
在文章的第三页上，他们指出：“提取和添加操作非常灵活：它可以用于信号量...”。 由于我们知道 fetch&add 的共识数等于 2，因此可以使用该论文的定理 1 来证明信号量的共识数必须小于或等于 2。证明如下： 证明
假设
等待- 存在通过 fetch&add 实现的信号量的自由实现。 进一步假设信号量的共识数大于 2。我们知道 fetch&add 的共识数为 2。从定理 1 我们可以得出结论，在系统中不存在 fetch&add 的信号量无等待实现。超过2个进程。 这与存在 fetch&add 实现的假设相矛盾。 因此，信号量的共识数必须小于或等于2。
QED
From this article alone you can conclude that a semaphore must have a consensus number less than or equal to 2. Here's why:
On the third page of the article they state: "The fetch&add operation is quite flexible: it can be used for semaphores...". Since we know that fetch&add has consensus number equal to 2, Theorem 1 of that paper can then be used to show that a semaphore must have consensus number less than or equal to 2. The proof goes like this:
Proof
Assume that a wait-free implementation of semaphores by fetch&add exists. Further assume that a semaphore has consensus number greater than 2. We know that fetch&add has a consensus number of 2. From Theorem 1 we can conclude that there exists no wait-free implementation of a semaphore by fetch&add in a system of more than 2 processes. This contradicts the assumption that an implementation by fetch&add exists. Therefore, a semaphore must have a consensus number less than or equal to 2.
QED