假设某个条件变量“cond”与一个互斥变量“mutex”关联。如果一个线程在调用pthread_cond_wait(&cond,&mutex)之后正在睡眠cond，并且锁定的另一个线程完成锁定，那么在调用pthread_mutex_unlock(&mutex)之前还是之后，该线程调用pthread_cond_signal(&cond)是否有关系？如果它调用pthread_cond_signal(&cond)，它甚至需要解锁互斥锁，因为睡眠线程无论如何都会获取互斥锁？发送条件变量（pthreads）
编辑：根据https://computing.llnl.gov/tutorials/pthreads/#ConVarOverview，“在调用pthread_cond_signal（）后未能解锁互斥锁可能无法完成匹配的pthread_cond_wait（）例程（它将保持阻塞状态）。”我想那时候，解锁，也许只有在之后，才是必需的。
调用pthread_cond_signal之后，您应该始终解锁互斥锁。这里有一些很好的问题/解答阅读：
Calling pthread_cond_signal without locking mutex
它不会来找我的权利，但我敢肯定有，你不要一个很好的理由（在比赛条件而言）在发送信号之前，您想解锁互斥锁。
如果在发信号通知条件变量并解锁互斥锁之后，线程会立即在该互斥锁上调用'pthread_mutex_lock（）'，它是否保证不会饿死先前由'pthread_cond_signal（）'唤醒的线程？ – ManRow 2011-03-03 03:45:13
@ManRow：如果设置了正确的优先级，那么Priority Scheduling选项中可能会有这样的保证。否则，绝对不是。 – 2011-03-03 03:53:00
好的原因是避免优先级倒置：http://groups.google.com/group/comp.programming.threads/msg/a3721a2fc9b21c64?hl=ky从http://stackoverflow.com/questions/4544234/calling-并行线程-COND - 信号 - 不锁定-互斥/ 4544494＃4544494 – ninjalj 2011-03-15 23:43:46
如果保持互斥锁定，则被唤醒的线程无法获取互斥锁，因此将在pthread_cond_wait中等待重新获取互斥锁。
您不需要锁定互斥锁就可以调用pthread_cond_signal。事实上，如果您的应用程序逻辑可以在互斥锁未锁定的情况下使用信号，那么这是一种更好的方法 - 操作系统可以立即安排等待的线程，并且不必等待信号在继续之前解锁互斥体。
但是，在这种情况下，必须注意确保唤醒不会丢失，并且您不会遇到“错误”线程被唤醒的问题。如果你使用直接谓词，这在实践中应该不成问题。
+1回答你自己的问题。 – 2011-03-03 01:44:46