首先看UnassignGuard类的结构:
public:
UnassignGuard(MutexLock& owner) /* 这个类貌似没有什么用处啊! */
: owner_(owner)
{
owner_.unassignHolder();
}
~UnassignGuard()
{
owner_.assignHolder();
}
private:
MutexLock& owner_;
};
可以看到UnassignGuard类中成员只有一把锁,接口只有一个构造函数和一个析构函数。
构造函数的特点是对该锁的持有者清0,析构函数的特点是设置该锁的持有者线程。
关于UnassignGuard,它是配合条件变量来使用的。
首先我们看下条件变量,一般使用条件变量时,要配合while()来防止虚假唤醒,一般模式如下:
MutexLockGuard lock(mutex_); /* 首先加锁 */
while (isEmpty()) { /* 如果队列是空 */
notFull_.wait(); /* 等待queue有任务 */
}
首先进行加锁,加锁后判断条件是否满足,如果满足则跳出对公共资源进行操作,如果不满足则进入while,通过wait陷入阻塞,直到被唤醒。
而UnassignGuard类就是用在wait()中的,进入Contidition::wait():
void wait()
{
MutexLock::UnassignGuard ug(mutex_);
MCHECK(pthread_cond_wait(&pcond_, mutex_.getPthreadMutex())); /* 等待Mutex */
}
我们知道,pthread_cond_wait的内部机制是在线程进入阻塞前将释放锁,如果不释放锁,则锁一直被这个阻塞的线程持有,其他线程无法访问公共资源。
而当pthread_cond_wait返回时,也就是说当前线程被生产者唤醒时,又会重新持有这把锁。
可以看到,在wait()中,pthread_cond_wait会在内部释放锁,而在返回时占有这把锁,UnassignGuard的目的正是在pthread_cond_wait释放锁前将锁的持有者清0,在pthread_cond_wait返回后重新占有锁时将锁的持有者改为当前线程。
看到UnassignGuard的构造函数,内容就是将锁的持有者清0,而在wait()结束时,对UnassignGuard进行析构时,UnassignGuard的析构函数被调用,内容为将当前线程设置为锁的持有者。
封装的手法实在是很巧妙呀。