答案 0 :(得分：10)
互斥锁的共识编号为1.很明显，互斥锁对于单个线程是等待的。从它的定义来看，同样清楚的是，两个线程的互斥锁不再是等待的。因此，共识数是> = 1且<2，所以它必须是1.
同样，通过暂停一个线程而使用另一个线程而工作的其他同步机制也具有共识编号1，因此不能用于构造由2个线程共享的无等待对象。
答案 1 :(得分：5)
答案取决于互斥锁或信号量上支持的操作。如果仅支持阻塞锁，则共识数为1.如果线程可以尝试在不等待的情况下锁定互斥锁，则共识数为2.这是因为如果有两个线程，则两者都可以尝试锁定互斥锁，两者都可以同意哪一个得到它，所以有共识。如果互斥锁可以另外确定，对于任何数量的线程，哪个线程已将其锁定，则共识数是无限的。我认为信号量的情况类似。互斥量相当于计数器1的信号量。我不认为只有较大的计数器才能达成共识，它仍然归结为相同的操作。 Pthreads支持非阻塞锁但不支持查询，所以答案是2。
如果任何线程没有等待它，那么发信号通知条件变量什么也不做，所以它们的共识号为1。
答案 2 :(得分：3)
无限，当然？但他们不是在等待自由。
也许我在误解。你说互斥锁的共识数为2 - 你的来源是什么？它旨在允许任意数量的线程共享资源，并通过权衡阻塞。
原子test-and-set的共识数为2，但不会阻止。
澄清：信号量，互斥量等是原始的，您可以简单地环绕共享资源以使其安全（只要您正确执行）。它们可能会阻止，但它们可以保证您的数据安全。
您引用的论文是关于保护数据而不阻塞所需的原语，即hard。同样的原语也可能对锁有用，但这只是一个很好的额外。
答案 3 :(得分：-1)
仅从这篇文章中您可以得出结论，信号量必须具有小于或等于2的共识数。这就是原因：
在文章的第三页，他们说：“fetch＆amp; add操作非常灵活：它可以用于信号量......”。由于我们知道fetch＆amp; add的共识数等于2，因此可以使用该论文的定理1来表明信号量必须具有小于或等于2的共识数。证明如下：
假设存在fetch＆amp; add等待信号量的无等待实现。进一步假设信号量的共识数大于2.我们知道fetch＆amp; add的共识数为2.从定理1我们可以得出结论，在一个系统中，fetch＆amp; add不存在信号量的无等待实现。超过2个进程。这与假设存在fetch＆amp; add的实现相矛盾。因此，信号量必须具有小于或等于2的共识数。
QED