为什么允许pthread_cond_wait（）有时会得到虚假的唤醒提升性能？

据我所知，pthread_cond_wait（）被记录为虚假唤醒，调用者必须检查该情况，并且其动机是为了允许pthread_cond_wait（）的实现具有更好的性能并强制调用者创建更强大的码。为什么允许pthread_cond_wait（）有时会得到虚假的唤醒提升性能？

但是，我还没有看到任何人对此提供的性能机会有具体的了解，但除了提到避免昂贵的竞争条件之外。

有人可以详细了解什么样的竞争条件会出现，以确保没有虚假唤醒和硬件架构会导致这种情况出现吗？

来源

2012-04-03 WilliamKF

事实证明，真正的动机显然是强迫用户检查循环中的谓词 - 可能的性能好处似乎有些次要的：http://stackoverflow.com/a/8594644/12711但是，这里是一个错误报告，指出NPTL可能会通过尝试*防止虚假唤醒来引入错误：http://sourceware.org/bugzilla/show_bug.cgi?id=13165#c13我仅以评论的形式呈现此内容，因为我不'不知道错误报告是否有效（比赛是复杂的事情）。 – 2012-04-03 20:06:20

我认为这是相反的。可以理解谓词应该被重新检查，因为condvar没有状态，（不像信号灯那样）。这个检查循环涵盖了即使condvar没有被发信号也会发生的任何虚假唤醒。 – 2012-04-04 10:55:06

不能保证您的线程在发送信号时会立即运行。它只是被标记为“准备好”，并且将在系统调度器的支配下运行。在这段时间之间它变得可调度并且它实际上被调度的时间，另一个线程可能已经改变了基本条件。

例如：

线程A：等待条件变量。

线程B：更新状态。信号条件变量。

线程C：复位状态

线程A：唤醒。检查底层状态，它不变。

来源

2012-04-03 14:44:25 Michael

这不是一个虚假的唤醒 - condvar已被发信号。来自Wiki：'其中一个原因是虚假唤醒;也就是说，即使没有线程指示条件，线程也可能会被唤醒。这就是，恕我直言，在Unix/Linux上说'condvars的另一种方式不能正常工作，必须在用户代码中应用修补程序。幸运的是，这被condvars的设计所掩盖，这意味着无论如何都必须应用循环检查。 – 2012-04-04 10:45:53

为什么允许pthread_cond_wait（）有时会得到虚假的唤醒提升性能？

回答

相关问题