pthread_cond_wait

原文出处：
http://hi.baidu.com/nkhzj/blog/item/f5480d4f740f7f35aec3ab4b.html

pthread_cond_wait()太难理解了

2007-11-01 19:44

了解 pthread_cond_wait() 的作用非常重要 -- 它是 POSIX 线程信号发送系统的核心，也是最难以理解的部分。

首先，让我们考虑以下情况：线程为查看已链接列表而锁定了互斥对象，然而该列表恰巧是空的。这一特定线程什么也干不了 -- 其设计意图是从列表中除去节点，但是现在却没有节点。因此，它只能：

锁定互斥对象时，线程将调用 pthread_cond_wait(&mycond,&mymutex)。pthread_cond_wait() 调用相当复杂，因此我们每次只执行它的一个操作。

pthread_cond_wait() 所做的第一件事就是同时对互斥对象解锁（于是其它线程可以修改已链接列表），并等待条件 mycond 发生（这样当 pthread_cond_wait() 接收到另一个线程的“信号”时，它将苏醒）。现在互斥对象已被解锁，其它线程可以访问和修改已链接列表，可能还会添加项。 【要求解锁并阻塞是一个原子操作】

此时，pthread_cond_wait() 调用还未返回。对互斥对象解锁会立即发生，但等待条件 mycond 通常是一个阻塞操作，这意味着线程将睡眠，在它苏醒之前不会消耗 CPU 周期。这正是我们期待发生的情况。线程将一直睡眠，直到特定条件发生，在这期间不会发生任何浪费 CPU 时间的繁忙查询。从线程的角度来看，它只是在等待 pthread_cond_wait() 调用返回。

现在继续说明，假设另一个线程（称作“2 号线程”）锁定了 mymutex 并对已链接列表添加了一项。在对互斥对象解锁之后，2 号线程会立即调用函数 pthread_cond_broadcast(&mycond)。此操作之后，2 号线程将使所有等待 mycond 条件变量的线程立即苏醒。这意味着第一个线程（仍处于 pthread_cond_wait() 调用中）现在将苏醒。

现在，看一下第一个线程发生了什么。您可能会认为在 2 号线程调用 pthread_cond_broadcast(&mymutex) 之后，1 号线程的 pthread_cond_wait() 会立即返回。不是那样！实际上，pthread_cond_wait() 将执行最后一个操作：重新锁定 mymutex。一旦 pthread_cond_wait() 锁定了互斥对象，那么它将返回并允许 1 号线程继续执行。那时，它可以马上检查列表，查看它所感兴趣的更改。

停止并回顾！
那个过程非常复杂，因此让我们先来回顾一下。第一个线程首先调用：



pthread_mutex_lock(&mymutex);




然后，它检查了列表。没有找到感兴趣的东西，于是它调用：



pthread_cond_wait(&mycond, &mymutex);




然后，pthread_cond_wait() 调用在返回前执行许多操作：



pthread_mutex_unlock(&mymutex);




它对 mymutex 解锁，然后进入睡眠状态，等待 mycond 以接收 POSIX 线程“信号”。一旦接收到“信号”（加引号是因为我们并不是在讨论传统的 UNIX 信号，而是来自 pthread_cond_signal() 或 pthread_cond_broadcast() 调用的信号），它就会苏醒。但 pthread_cond_wait() 没有立即返回 -- 它还要做一件事：重新锁定 mutex：



pthread_mutex_lock(&mymutex);




pthread_cond_wait() 知道我们在查找 mymutex “背后”的变化，因此它继续操作，为我们锁定互斥对象，然后才返回。



原文出处
http://tower.iteye.com/blog/309294

一般来说，在多线程竞争一个资源的时候，会用到pthread_cond_wait,pthread_cond_signal机制，典型的 做法就是在一个使用这个资源的线程（消费者）里面，判断资源如果不可用的话，则pthread_cond_wait,在另外一个线程（生产者）中判断如果 资源可用的话，则发一个pthread_cond_signal或者pthread_cond_broadcast通知wait的线程。

 

但是有一个问题，就是在wait成功后，实际上此时的资源是否就一定可用呢？答案是否定的，如果存在两个线程同时使用这个资源的话，wait返回后，有可能资源已经被使用了。所以在这种情况下，判断资源是否可用，应该用如下模型：

 

while (resource==TRUE)       

{               

           pthread_cond_wait( &COND, &MUTEX);          

}

 

这里用了while，而不是用if，原因就是上面提到的。当然，如果在应用中，只有一个消费者，就可以直接用if了。 要搞清楚这个问题背后的问题，就需要知道pthread_cond_wait的实际过程。 当发起一个pthread_cond_wait之后，分解后，实际上是三个动作：    

1、解锁    

2、等待 当收到一个解除等待的信号（pthread_cond_signal或者pthread_cond_broad_cast）之后，pthread_cond_wait马上需要做的动作是：    

3、上锁

 

了解这个原理后，假设出现如下场景：如果消费者A的wait在收到解除信号后，去上锁，但是这个时候，被消费者B先上锁，把资源使用掉了，然后解锁，然后消费者A上锁成功，wait返回，而此时资源已经不可用了，所以消费者A必须在判断一下资源的可用性。