关于Condition Variable的一些思考

时间:2021-11-23 15:15:18

可能大家都使用过condition variable(之后称cv),一些博客也对cv做了介绍,但是有的说的不完全正确,甚至有误导使用者的倾向,其实最合理的使用方式是查阅文档,

如果你英语还ok的话,http://en.cppreference.com/w/cpp/thread/condition_variable 读一遍即可 完全没有必要看我写的这些砖块,但是我的blog可能思路上更贴近初学者,可以借鉴一下。

背景不过多做介绍,使用condition variable的时候都要配合mutex使用,那么mutex就是为了什么呢,为什么要用这个东西呢?

为什么要这样设计?mutex多余吗?他是用来保护什么数据呢?

ok!让我们来从零开始。

condition variable的初衷是为了wait某一个东东变成true或false,然后此线程继续进行。

按照此需求,大概的代码应该是这样:

//version 1.0
Thread 1:
cv.wait();
Thread 2:
cv.signal();

这样的话有一个很严重的问题,如果t2先执行,那么t1岂不是永远停在那里了!这样与我们最初的构想完全不符!

于是产生了下面的写法:

//version 2.0
bool signaled = false;
thread 1:
if(!signaled)
  cv.wait();
thread 2:
cv.signal();
signaled = true;

看上去不错吧!但是犯了一个很白痴的错误,bool并不是thread safe的,所以

//version 2.1
bool signaled = false;
thread 1:
lock;
if(!signaled) //1
  unlock;
  cv.wait(); //2
thread 2:
cv.signal(); //3
lock;
signaled = true; //4
unlock;

这样我们把signaled保护起来,保证thread safe了,会有什么问题吗?

当然有问题!如果执行顺序是这样的话,3-1-4-2 那么thread 1永远wait在那里了!

欸!为什么会这样呢!让我们从长计议!一开始为了保证signal是否发出,我们增加了一个标志位来判断是否信号已经发出,如果已经发出,那么cv不需要等待。接着,我们对thread safe进行了保证,然后现在又出现了执行顺序的问题!

仔 细思考一下,就会发现,其实导致问题的原因就在于需求的原子性并没有很好的用c++表达出来,你想想,thread 1的意思翻译成汉语就是“如果没有信号没有触发,那么我就等”,thread 2的意思很明显就是“触发!”,但是触发一句话到了c++语义中就变成了两个语句,多个指令,那么你很难满足我的需求,至少在不进行原子性语句约束的情况 下你无法满足我的需求。

所以 thread 1 这段代码就是一团糟!当进行wait操作之前,你能确定signaled为false吗?答案是否定的。

或者说thread 2 这段代码 当你signal之后,你的signaled马上变成true了吗? 答案也是否定的,你如果无法保证这两个语句的原子性,那么就无法达到需求。

所以我们继续修改:

//version 3.0
bool signaled = false;
thread 1:
lock;
if(!signaled) //1
  cv.wait(); //2
unlock;
thread 2:
lock;
cv.signal(); //3
signaled = true; //4
unlock;

这样就ok了!但是如果你听说过spurious wakeup(可以自行查阅一下),那么3.0依然是不够完善的,

最终的版本是:

//version 4.0
bool signaled = false;
thread 1:
lock;
while(!signaled) //1
  cv.wait(); //2
unlock;
thread 2:
lock;
cv.signal(); //3
signaled = true; //4
unlock;

然后我们回到最初的问题上去,为什么需要传入一个参数mutex,答案就很显然了,是为了让cv进行unlock操作的,当cv拿回线程的权杖的时候,再把mutex lock上,保证对称性。