调用 pthread_cond_signal 而不锁定互斥锁

Question

我在某处读到，我们应该在调用 pthread_cond_signal 之前锁定互斥体，并在调用后解锁互斥体：

pthread_cond_signal() 例程是 用于向另一个人发出信号（或唤醒） 正在等待的线程 条件变量。应该是 互斥体锁定后调用，并且必须 解锁互斥体以便 pthread_cond_wait() 例程 完成。

我的问题是：在不锁定互斥体的情况下调用 pthread_cond_signal 或 pthread_cond_broadcast 方法不是可以吗？

Answer 1

如果您不锁定更改条件和信号的代码路径中的互斥锁，则可能会丢失唤醒。考虑这对进程：

进程 A：

pthread_mutex_lock(&mutex);
while (condition == FALSE)
    pthread_cond_wait(&cond, &mutex);
pthread_mutex_unlock(&mutex);

进程 B（不正确）：

condition = TRUE;
pthread_cond_signal(&cond);

然后考虑这种可能的指令交错，其中 condition 开始为 < code>FALSE：

Process A                             Process B

pthread_mutex_lock(&mutex);
while (condition == FALSE)

                                      condition = TRUE;
                                      pthread_cond_signal(&cond);

pthread_cond_wait(&cond, &mutex);

条件现在为TRUE，但进程 A 一直在等待条件变量 - 它错过了唤醒信号。如果我们改变进程 B 来锁定互斥体：

进程 B（正确）：

pthread_mutex_lock(&mutex);
condition = TRUE;
pthread_cond_signal(&cond);
pthread_mutex_unlock(&mutex);

...那么上述情况就不会发生；唤醒永远不会错过。

（请注意，实际上您可以将pthread_cond_signal()本身移到pthread_mutex_unlock()之后，但这可能会导致线程调度效果不佳，并且由于条件本身的更改，您必须锁定此代码路径中已经存在的互斥体）。

Answer 2

根据本手册：

pthread_cond_broadcast() 或
pthread_cond_signal() 函数
可以由线程调用，无论它当前是否拥有互斥体
线程调用 pthread_cond_wait()
或 pthread_cond_timedwait() 有
与条件变量相关
在等待期间；然而，如果
可预测的调度行为是
需要，那么该互斥锁应为
被调用线程锁定
pthread_cond_broadcast() 或
pthread_cond_signal()。

Dave Butenhof（使用 POSIX 线程进行编程）位于 comp.programming.threads 上，并且可以使用 此处。

Answer 3

caf，在您的示例代码中，进程 B 修改 condition 而不首先锁定互斥体。如果进程 B 在修改期间只是锁定互斥体，然后在调用 pthread_cond_signal 之前仍然解锁互斥体，那么就不会有问题 --- 我的说法正确吗？

我凭直觉相信 caf 的位置是正确的：在不拥有互斥锁的情况下调用 pthread_cond_signal 是一个坏主意。但咖啡馆的例子实际上并不是支持这一立场的证据；这只是支持更弱（实际上不言而喻）的立场的证据，即除非您首先锁定了该互斥体，否则修改由互斥体保护的共享状态是一个坏主意。

任何人都可以提供一些示例代码，其中调用 pthread_cond_signal 后跟 pthread_mutex_unlock 会产生正确的行为，但调用 pthread_mutex_unlock 后跟 pthread_cond_signal > 产生不正确的行为？