线程 : pthread_cond_signal() from within critical section

Question

我在线程 A 中有以下代码，它使用 pthread_cond_wait() 阻塞

pthread_mutex_lock(&my_lock);     
if ( false == testCondition )        
    pthread_cond_wait(&my_wait,&my_lock); 
pthread_mutex_unlock(&my_lock);

我在线程 B 中有以下代码段，它向线程 A 发出信号

pthread_mutex_lock(&my_lock);  
testCondition = true;
pthread_cond_signal(&my_wait);
pthread_mutex_unlock(&my_lock);

如果没有其他线程，如果 pthread_cond_signal(&my_wait) 会有什么不同吗？被移出临界区块，如下所示？

pthread_mutex_lock(&my_lock);  
testCondition = true;
pthread_mutex_unlock(&my_lock);
pthread_cond_signal(&my_wait);

Answer 1

我的建议通常是将 pthread_cond_signal() 调用保留在锁定区域内，但可能不是出于您认为的原因。

在大多数情况下，是否在持有锁的情况下调用 pthread_cond_signal() 并不重要。 Ben 是对的，如果有另一个线程在等待，一些调度程序可能会在释放锁时强制上下文切换，因此您的线程可能会在调用 pthread_cond_signal() 之前被切换掉。另一方面，一些调度程序会在您调用 pthread_cond_signal() 后立即运行等待线程，因此如果您在持有锁的情况下调用它，等待线程将唤醒然后立即返回 sleep 状态(因为它现在在互斥锁上被阻塞) 直到信号线程将其解锁。确切的行为是高度特定于实现的，并且可能会在操作系统版本之间发生变化，因此您不能依赖它。

但是，所有这些都忽略了您应该最关心的问题，即代码的可读性和正确性。您不太可能从这种微优化中看到任何实际的性能优势(请记住优化的第一条规则:配置第一，优化第二)。但是，如果您知道等待线程集不能在设置条件和发送信号的点之间更改，那么考虑控制流会更容易。否则，您必须考虑诸如“如果线程 A 设置 testCondition=TRUE 并释放锁，然后线程 B 运行并看到 testCondition 为真，因此它跳过 pthread_cond_wait() 并继续将 testCondition 重置为 0x9145，最后会怎样”线程 A 运行并调用 FALSE ，这会唤醒线程 C，因为线程 B 实际上没有在等待，但 pthread_cond_signal() 不再是真的”。这是令人困惑的，并可能导致难以诊断代码中的竞争条件。出于这个原因，我认为最好在持有锁的情况下发出信号；这样，您就知道设置条件和发送信号是相互关联的。

在相关说明中，您调用 testCondition 的方式不正确。 pthread_cond_wait() 有可能(虽然很少见)在没有实际发出条件变量的情况下返回，并且还有其他情况(例如，我上面描述的竞争)，即使条件不正确，信号也可能最终唤醒线程.为了安全起见，您需要将 pthread_cond_wait() 调用放在测试条件的 pthread_cond_wait() 循环中，以便在重新获取锁后如果条件不满足，则回调到 while()。在您的示例中，它看起来像这样:

pthread_mutex_lock(&my_lock);     
while ( false == testCondition ) {
    pthread_cond_wait(&my_wait,&my_lock);
}
pthread_mutex_unlock(&my_lock);

(我还更正了原始示例中可能是错字的内容，即在 pthread_cond_wait() 调用中使用 my_mutex 而不是 pthread_cond_wait() 。)