但使用pthread_cond_signal不会有“惊群现象”产生，他最多只给一个执行绪发信号。假如有多个执行绪正在阻塞等待着这个条件变数的话，那幺是根据各等待执行绪优先权的高低确定哪个执行绪接收到信号开始继续执行。如果各执行绪优先权相同，则根据等待时间的长短来确定哪个执行绪获得信号。但无论如何一个pthread_cond_signal调用最多发信一次。

另外，互斥量的作用一般是用于对某个资源进行互斥性的存取,很多时候是用来保证操作是一个原子性的操作，是不可中断的。

pthread_cond_wait必须放在pthread_mutex_lock和pthread_mutex_unlock之间，因为他要根据共享变数的状态来决定是否要等待，而为了不永远等待下去所以必须要在lock/unlock队中

共享变数的状态改变必须遵守lock/unlock的规则

pthread_cond_signal即可以放在pthread_mutex_lock和pthread_mutex_unlock之间，也可以放在pthread_mutex_lock和pthread_mutex_unlock之后，但是各有优缺点。

pthread_mutex_lock

xxxxxxx

pthread_cond_signal

pthread_mutex_unlock

缺点：在某些执行绪的实现中，会造成等待执行绪从核心中唤醒（由于cond_signal)然后又回到核心空间（因为cond_wait返回后会有原子加锁的行为），所以一来一回会有性能的问题。但是在LinuxThreads或者NPTL里面，就不会有这个问题，因为在Linux 执行绪中，有两个伫列，分别是cond_wait伫列和mutex_lock伫列， cond_signal只是让执行绪从cond_wait伫列移到mutex_lock伫列，而不用返回到用户空间，不会有性能的损耗。

所以在Linux中推荐使用这种模式。

pthread_mutex_lock

xxxxxxx

pthread_mutex_unlock

pthread_cond_signal

优点：不会出现之前说的那个潜在的性能损耗，因为在signal之前就已经释放锁了

缺点：如果unlock和signal之前，有个低优先权的执行绪正在mutex上等待的话，那幺这个低优先权的执行绪就会抢占高优先权的执行绪（cond_wait的执行绪)，而这在上面的放中间的模式下是不会出现的。

所以，在Linux下最好pthread_cond_signal放中间，但从编程规则上说，其他两种都可以