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);
}
每种方法的优缺点是什么？
信号量完全适用于生产者-消费者模型，尽管它还有其他用途。您的程序逻辑负责确保根据等待次数发布正确数量的帖子。如果您发布信号量并且没有人在等待它，那么当他们等待时，他们会立即继续。如果您的问题可以用信号量的计数值来解释，那么使用信号量应该很容易解决。
条件变量在某些方面更加宽容。例如，您可以使用 cond_broadcast 唤醒所有服务员，而生产者不知道有多少服务员。如果你 cond_signal 一个没有人在等待它的 condvar，那么什么也不会发生。如果您不知道是否会有听众感兴趣，这很好。这也是为什么侦听器应始终在等待之前检查持有的互斥锁的状态 - 如果他们不这样做，那么他们可能会错过一个信号并且直到下一个信号才会醒来（可能永远不会）。
因此，条件变量适用于通知相关方状态已更改：您获取互斥锁、更改状态、发送信号（或广播）condvar 并释放互斥锁。如果这描述了您的问题，那么您就处于 condvar 领域。如果不同的听众对不同的状态感兴趣，你可以广播，他们会依次醒来，确定他们是否找到了他们想要的状态，如果没有，就再等。
用互斥锁和信号量尝试这种事情确实非常棘手。当您想要获取互斥体，检查某些状态，然后等待信号量进行更改时，问题就来了。除非您可以原子地释放互斥体并在信号量上等待（在 pthread 中您不能这样做），否则您最终会在持有互斥体的同时等待信号量。这会阻止互斥体，这意味着其他人无法接受它来进行您关心的更改。因此，您会很想以一种取决于您的特定要求的方式添加另一个互斥锁。也许另一个信号量。结果通常是带有有害竞争条件的错误代码。
条件变量避免了这个问题，因为调用 cond_wait 会自动释放互斥体，释放它以供其他人使用。在 cond_wait 返回之前重新获得互斥锁。
IIRC 可以仅使用信号量来实现一种 condvar，但是如果您要与 condvar 一起实现的互斥锁需要具有 trylock，那么这是一个严重的问题，并且定时等待已经结束。不建议。所以不要假设你可以用 condvar 做的任何事情都可以用信号量来完成。当然，互斥体可以具有信号量所缺乏的良好行为，主要是避免优先级反转。
条件允许你做一些信号量不会做的事情。
例如，假设您有一些需要互斥体的代码，称为m. 然而，它需要等到其他线程完成他们的任务，所以它等待一个名为s. 现在任何需要的线程都m被阻止运行，即使该线程m正在等待s。这些情况可以使用条件来解决。当您等待条件时，当前持有的互斥锁被释放，因此其他线程可以获取互斥锁。回到我们的例子，假设c使用条件而不是s. 我们的线程现在获取m，然后有条件地等待c。这将释放m，以便其他线程可以继续。当c可用时，m被重新获取，我们的原始线程可以继续愉快地前进。
条件变量还允许您让所有等待条件变量的线程通过pthread_cond_broadcast. 此外，它还允许您执行定时等待，这样您就不会永远等待。
当然，有时您不需要条件变量，因此根据您的要求，其中一个可能更好。
第二个片段是活泼的，不要那样做。
其他答案对相对优点进行了很好的讨论；我将补充一点，这pthread_cond_broadcast是条件变量的明显优势。
除此之外，我更习惯于为此设置条件变量，因为它们是您在 Java 中使用的，即使它们可以帮助您在检查共享标志时避免竞争。
实际上，在第二个片段中，您没有任何锁来保护 cam->status 的读取，因此它是通过数据竞争访问的。在这个特定的示例中，大多数平台都会让您摆脱这种情况，但是根据 POSIX 和下一个 C/C++ 标准的内存模型，它具有未定义的语义。
事实上，如果另一个线程分配了一个新的 cam 结构并覆盖了 cam，那么真正的竞争条件是可能的；等待线程可能会看到“cam”指针的更新，而没有看到 cam->status 的初始化。实际上，在这种情况下和一般情况下，第二个片段正在自找麻烦。
在您的第二个片段中，您多次获得锁定，从未释放它。
通常，您正在等待的状态可以完全由信号量表示，然后您就可以使用它。锁结构的大小更小，它需要更少的原子操作来检查/设置/释放。
否则，如果状态很复杂，并且代码的不同部分在同一变量的不同条件下等待（例如，这里你想要 x<10；那里你想要 y>x），请使用 cond_wait。
while(cam->status == WAIT_DISPLAY) {
sem_wait(&some_semaphore);
}
这是完全错误的。这很容易出现竞争条件。当线程在 sem_Wait 上阻塞时，条件 cam->status == WAIT_DISPLAY 可能无法在系统中保持良好状态，因为其他线程可能已对其进行了修改。因此，您的线程现在由于所有错误的原因而处于休眠状态。