Some thoughts on the condition variable

You may have used condition variable (later called CV).

Background but more to do introduction, use condition variable time to cooperate with the mutex use, then the mutex is for what, why use this thing?

Why do you design this? Is the mutex superfluous? What data does he use to protect?

Ok! Let's start from scratch.

Condition variable (later unified called CV) is intended to wait for a certain thing to become true or false, and then this thread continues.

According to this requirement, the approximate code should look like this:

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

In this case there is a very serious problem, if T2 first execution, then T1 will never stop there! This is completely inconsistent with our original idea!

The following wording was produced:

Version 2.0bool signaled = False;thread 1:if (!signaled) cv.wait (); thread 2:cv.signal (); signaled = true;

It looks good! But made a very stupid mistake, BOOL is not the thread safe, so

Version 2.1bool signaled = False;thread 1:
Lock;if (!signaled)//1
Unlock Cv.wait (); 2thread 2:cv.signal (); 3
Lock;signaled = true; 4
Unlock

So we protect the signaled to ensure that the thread safe, what will be the problem?

Of course there is a problem! If this is the order of execution, 3-1-4-2 then thread 1 always wait there!

Hey Why is this so? Let's take a few more! To ensure that the signal is issued at the outset, we have added a flag to determine if the signal has been sent, and if so, the CV does not need to wait. Next, we guarantee the thread safe, and now there's a problem with the order of execution!

Think carefully, you will find that the cause of the problem is that the atomic nature of demand is not very good in C + + expression, you think, the meaning of thread 1 translated into Chinese is "if there is no signal is not triggered, then I will wait", thread 2 meaning is obviously "trigger!" ", but triggering a sentence into C + + semantics becomes two statements, multiple instructions, then it's hard for you to meet my needs, at least you can't meet my needs without atomic statement constraints.

So the thread 1 code is a mess! Can you determine if the signaled is false before the wait operation? The answer is in the negative.

Or thread 2, does your signaled become true immediately after you signal? The answer is no, and if you cannot guarantee the atomicity of the two statements, you will not be able to meet the requirements.

So we continue to revise:

Version 3.0bool signaled = False;thread 1:lock;if (!signaled)//1 cv.wait (); 2
Unlock
Thread 2:
Lock
Cv.signal (); 3signaled = true; 4
Unlock

That's OK! But if you've ever heard of spurious wakeup (you can check it yourself), then 3.0 is still not perfect,

The final version is:

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

Then we go back to the original question, why we need to pass in a parameter mutex, the answer is obvious, is to let the CV unlock operation, when the CV takes back the thread's scepter, then the mutex lock, to ensure the symmetry.

Some thoughts on the condition variable