条件变量与虚假唤醒

1. 相关函数                                                                                         
       #include
       pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
       int    pthread_cond_init(pthread_cond_t    *cond,    pthread_condattr_t
       *cond_attr);
       int pthread_cond_signal(pthread_cond_t *cond);
       int pthread_cond_broadcast(pthread_cond_t *cond);
       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);

       int pthread_cond_destroy(pthread_cond_t *cond);

2. 说明
    条件变量是一种同步机制，允许线程挂起，直到共享数据上的某些条件得到满足。条件变量上的基本操作有：触发条件(当条件变为 true 时)；等待条件，挂起线程直到其他线程触发条件。
    条件变量要和互斥量相联结，以避免出现条件竞争－－一个线程预备等待一个条件变量，当它在真正进入等待之前，另一个线程恰好触发了该条件。
    pthread_cond_init 使用 cond_attr 指定的属性初始化条件变量 cond，当 cond_attr 为 NULL 时，使用缺省的属性。LinuxThreads 实现条件变量不支持属性，因此 cond_attr 参数实际被忽略。
    pthread_cond_t 类型的变量也可以用 PTHREAD_COND_INITIALIZER 常量进行静态初始化。                                                                                          
    pthread_cond_signal 使在条件变量上等待的线程中的一个线程重新开始。如果没有等待的线程，则什么也不做。如果有多个线程在等待该条件，只有一个能重启动，但不能指定哪一个。
    pthread_cond_broadcast 重启动等待该条件变量的所有线程。如果没有等待的线程，则什么也不做。
    pthread_cond_wait 自动解锁互斥量(如同执行了 pthread_unlock_mutex)，并等待条件变量触发。这时线程挂起，不占用 CPU 时间，直到条件变量被触发。在调用 pthread_cond_wait 之前，应用程序必须加锁互斥量。pthread_cond_wait 函数返回前，自动重新对互斥量加锁(如同执行了 pthread_lock_mutex)。
    互斥量的解锁和在条件变量上挂起都是自动进行的。因此，在条件变量被触发前，如果所有的线程都要对互斥量加锁，这种机制可保证在线程加锁互斥量和进入等待条件变量期间，条件变量不被触发。
    pthread_cond_timedwait 和 pthread_cond_wait 一样，自动解锁互斥量及等待条件变量，但它还限定了等待时间。如果在 abstime 指定的时间内 cond 未触发，互斥量 mutex 被重新加锁，且 pthread_cond_timedwait 返回错误 ETIMEDOUT。abstime 参数指定一个绝对时间，时间原点与 time 和 gettimeofday 相同：abstime = 0 表示 1970 年 1 月 1 日 00:00:00 GMT。
    pthread_cond_destroy 销毁一个条件变量，释放它拥有的资源。进入 pthread_cond_destroy 之前，必须没有在该条件变量上等待的线程。在 LinuxThreads 的实现中，条件变量不联结资源，除检查有没有等待的线程外，pthread_cond_destroy 实际上什么也不做。

3. 取消
pthread_cond_wait 和 pthread_cond_timedwait 是取消点。如果一个线程在这些函数上挂起时被取消，线程立即继续执行，然后再次对 pthread_cond_wait 和 pthread_cond_timedwait 在 mutex 参数加锁，最后执行取消。因此，当调用清除处理程序时，可确保，mutex 是加锁的。
4. 异步信号安全(Async-signal Safety)
条件变量函数不是异步信号安全的，不应当在信号处理程序中进行调用。特别要注意，如果在信号处理程序中调用 pthread_cond_signal 或 pthread_cond_boardcast 函数，可能导致调用线程死锁。

