在Stevens的《Unix 环境高级编程》中第11章线程关于pthread_cond_wait的介绍中有一个生产者-消费者的例子P311,
在进入pthread_cond_wait前使用while进行条件判断,而没有直接使用if,耐人费解!编程
代码以下: #include <pthread.h> struct msg { struct msg *m_next; /* value...*/ }; struct msg* workq; pthread_cond_t qready = PTHREAD_COND_INITIALIZER; pthread_mutex_t qlock = PTHREAD_MUTEX_INITIALIZER; void process_msg() { struct msg* mp; for (;;) { pthread_mutex_lock(&qlock); while (workq == NULL) { pthread_cond_wait(&qread, &qlock); } mq = workq; workq = mp->m_next; pthread_mutex_unlock(&qlock); /* now process the message mp */ } } void enqueue_msg(struct msg* mp) { pthread_mutex_lock(&qlock); mp->m_next = workq; workq = mp; pthread_mutex_unlock(&qlock); /** 此时另一个线程在signal以前,执行了process_msg,恰好把mp元素拿走*/ pthread_cond_signal(&qready); /** 此时执行signal, 在pthread_cond_wait等待的线程被唤醒, 可是mp元素已经被另一个线程拿走,因此,workq仍是NULL ,所以须要继续等待*/ }
这里process_msg至关于消费者,enqueue_msg至关于生产者,struct msg* workq做为缓冲队列
的线程,会出现上述注释出现的状况,形成workq==NULL,所以须要继续等待。函数
可是若是将pthread_cond_signal移到pthread_mutex_unlock()以前执行,则会避免这种竞争,在unlockspa
以后,会首先唤醒pthread_cond_wait的线程,进而workq!=NULL老是成立。.net
pthread_cond_wait返回时没法保证判断式是真是假,所以须要从新判断。所以建议使用while循环进行验证,以便可以容忍这种竞争。线程
http://yaronspace.cn/blog/archives/1479code
还有一种解释以下所示blog
http://bbs.csdn.net/topics/370094313队列
我猜应该是这个意思:
假设有两个线程(我就用伪代码了):
//thread 1
while(0<x<10)
pthread_cond_wait();
//thread 2
while(5<x<15)
pthread_cond_wait();
若是某段时间内 x == 8,那么两个线程相继进入等待。
而后,另外一个线程3:
修改x:x = 12
if(..) phtread_cond_signal()
那么,虽然线程一、2都被唤醒了,可是,此时线程1仍然不知足while,只有线程1跳出while,
咱们假设一种状况线程2线得到了锁,而后发现知足循环条件,以后又有执行pthread_cond_wait()函数,而后阻塞在这儿,而且释放锁!
1,pthread_cond_signal在多处理器上可能同时唤醒多个线程,当你只能让一个线程处理某个任务时,其它被唤醒的线程就须要继续wait,while循环的意义就体如今这里了,并且规范要求pt hread_cond_signal至少唤醒一个pthread_cond_wait上的线程,其实有些实现为了简单在单处理器上也会唤醒多个线程. 2,某些应用,如线程池,pthread_cond_broadcast唤醒所有线程,但咱们一般只须要一部分线程去作执行任务,因此其它的线程须要继续wait.因此强烈推荐此处使用while循环. 其实说白了很简单,就是pthread_cond_signal()也可能唤醒多个线程,而若是你同时只容许一个线程访问的话,就必需要使用while来进行条件判断,以保证临界区内只有一个线程在处理