关于pthread_cond_signal与pthread_cond_broadcast的使用...

       在code review中，我会发现很多人喜欢在pthread_mutex_lock()和pthread_mutex_unlock(()之间调用 pthread_cond_signal或者pthread_cond_broadcast函数，从逻辑上来说，这种使用方法是完全正确的。但是在多线程环境中，这种使用方法可能是低效的。posix1标准说，pthread_cond_signal与pthread_cond_broadcast无需考虑调用线程是否是mutex的拥有者，也就是说，可以在lock与unlock以外的区域调用。如果我们对调用行为不关心，那么请在lock区域之外调用吧。这里举个例子：
       我们假设系统中有线程1和线程2，他们都想获取mutex后处理共享数据，再释放mutex。请看这种序列：
       1)线程1获取mutex，在进行数据处理的时候，线程2也想获取mutex，但是此时被线程1所占用，线程2进入休眠，等待mutex被释放。
       2)线程1做完数据处理后，调用pthread_cond_signal（）唤醒等待队列中某个线程，在本例中也就是线程2。线程1在调用pthread_mutex_unlock（）前，因为系统调度的原因，线程2获取使用CPU的权利，那么它就想要开始处理数据，但是在开始处理之前，mutex必须被获取，很遗憾，线程1正在使用mutex，所以线程2被迫再次进入休眠。
       3)然后就是线程1执行pthread_mutex_unlock（）后，线程2方能被再次唤醒。
       从这里看，使用的效率是比较低的，如果再多线程环境中，这种情况频繁发生的话，是一件比较痛苦的事情。所以觉得，如果程序不关心线程可预知的调度行为，那么最好在锁定区域以外调用他们。

对于
int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex);
int pthread_cond_timedwait(pthread_cond_t *cond, pthread_mutex_t *mutex, const struct timespec *abstime);
，一定要在mutex的锁定区域内使用。
如果要正确的使用pthread_mutex_lock与pthread_mutex_unlock，请参考
pthread_cleanup_push 和pthread_cleanup_pop宏，它能够在线程被cancel的时候正确的释放mutex！

        pthread_cond_wait()  用于阻塞当前线程，等待别的线程使用 pthread_cond_signal() 或 pthread_cond_broadcast来唤醒它 。  pthread_cond_wait()   必须与pthread_mutex 配套使用。 pthread_cond_wait() 函数一进入wait状态就会自动release mutex。当其他线程通过 pthread_cond_signal() 或 pthread_cond_broadcast ，把该线程唤醒，使 pthread_cond_wait()通过（返回）时，该线程又自动获得该 mutex 。

        pthread_cond_signal 函数的作用是发送一个信号给另外一个正在处于阻塞等待状态的线程,使其脱离阻塞状态,继续执行.如果没有线程处在阻塞等待状态,pthread_cond_signal也会成功返回。

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

        但是 pthread_cond_signal 在多处理器上可能同时唤醒多个线程，当你只能让一个线程处理某个任务时，其它被唤醒的线程就需要继续 wait，而且规范要求 pthread_cond_signal 至少唤醒一个pthread_cond_wait上的线程，其实有些实现为了简单在单处理器上也会唤醒多个线程. 

        另外，某些应用，如线程池， pthread_cond_broadcast 唤醒全部线程，但我们通常只需要一部分线程去做执行任务，所以其它的线程需要继续wait.

 

http://www.cppblog.com/fwxjj/archive/2010/05/22/116066.html

http://apps.hi.baidu.com/share/detail/19786281