【问题讨论】：
标签： synchronization pthreads mutex semaphore condition-variable
互斥体的共识数为 1。很明显，互斥体对于单个线程是无等待的。从它的定义来看，互斥体不再对两个线程无等待。因此共识数是 >=1 和
同样，通过停止一个线程以支持另一个线程的其他同步机制也具有共识编号 1，因此不能用于构造由 2 个线程共享的无等待对象。
【讨论】：
答案取决于互斥体或信号量上支持的操作。如果只支持阻塞锁，则共识数为1。如果一个线程可以尝试锁定互斥锁而不等待，则共识数为2。那是因为如果有两个线程，都可以尝试锁定互斥锁，两者都可以同意哪一个得到它，所以有共识。如果互斥锁可以额外确定，对于任意数量的线程，哪个线程锁定了它，那么共识数是无限的。我认为信号量的情况类似。互斥量相当于带有计数器 1 的信号量。我认为仅使用更大的计数器就无法达成共识，它仍然归结为相同的操作。 Pthreads 支持非阻塞锁但不支持查询，所以答案是 2。
如果任何线程没有等待它，则向条件变量发出信号不会执行任何操作，因此它们的共识编号为 1。
【讨论】：
肯定是无限的吧？但他们不是免费等待的。
也许我误会了。您说互斥体的共识数为 2 - 您的来源是什么？它的设计目的是允许任意数量的线程共享资源，并以阻塞为代价。
Atomic test-and-set 的共识数为 2，但不会阻塞。
澄清一下：信号量、互斥体等是原语，您可以简单地将共享资源包装起来以使其安全（只要您正确执行）。他们可能会阻止，但他们会保证您的数据是安全的。
您引用的论文是关于保护数据无阻塞所需的原语，即hard。相同的原语也可能对锁有用，但这只是一个不错的附加功能。
【讨论】：
仅从本文中，您就可以得出结论，信号量的共识数必须小于或等于 2。原因如下：
在文章的第三页他们说：“fetch&add 操作非常灵活：它可以用于信号量......”。由于我们知道 fetch&add 的共识数等于 2，因此可以使用该论文的定理 1 来证明信号量的共识数必须小于或等于 2。证明如下：
假设存在通过 fetch&add 实现的信号量的无等待实现。进一步假设信号量的共识数大于 2。我们知道 fetch&add 的共识数为 2。从定理 1 我们可以得出结论，在超过 2 个进程的系统中不存在通过 fetch&add 实现的信号量的无等待实现.这与存在 fetch&add 实现的假设相矛盾。因此，一个信号量的共识数必须小于或等于 2。
QED
【讨论】：