5. 返回值
在执行成功时，所有条件变量函数都返回 0，错误时返回非零的错误代码。
6. 错误代码
pthread_cond_init, pthread_cond_signal, pthread_cond_broadcast, 和 pthread_cond_wait 从不返回错误代码。
pthread_cond_timedwait 函数出错时返回下列错误代码：
ETIMEDOUT abstime 指定的时间超时时，条件变量未触发
EINTR pthread_cond_timedwait 被触发中断
pthread_cond_destroy 函数出错时返回下列错误代码：
EBUSY 某些线程正在等待该条件变量
7. 举例
设有两个共享的变量 x 和 y，通过互斥量 mut 保护，当 x > y 时，条件变量 cond 被触发。
int x,y;
int x,y;
pthread_mutex_t mut = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;

等待直到 x > y 的执行流程：
pthread_mutex_lock(&mut);
while (x <= y) {
pthread_cond_wait(&cond, &mut);
}
/* 对 x、y 进行操作 */
pthread_mutex_unlock(&mut);

对 x 和 y 的修改可能导致 x > y，应当触发条件变量：
pthread_mutex_lock(&mut);
/* 修改 x、y */
if (x > y) pthread_cond_broadcast(&cond);
pthread_mutex_unlock(&mut);

如果能够确定最多只有一个等待线程需要被唤醒(例如，如果只有两个线程通过 x、y 通信)，则使用 pthread_cond_signal 比 pthread_cond_broadcast 效率稍高一些。如果不能确定，应当用 pthread_cond_broadcast。
要等待在 5 秒内 x > y，这样处理：

struct timeval now;
struct timespec timeout;
int retcode;

pthread_mutex_lock(&mut);
gettimeofday(&now);
timeout.tv_sec = now.tv_sec + 5;
timeout.tv_nsec = now.tv_usec * 1000;
retcode = 0;
while (x <= y && retcode != ETIMEDOUT) {
retcode = pthread_cond_timedwait(&cond, &mut, &timeout);
}
if (retcode == ETIMEDOUT) {
/* 发生超时 */
} else {
/* 操作 x 和 y */
}
pthread_mutex_unlock(&mut);

虚假唤醒：

最近在温习pthread的时候，忽然发现以前对pthread_cond_wait的了解太肤浅了。昨晚在看《Programming With POSIX Threads》的时候，看到了pthread_cond_wait的通常使用方法：

pthread_mutex_lock();

while(condition_is_false)

pthread_cond_wait();

pthread_mutex_unlock();

为什么在pthread_cond_wait()前要加一个while循环来判断条件是否为假呢？

APUE中写道:

传递给pthread_cond_wait的互斥量对条件进行保护，调用者把锁住的互斥量传给函数。函数把调用线程放到等待条件的线程列表上，然后对互斥量解锁，这两个操作是原子操作。

线程释放互斥量，等待其他线程发给该条件变量的信号（唤醒一个等待者）或广播该条件变量（唤醒所有等待者）。当等待条件变量时，互斥量必须始终为释放的，这样其他线程才有机会锁住互斥量，修改条件变量。当线程从条件变量等待中醒来时，它重新继续锁住互斥量，对临界资源进行处理。

条件变量的作用是发信号，而不是互斥。

wait前检查

对于多线程程序，不能够用常规串行的思路来思考它们，因为它们是完全异步的，会出现很多临界情况。比如：pthread_cond_signal的时间早于pthread_cond_wait的时间，这样pthread_cond_wait就会一直等下去，漏掉了之前的条件变化。

对于这种情况，解决的方法是在锁住互斥量之后和等待条件变量之前，检查条件变量是否已经发生变化。

if(condition_is_false)

pthread_cond_wait();

这样在等待条件变量前检查一下条件变量的值，如果条件变量已经发生了变化，那么就没有必要进行等待了，可以直接进行处理。这种方法在并发系统中比较常见，例如之前PACKET_MMAP中poll的竞争条件的解决方法。

-----------------------------------------------------------------------

忽然想起了设计模式中的单件模式的"双重检查加锁"：

Singleton *getInstance()

{

if(ptr==NULL)

{

LOCK();

if(ptr==NULL)

{

ptr = new Singleton();

}

UNLOCK();

}

return ptr;

}

