POSIX Thread相关
1. 关于pthread_cond系列函数
pthread_cond_wait的参数里有一个mutex,其作用往往令人费解。
最近在考察OpenMAX系统发现这一部分的实现可能导致较大的风险。
一般而言有了这个mutex以后对于cond实现一些增强的特性就比较方便。
例如,如果要将cond用作semaphore,以下代码应该能起作用:
- sem_down(sem)
- {
- pthread_mutex_lock(sem->mutex);
- // critical section
- sem->count--;
- if (sem->count < 0)
- {
- pthread_cond_wait(sem->cond, sem->mutex); // the mutex is unlocked once the thread gets blocked
- // mutex is locked and owned by the current thread again after it is scheduled to run when unblocked
- }
- pthread_mutex_unlock(sem->mutex)
- }
- sem_up(sem)
- {
- pthread_mutex_lock(sem->mutex); // absence of this mutex acquisition may cause severe error
- sem->count++;
- pthread_cond_signal(sem->cond);
- pthread_mutex_unlock(sem->mutex)
- }
这样cond和count的操作被完全保护(原子化),同时由于pthread_cond_wait在cond阻塞情况下自动释放mutex又不至于导致死锁。
但是其前提条件是底层的OS正确地实现这几个POSIX接口的意图(这不是必然的)。否则需要通过时序的分析确定可能造成的问题。
注意在sem_up中如果不做互斥量保护则在如下情况下发生错误:
线程A阻塞在pthread_cond_wait,sem->count计数为-1;
线程B进入sem_down,并执行完成sem->count--后,调度到线程C;
线程C进入sem_up,执行sem->count++,和pthread_cond_signal,使得sem->count计数变为0,同时线程A被激活;
这样线程A可获得mutex并从sem_down返回;
线程B条件判断不成立不被阻塞,亦返回。但显然在这个序列中应该至少有一个线程被阻塞。(按理想顺序应该B被阻塞)
由于posix规定中关于pthread_cond_signal触发的说明是至少释放一个阻塞,于是存在同时释放多个阻塞的情形。如下代码也许可以解决这个问题:
- sem_down(sem)
- {
- pthread_mutex_lock(sem->mutex);
- // critical section
- sem->count--;
- if (sem->count < 0)
- {
- _again:
- sem->nblocked++; // count the number of blocked threads
- pthread_cond_wait(sem->cond, sem->mutex);
- sem->nblocked--;
- if (sem->nblocked + sem->count < 0)
- { // this thread is not ready to be unblocked
- goto _again;
- }
- }
- pthread_mutex_unlock(sem->mutex);
- }
如果count不记录被阻塞的线程个数,以下方案很理想:
- sem_down(sem)
- {
- pthread_mutex_lock(sem->mutex);
- // critical section
- while(sem->count == 0)
- {
- pthread_cond_wait(sem->cond, sem->mutex);
- }
- sem->count--;
- pthread_mutex_unlock(sem->mutex);
- }
enjoy every minute of an appless, googless and oracless life