futex-based pthread_cond 源代码分析
pthread_cond的实现使用了几个futex来协同进行同步，以及如何来实现的。
假定你已经明白 futex，futex-requeue，以及 pthread lowlevellock。
《linux 内核的futex - requeue 以及 requeue-pi》
pthread_cond一共使用了4个futex，其中包括1个外部的futex，是它所从属的Mutex。
pthread_cond自身包含的3个futex：
__lock：是一个lowlevellock用于pthread_cond原语操作在用户空间的临界区保护（或同步），同时保护pthread_cond的其它变量。
__futex：这是我们所熟知的条件变量阻塞队列。
__nwaiters：用作变量监视器，pthread_cond在destroy使用来同步所有没结束的wait。
这里可以看到futex除了锁之外另一种用法，用户空间可以阻塞在__nwaiters变量上，以Observer角色等待修改的一方发出更新的信号。pthread_cond_destroy会一直阻塞/唤醒监视__nwaiters，直到__nwaiters等于0为止。
pthread_cond_wait就是先后阻塞在__futex和__mutex.__lock两个futex队列进行等待，也就是futex_requeue系统调用中的futex1与futex2。pthread_cond_broadcast使用futex_requeue将__futex上的阻塞线程requeue到__mutex.__lock的等待队列上。
__total_seq 是 cond_wait调用的次序号。
__nwaiters 是 阻塞中的cond_wait的计数。
__wakeup_seq 是 发起唤醒的次序号，包括cond_signal 以及 cond_wait的timeout。
__broadcast_seq 是 cond_broadcast调用的次序号。
__woken_seq 是 cond_wait从阻塞中被唤醒的次序号。
__futex 是发起wakeup或wait的动作次序号。
规则：
__futex 在 __total_seq 和 __total_seq * 2 之间推进。__futex 为 __total_seq 和 __wakeup_seq 之和。
__total_seq 先于 __wakeup_seq 向前推进。每次wait调用使__total_seq向前推进1。后随的wakeup才能使__wakeup_seq向前推进。
__wakeup_seq 先于 __woken_seq 向前推进。wait被唤醒后将__woken_seq向前推进1，结束一次wait。
__broadcast_seq，独立的调用次序。每次broadcast，都会将__wakeup_seq，__wokenup_seq，以及__futex平衡，根据 __total_seq。
__nwaiters 未结束的 wait 调用，destroy 必须监视这个值，同步到这个值等于0才能安全进行销毁。
只有当__total_seq 不等于 __wakeup_seq 时，才能进行 signal 或 broadcast 。
当wait发现__futex这个参考次序号有变动，回到用户空间去调查情况：
1. 发现__wakeup_seq次序号有变动，即表明此时有signal调用，就可以与signal所唤醒的waiter进行竞争，竞争同步在用户空间临界区。如果__wakeup_seq != __woken_seq表明自己可以获得这次通行，如果__wakeup_seq == __woken_seq表示这次通行已经被某个waiter拔得头筹，只能决定再进内核排队。
2. 发现__broadcast_seq次序号有变动，即表明自身正包含在broadcast当中（自己修改的__total_seq，被broadcast采纳），可以不再进入内核排队，而直接获得通行。
wait都是三心两意的，一发现__futex有推进，就先打消排队的意愿，怀着被broadcast选中或幸运抢占到一次signal带来的机会，转头回到用户空间张望一下，没戏才失望地再次进入内核排队，但在排队前还是不死心。
下面来看pthread_cond_wait，pthread_cond_signal，以及pthread_cond_broadcast是如何在用户空间临界区同步的：
红色框：__lock保护的用户空间临界区。
紫色框：futex系统调用。
这里可以看到signal是全过程排他（mutual exclusion）进行的。而wait和broadcast则是用户空间和内核（系统调用）分开进行临界区同步的，它们在用户空间的代码只在用户空间的临界区同步，系统调用可以并发进行，当然也不是完全并发，在内核中系统调用的执行还是会同步进行的。换个说法，系统调用并不阻塞其它线程在用户空间在代码，一些线程阻塞在用户空间的临界区，不影响另一些线程去进行系统调用。
broadcast在唤醒线程时，是不会阻塞其它线程去调用wait的。但是signal 即使进入内核去唤醒线程时，也得阻塞其它线程去调用condvar的函数。
broadcast 与 broadcast 并发：
broadcast与broadcast同时调用，同步在用户空间临界区次序后面的broadcast，因为__total_seq == __wakeup_seq而退出，只有同步在用户临界区的第一个broadcast会继续单独执行。
signal 与 wait 和 broadcast 并发：
当signal调用时，可能有前面的wait或broadcast刚进入内核，但在signal结束之前，不允许任何用户空间的调用进入临界区。这情况下，前面的wait必须回到用户空间重新进入临界区，在signal调用完全结束之后，才能再次进入内核。
a. signal调用在broadcast执行期间，signal会因为__total_seq == __wakeup_seq而退出。
b. broadcast调用在signal执行期间，只能阻塞在用户空间临界区，等待signal调用结束。
c. signal调用时，前面已经有wait在执行，signal会将未能在内核临界区排队的wait全部延后，原理是，wait在内核临界区发现futex有变，即表明用户空间层有变动，必须先回到用户空间，延后次序再次进入内核。
d. wait调用在signal执行期间，wait只能阻塞在用户空间临界区，等待signal调用结束。
broadcast 与 wait 并发：
broadcast与wait同时调用，wait都会回到用户空间，检查自身是否包含在本次broadcast中，同步在用户空间临界区，先于broadcast的wait被包含在broadcast，后面的wait则排除在外。包含在本次broadcast中的wait则可以不用在内核排队而直接获得通行。
其它同步或锁的还有
《linux 内核的spinlock如何实现排队》
《linux 内核的各种futex功能》
《linux 内核的rt_mutex (realtime互斥体)》
《linux 内核的futex pi-support，即pi-futex使用rt_mutex委托》
