调用pthread_cond_wait与信号 [英] pthread_cond_wait versus semaphore

问题描述

什么是使用的优点/缺点调用pthread_cond_wait 或使用信号？
我等待这样的状态变化：

What are the pros / cons of using pthread_cond_wait or using a semaphore ? I am waiting for a state change like this :

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);

使用正确初始化信号，我想我能做到这一点是这样的：

Using a properly initialised semaphore, I think I could do it like this :

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

什么是每种方法的优点和缺点是什么？

What are the pros and cons of each method ?

推荐答案

一个信号是干净适合于生产者 - 消费者模式，虽然它有其他用途。你的程序逻辑是负责确保职位的权数为等待数发。如果您发布一个信号，没有人还等着它，然后当他们这样做，他们等待立即继续。如果您的问题是这样的，它可以在一个信号的计数值来解释，那么它应该是很容易用信号来解决。

A semaphore is suited cleanly to a producer-consumer model, although it has other uses. Your program logic is responsible for ensuring that the right number of posts are made for the number of waits. If you post a semaphore and nobody is waiting on it yet, then when they do wait they continue immediately. If your problem is such that it can be explained in terms of the count value of a semaphore, then it should be easy to solve with a semaphore.

一个条件变量是在某些方面更宽容一点。例如，您可以使用调用cond_broadcast唤醒所有的服务员，未经制作知道有多少。如果你cond_signal一个condvar上面有没有人在等待，然后什么也没有发生。这是好事，如果你不知道是否有将是一个有兴趣的听众。这也是为什么听者总是以等待之前举行的互斥检查状态 - 如果他们不那么他们可能会错过一个信号，并没有醒来，直到下一个（可能是永远）

A condition variable is a bit more forgiving in some respects. You can for example use cond_broadcast to wake up all waiters, without the producer knowing how many there are. And if you cond_signal a condvar with nobody waiting on it then nothing happens. This is good if you don't know whether there's going to be a listener interested. It is also why the listener should always check the state with the mutex held before waiting - if they don't then they can miss a signal and not wake up until the next one (which could be never).

因此​​，一个条件变量适合通知状态已更改有关各方：你获得互斥体，改变状态，信号（或广播）的condvar并释放互斥。如果这个描述你的问题，你在condvar领土。如果不同的听众有兴趣不同的状态可以只播出，他们将每个反过来醒来，弄清楚他们是否已找到自己想要的状态，如果不再次等待。

So a condition variable is suitable for notifying interested parties that state has changed: you acquire the mutex, change the state, signal (or broadcast) the condvar and release the mutex. If this describes your problem you're in condvar territory. If different listeners are interested in different states you can just broadcast and they'll each in turn wake up, figure out whether they've found the state they want, and if not wait again.

这是非常粗糙的确实尝试这样的事情用互斥锁和信号量。如果你想利用互斥体，检查一些状态，然后等待的信号更改的问题就来了。除非你能以原子释放互斥锁和信号量等待（在pthreads的，你不能），你最终等待的信号，同时持有互斥锁。这将阻止互斥体，这意味着其他人不能把它做你关心的变化。所以，你会受到诱惑再添互斥其中取决于您的特定需求的一种方式。也许另一个信号。其结果通常是不正确code有害的竞争条件。

It's very gnarly indeed to attempt this sort of thing with a mutex and a semaphore. The problem comes when you want to take the mutex, check some state, then wait on the semaphore for changes. Unless you can atomically release the mutex and wait on the semaphore (which in pthreads you can't), you end up waiting on the semaphore while holding the mutex. This blocks the mutex, meaning that others can't take it to make the change you care about. So you will be tempted to add another mutex in a way which depends on your specific requirements. And maybe another semaphore. The result is generally incorrect code with harmful race conditions.

条件变量逃避这个问题，因为自动调用cond_wait释放互斥体，释放它供他人使用。该互斥cond_wait返回之前恢复。

Condition variables escape this problem, because calling cond_wait automatically releases the mutex, freeing it for use by others. The mutex is regained before cond_wait returns.

IIRC有可能实现一种只使用信号量condvar的，但如果你实现去与condvar互斥体需要具有的tryLock，那么它是一个严重的头饼刷，并定时等待都出来了。不建议。所以，不要以为任何你可以用condvar可以用信号量来完成事情。另外当然互斥可以有信号灯缺乏很好的行为，主要是优先级反转回避。

IIRC it is possible to implement a kind of condvar using only semaphores, but if the mutex you're implementing to go with the condvar is required to have trylock, then it's a serious head-scratcher, and timed waits are out. Not recommended. So don't assume that anything you can do with a condvar can be done with semaphores. Plus of course mutexes can have nice behaviours that semaphores lack, principally priority-inversion avoidance.

这篇关于调用pthread_cond_wait与信号的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！