c++ - 虚假的唤醒是否会解除阻塞所有正在等待的线程，甚至是无关的线程？

Question

我仍然对C++中的多线程还不陌生，并且我目前正试图将自己的头缠在“虚假唤醒”上以及造成它们的原因。我已经对条件变量，内核信号，futex等进行了一些挖掘，发现了造成“虚假唤醒”的原因和方式的一些元凶，但是仍然找不到答案。 。

问题:伪唤醒是否会解除阻止所有正在等待/被阻止的线程，甚至是那些等待完全不相关的通知的线程？还是对于被阻塞的线程有单独的等待队列，因此等待另一个通知的线程受到保护？

示例:假设我们有249名斯巴达人在等待攻击波斯人。他们将首领列奥尼达斯(第250名)的wait()改为攻击时的notify_all()。现在，在营地的另一侧，有49名受伤的斯巴达人，他们在等医生(第50名)来notify_one()，以便他可以对每个人进行治疗。虚假的唤醒会解除阻止所有等待中的斯巴达人，包括受伤的斯巴达人，还是只会影响等待战斗的人？是否有两个单独的队列用于等待线程，或者仅一个用于所有线程？

如果示例令人误解，我们深表歉意。。。我不知道该怎么解释。

Answer 1

虚假唤醒的原因特定于每个操作系统，此类唤醒的属性也是如此。例如，在Linux中，当信号传递到阻塞线程时会发生唤醒。执行完信号处理程序后，线程不会再次阻塞，而是从被阻塞的系统调用中接收到特殊的错误代码(通常为EINTR)。由于信号处理不涉及其他线程，因此不会被唤醒。

请注意，虚假唤醒不取决于您要阻止的同步原语或该原语上被阻止的线程数。非同步阻止系统调用(例如read或write)也可能发生这种情况。通常，您必须假定任何阻塞的系统调用可能会由于任何原因而过早返回，除非POSIX之类的规范不能保证不会这样做(即使那样，也可能会存在与规范不符的错误和OS细节)。

有些将多余的通知归因于虚假唤醒，因为处理两者通常是相同的。但是，它们并不相同。与伪唤醒不同，多余的通知实际上是由另一个线程引起的，并且是对条件变量或futex进行通知操作的结果。这只是您在无阻塞线程设法检查唤醒之前检查唤醒的条件。