条件变量与虚假唤醒

1. 相关函数                                                                                         
       #include <pthread.h>
       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循环来检查条件变量。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值