首先看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的析构函数被调用，内容为将当前线程设置为锁的持有者。
封装的手法实在是很巧妙呀。
转载于:https://www.cnblogs.com/lxy-xf/p/11289078.html
