48

pthread_cond_wait使用或使用信号量的优点/缺点是什么?我正在等待这样的状态变化:

pthread_mutex_lock(&cam->video_lock);
while(cam->status == WAIT_DISPLAY) {
    pthread_cond_wait(&cam->video_cond, &cam->video_lock);
}
pthread_mutex_unlock(&cam->video_lock);

使用正确初始化的信号量,我想我可以这样做:

while(cam->status == WAIT_DISPLAY) {
    sem_wait(&some_semaphore);
}

每种方法的优缺点是什么?

4

5 回答 5

65

信号量完全适用于生产者-消费者模型,尽管它还有其他用途。您的程序逻辑负责确保根据等待次数发布正确数量的帖子。如果您发布信号量并且没有人在等待它,那么当他们等待时,他们会立即继续。如果您的问题可以用信号量的计数值来解释,那么使用信号量应该很容易解决。

条件变量在某些方面更加宽容。例如,您可以使用 cond_broadcast 唤醒所有服务员,而生产者不知道有多少服务员。如果你 cond_signal 一个没有人在等待它的 condvar,那么什么也不会发生。如果您不知道是否会有听众感兴趣,这很好。这也是为什么侦听器应始终在等待之前检查持有的互斥锁的状态 - 如果他们不这样做,那么他们可能会错过一个信号并且直到下一个信号才会醒来(可能永远不会)。

因此,条件变量适用于通知相关方状态已更改:您获取互斥锁、更改状态、发送信号(或广播)condvar 并释放互斥锁。如果这描述了您的问题,那么您就处于 condvar 领域。如果不同的听众对不同的状态感兴趣,你可以广播,他们会依次醒来,确定他们是否找到了他们想要的状态,如果没有,就再等。

用互斥锁和信号量尝试这种事情确实非常棘手。当您想要获取互斥体,检查某些状态,然后等待信号量进行更改时,问题就来了。除非您可以原子地释放互斥体并在信号量上等待(在 pthread 中您不能这样做),否则您最终会在持有互斥体的同时等待信号量。这会阻止互斥体,这意味着其他人无法接受它来进行您关心的更改。因此,您会很想以一种取决于您的特定要求的方式添加另一个互斥锁。也许另一个信号量。结果通常是带有有害竞争条件的错误代码。

条件变量避免了这个问题,因为调用 cond_wait 会自动释放互斥体,释放它以供其他人使用。在 cond_wait 返回之前重新获得互斥锁。

IIRC 可以仅使用信号量来实现一种 condvar,但是如果您要与 condvar 一起实现的互斥锁需要具有 trylock,那么这是一个严重的问题,并且定时等待已经结束。不建议。所以不要假设你可以用 condvar 做的任何事情都可以用信号量来完成。当然,互斥体可以具有信号量所缺乏的良好行为,主要是避免优先级反转。

于 2008-09-20T18:21:54.963 回答
20

条件允许你做一些信号量不会做的事情。

例如,假设您有一些需要互斥体的代码,称为m. 然而,它需要等到其他线程完成他们的任务,所以它等待一个名为s. 现在任何需要的线程都m被阻止运行,即使该线程m正在等待s。这些情况可以使用条件来解决。当您等待条件时,当前持有的互斥锁被释放,因此其他线程可以获取互斥锁。回到我们的例子,假设c使用条件而不是s. 我们的线程现在获取m,然后有条件地等待c。这将释放m,以便其他线程可以继续。当c可用时,m被重新获取,我们的原始线程可以继续愉快地前进。

条件变量还允许您让所有等待条件变量的线程通过pthread_cond_broadcast. 此外,它还允许您执行定时等待,这样您就不会永远等待。

当然,有时您不需要条件变量,因此根据您的要求,其中一个可能更好。

于 2008-09-16T11:15:15.233 回答
5

第二个片段是活泼的,不要那样做。

其他答案对相对优点进行了很好的讨论;我将补充一点,这pthread_cond_broadcast是条件变量的明显优势。

除此之外,我更习惯于为此设置条件变量,因为它们是您在 Java 中使用的,即使它们可以帮助您在检查共享标志时避免竞争。

实际上,在第二个片段中,您没有任何锁来保护 cam->status 的读取,因此它是通过数据竞争访问的。在这个特定的示例中,大多数平台都会让您摆脱这种情况,但是根据 POSIX 和下一个 C/C++ 标准的内存模型,它具有未定义的语义。

事实上,如果另一个线程分配了一个新的 cam 结构并覆盖了 cam,那么真正的竞争条件是可能的;等待线程可能会看到“cam”指针的更新,而没有看到 cam->status 的初始化。实际上,在这种情况下和一般情况下,第二个片段正在自找麻烦。

http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/

于 2009-01-12T09:11:45.853 回答
0

在您的第二个片段中,您多次获得锁定,从未释放它。

通常,您正在等待的状态可以完全由信号量表示,然后您就可以使用它。锁结构的大小更小,它需要更少的原子操作来检查/设置/释放。

否则,如果状态很复杂,并且代码的不同部分在同一变量的不同条件下等待(例如,这里你想要 x<10;那里你想要 y>x),请使用 cond_wait。

于 2008-09-16T10:10:46.403 回答
0
while(cam->status == WAIT_DISPLAY) {
    sem_wait(&some_semaphore);
}

这是完全错误的。这很容易出现竞争条件。当线程在 sem_Wait 上阻塞时,条件 cam->status == WAIT_DISPLAY 可能无法在系统中保持良好状态,因为其他线程可能已对其进行了修改。因此,您的线程现在由于所有错误的原因而处于休眠状态。

于 2022-02-28T06:40:00.257 回答