条件变量的这种使用是否总是会受到信号丢失竞争的影响？

Question

假设在信号线程修改影响谓词真值的状态并调用 pthread_cond_signal 而不持有与条件变量关联的互斥体的情况下使用条件变量？这种类型的使用是否总是受到可能会丢失信号的竞争条件的影响？

对我来说，似乎总是存在明显的竞争：

1. Waiter 将谓词评估为 false，但在它开始等待之前...
2. 另一个线程以某种方式更改状态，使谓词为 true。
3. 另一个线程调用 pthread_cond_signal，它不执行任何操作，因为还没有等待者。
4. 等待线程进入 pthread_cond_wait ，不知道谓词现在为真，并无限期等待。

但是，如果情况发生变化，这种相同类型的竞争条件是否总是存在，以便 (A) 在调用 pthread_cond_signal 时保留互斥体，而不是在更改状态时，或者 (B) 以便更改状态时会保持互斥锁，而不是在调用 pthread_cond_signal 时保持互斥锁？

我从想知道上述非最佳实践用法是否有任何有效用途的角度出发，即正确的条件变量实现是否需要考虑这种用法以避免竞争条件本身，或者是否可以忽略它们，因为它们本质上已经很活泼了。

Answer 1

这里的基本竞争如下所示：

THREAD A        THREAD B
Mutex lock
Check state
                Change state
                Signal
cvar wait
(never awakens)

如果我们对状态变化或信号或两者都进行锁定，那么我们就可以避免这种情况；当线程 A 处于其临界区并持有锁时，状态更改和信号不可能同时发生。

如果我们考虑相反的情况，即线程 A 交错到线程 B 中，则没有问题：

THREAD A        THREAD B
                Change state
Mutex lock
Check state
( no need to wait )
Mutex unlock
                Signal (nobody cares)

因此线程 B 没有特别需要在整个操作中持有互斥体；它只需要在状态变化和信号之间保持互斥体一段可能无限小的间隔。当然，如果状态本身需要锁定以进行安全操作，则也必须在状态更改时保持锁定。

最后，请注意，在大多数情况下，尽早删除互斥体不太可能提高性能。要求保持互斥体可以减少对条件变量中内部锁的争用，并且在现代 pthread 实现中，系统可以将等待线程从等待 cvar '移动' 为等待互斥体而不唤醒它（从而避免它醒来后立即阻止互斥体）。
正如评论中所指出的，在某些情况下，删除互斥体可能会通过减少所需的系统调用数量来提高性能。然而，它也可能导致对条件变量的内部互斥体的额外争用。很难说。无论如何，这可能都不值得担心。

请注意，适用标准要求 pthread_cond_signal无需持有互斥体即可安全调用：

无论线程当前是否拥有调用 pthread_cond_wait() 或 pthread_cond_timedwait() 的线程在等待期间与条件变量关联的互斥体，线程都可以调用 pthread_cond_signal() 或 pthread_cond_broadcast() 函数 [...]

这通常意味着条件变量对其内部数据结构有内部锁，或者使用一些非常仔细的无锁算法。

Answer 2

必须在互斥锁内修改状态，如果没有其他原因，除了可能出现虚假唤醒，这将导致读者在编写者正在编写状态时读取状态。

状态更改后，您可以随时调用pthread_cond_signal。它不必位于互斥体内部。 POSIX 保证至少有一名服务员会被唤醒来检查新状态。更重要的是：

1. 调用 pthread_cond_signal 并不能保证读取器首先获取互斥锁。在读者有机会检查新状态之前，另一位作者可能会介入。条件变量不能保证读者立即跟随编写者（毕竟，如果没有读者怎么办？）
2. 在释放锁后调用它实际上更好，因为您不会冒让刚刚唤醒的读者立即重新进入睡眠状态的风险尝试获取作者仍然持有的锁。

编辑： @DietrichEpp 在评论中提出了很好的观点。编写者必须以这样的方式更改状态，以使读者永远无法访问不一致的状态。正如我上面指出的，它可以通过获取条件变量中使用的互斥体来实现这一点，或者通过确保所有状态更改都是原子的。

Answer 3

答案是，存在竞争，为了消除竞争，您必须这样做：

/* atomic op outside of mutex, and then: */

pthread_mutex_lock(&m);
pthread_mutex_unlock(&m);

pthread_cond_signal(&c);

数据的保护并不重要，因为无论如何在调用 pthread_cond_signal 时您都不会持有互斥锁。

看，通过锁定和解锁互斥体，您已经创建了一个屏障。在信号发送者拥有互斥锁的那一刻，可以肯定的是：没有其他线程拥有互斥锁。这意味着没有其他线程正在执行任何关键区域。

这意味着所有线程要么即将获取互斥体以发现您已发布的更改，要么它们已经发现该更改并随之运行（释放互斥体），要么尚未找到它们正在寻找的并且已找到原子地放弃互斥体进入睡眠状态（并且保证在条件下很好地等待）。

如果没有互斥锁/解锁，就没有同步。当没有看到更改的原子值的线程转换到原子睡眠状态以等待它时，有时会触发该信号。

从发出信号的线程的角度来看，这就是互斥量的作用。您可以从其他地方获得访问的原子性，但不能获得同步。

PS 我之前已经实现过这个逻辑。这种情况发生在 Linux 内核中（使用我自己的互斥体和条件变量）。

在我的情况下，信号发送者不可能持有共享数据原子操作的互斥体。为什么？因为信号发送器在用户空间、内核和用户之间共享的缓冲区内执行操作，然后（在某些情况下）对内核进行系统调用以唤醒线程。用户空间只需对缓冲区进行一些修改，然后如果满足某些条件，它将执行ioctl。

因此，在 ioctl 调用中，我执行了互斥锁/解锁操作，然后命中条件变量。这确保了线程不会错过与用户空间发布的最新修改相关的唤醒。

起初我只有条件变量信号，但在没有互斥锁参与的情况下看起来是错误的，所以我对这种情况进行了一些推理，并意识到必须简单地锁定和解锁互斥锁以符合同步仪式，从而消除了失去唤醒。