这样只有在第一次的时候会进行锁(应该是第一轮，如果刚开始有多个线程进入了最上层的ptr==NULL代码块，就会有多次锁，只不过之后就不会锁了)，之后就不会锁了。

pthread_once()的实现也是基于单件模式的。

pthread_once函数首先检查控制变量，以判断是否已经完成初始化。如果完成，pthread_once简单的返回；否则，pthread_once调用初始化函数(没有参数)，并记录下初始化被完成。如果在一个线程初始化时，另外的线程调用pthread_once，则调用线程将等待，直到那个线程完成初始化后返回。换句话，当调用pthread_once成功返回时，调用者能够肯定所有的状态已经初始化完毕。

int

__pthread_once (once_control, init_routine)

pthread_once_t *once_control;

void (*init_routine) (void);

{

/* XXX Depending on whether the LOCK_IN_ONCE_T is defined use a

global lock variable or one which is part of the pthread_once_t

object. */

if (*once_control == PTHREAD_ONCE_INIT)

{

lll_lock (once_lock, LLL_PRIVATE);

/* XXX This implementation is not complete. It doesn't take

cancelation and fork into account. */

if (*once_control == PTHREAD_ONCE_INIT)

{

init_routine ();

*once_control = !PTHREAD_ONCE_INIT;

}

lll_unlock (once_lock, LLL_PRIVATE);

}

return 0;

}

-----------------------------------------------------------------------

pthread_cond_wait中的while()不仅仅在等待条件变量前检查条件变量，实际上在等待条件变量后也检查条件变量。pthread_cond_wait返回后，还需要检查条件变量，这是为什么呢？难道pthread_cond_wait不是pthread_cond_signal触发了某个condition导致的吗？

这个地方有些迷惑人，实际上pthread_cond_wait的返回不仅仅是pthread_cond_signal和pthread_cond_broadcast导致的，还会有一些假唤醒，也就是spurious wakeup。

何为假唤醒？顾名思义就是虚假的唤醒，与pthread_cond_signal和pthread_cond_broadcast的唤醒相对。那么什么情况下会导致假唤醒呢？可以阅读参考1。

signal

大致意思是：

在linux中，pthread_cond_wait底层是futex系统调用。在linux中，任何慢速的阻塞的系统调用当接收到信号的时候，就会返回-1，并且设置errno为EINTR。在系统调用返回前，用户程序注册的信号处理函数会被调用处理。



注:什么有样的系统调用会出现接收信号后发挥EINTR呢？

慢速阻塞的系统调用，有可能会永远阻塞下去的那种。当接收到信号的时候，认为是一个返回并执行其他代码的一个时机。

信号的处理也不简单，因为有些慢系统调用被信号中断后是会自动重启的，所以我们通常需要用siginterrupt(signo, 1)来关闭重启或者在用sigaction安装信号处理函数的时候取消SA_RESTART标志，之后就可以通过判断信号的返回值是否是-1和errno是否为EINTR来判断是否有信号抵达。

如果关闭了SA_RESTART的一些使用慢速系统调用的应用，一般都采用while()循环，检测到EINTR后就重新调用。

while(1)

{

int ret = syscall();

if(ret<0 && errno==EINTR)

continue;

else

break;

}

但是，对于futex这种方法不行，因为futex结束后，再重新运行的过程中，会出现一个时间窗口，其他线程可能会在这个时间窗口中进行pthread_cond_signal，这样，再进行pthread_cond_wait的时候就丢失了一次条件变量的变化。解决方法就是在pthread_cond_wait前检查条件变量，也就是

pthread_mutex_lock();

while(condition_is_false)

pthread_cond_wait();

pthread_mutex_unlock();

pthread_cond_broadcast

实际上，不仅仅信号会导致假唤醒，pthread_cond_broadcast也会导致假唤醒。加入条件变量上有多个线程在等待，pthread_cond_broadcast会唤醒所有的等待线程，而pthread_cond_signal只会唤醒其中一个等待线程。这样，pthread_cond_broadcast的情况也许要在pthread_cond_wait前使用while循环来检查条件变量。