Linux条件变量pthread_condition细节（为何先加锁，pthread_cond_wait为何先解锁，返回时又加锁）

---

本文目的

 
  首先说明，本文重点不在怎么用条件变量。这里我先列出 apue 中对于pthread_cond_wait函数的这么一段话：

• “ 调用者把锁住的互斥量传给函数，函数然后自动把调用线程放到等待条件的线程列表上，**对互斥量解锁。**这就关闭了条件检查和线程进入休眠状态等待条件改变这两个操作之间的时间通道，这样线程就不会错过条件的任何变化。pthread_cond_wait返回时，互斥量再次被锁住。”

  这段话的信息量很大，其中关于互斥量的操作可以理解为以下三个点：

1. 调用pthread_cond_wait前需要先对互斥量mutex上锁，才能把&mutex传入pthread_cond_wait函数
2. 在pthread_cond_wait函数内部，会首先对传入的mutex解锁
3. 当等待的条件到来后，pthread_cond_wait函数内部在返回前会去锁住传入的mutex

  我当时看到这里，各种疑问，传入前为何要锁，传入后为何要释放，返回时又为何再次锁？

本文就这三个问题进行详细解释。不过在此之前，我们需要了解为什么要有条件变量。即条件变量的作用。

---

为何需要条件变量

 
  如果没有条件变量，那么我们等待一个条件满足则会是下面这样的模型：

  首先加锁进入临界区去查看条件是否满足，不满足则解锁离开临界区，睡眠一段时间再继续循环判断。在这种情况下如果刚离开临界区，条件变为满足，那么线程必须还要等一段时间重新进入临界区才能知道条件满足（如果在这段时间内，条件依旧一直保持满足的话），如果这一小段时间条件又变为不满足，那么这个线程还要继续循环判断。不断地加锁解锁（会影响使用同一把锁的其他线程），还不能第一时间收到条件满足。这种模型既费时又开销大。

  所以条件变量的产生，正是为了不循环加锁解锁，并且第一时间收到条件满足的通知。

---

三个问题

 
  要回答那三个问题，那么首先需要明白 等待与唤醒的配合。

  下图是我参考其他人的图（原图有误）更正后所画的。其实这个图就能解释那三个问题：pthread_cond_wait传入前为何要锁，传入后为何先解锁，以及返回前为何再锁。不过我还是详细解释一下。

  图中有一个关键点，就是判断条件是否满足，是在调用pthread_cond_wait之前，上锁之后，就是说pthread_cond_wait不具备判断条件的能力，需要我们在外部写判断语句。

1. 条件不满足时，才会进入pthread_cond_wait