Q1:
在编写一个自己的MutexLock,MutexLockGuard,Condition_var时，为何pthread的condition的wait及signal操作需要传入mutex？
A1:
具体的可见这个帖子:c - Does pthread_cond_wait(&cond_t, &mutex); unlock and then lock the mutex? - Stack Overflow
必须知道条件变量并不需要互斥锁来保护，网络上说需要保护条件变量的都是胡扯.回答中这样说道:
The condition variable doesn't need mutual exclusion protection; the predicate data does.
那为什么在wait和signal的时候总是在外层包一层mutex呢？
那是因为我们必须要保护谓词(predicate),我们使用条件变量的时候是要和谓词一起用的，要是我们想实现这样一个功能:一旦资源数大于0就进行处理,我们可以有下面的代码(这其实也是信号量的实现原理)
extern int rc_count; // 表示资源值
pthread_mutex_t mutex;//是为了保护rc_count,即rc_count就是谓词
pthread_cond_t cond;
pthread_mutex_lock(&mutex);
while(rc_count <= 0)
{
pthread_cond_wait(&cond,&mutex);//只有当资源量大于0时才可能跳出循环.
}
pthread_mutex_unlock(&mutex);
简单来说就是condition的wait和signal是一种简单的信号机制,在wait时,就将当前线程阻塞,并且还要把负责将mutex打开,否则遵循mutex机制的其他乖孩子线程无法更改谓词,和发出signal了.这样wait的线程就会一直阻塞，无法进行下一步操作.而在wait退出的时候，会负责将mutex锁上，从而wait的线程从wait刚退出就自动拥有这个mutex所保护的谓词.帖子中说道:
Never change, nor check, the predicate condition unless the mutex is locked. Ever.
注意,我这里所说的一直阻塞其实只会发生在谓词改变不了的时候.我们一般在signal的线程中采用下面的两种规范写法:
pattern1
pthread_mutex_lock(&mtx);
TODO: change predicate state here as needed.
pthread_mutex_unlock(&mtx);
pthread_cond_signal(&cv);
pattern2
pthread_mutex_lock(&mtx);
TODO: change predicate state here as needed.
pthread_cond_signal(&cv);
pthread_mutex_unlock(&mtx);
想想如果我们的线程都是乖孩子，意味着只有获取锁才能改变谓词,这样的话如果因为某些粗心的程序员写出了下面的代码:
some code
pthread_cond_signal(&cv)//错误添加了这一行
some code
pthread_mutex_lock(&mtx);
TODO: change predicate state here as needed.
pthread_cond_signal(&cv);
pthread_mutex_unlock(&mtx);
由于我们wait端一般是这样写的:
while(rc_count <= 0)
{
pthread_cond_wait(&cond,&mutex);
}
这样的话，即使错误信号发出，只要谓词不满足条件一样是线程阻塞.
下面是一个例子:
int WaitForPredicate()
{
// lock mutex (means:lock access to the predicate)
pthread_mutex_lock(&mtx);
// we can safely check this, since no one else should be
// changing it unless they have the mutex, which they don't
// because we just locked it.
while (!predicate)
{
// predicate not met, so begin waiting for notification
// it has been changed *and* release access to change it
// to anyone wanting to by unlatching the mutex, doing
// both (start waiting and unlatching) atomically
pthread_cond_wait(&cv,&mtx);
// upon arriving here, the above returns with the mutex
// latched (we own it). The predicate *may* be true, and
// we'll be looping around to see if it is, but we can
// safely do so because we own the mutex coming out of
// the cv-wait call.
}
// we still own the mutex here. further, we have assessed the
// predicate is true (thus how we broke the loop).
// take whatever action needed.
// You *must* release the mutex before we leave. Remember, we
// still own it even after the code above.
pthread_mutex_unlock(&mtx);
}
