![\"trapMice\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/06\/trapMice.jpg\")
<\/h5>\nToday, I am writing a scary post about condition variables. You should be aware of these issues of condition variables. The C++ core guideline CP 42 states: “Don’t wait without a condition”.<\/p>\n
<\/p>\n
<\/h5>\n<\/p>\n
Wait! Condition variables support a pretty simple concept. One thread prepares something and sends a notification another thread is waiting for. Why can’t this be so dangerous? Okay, let’s start with the only rule for today.<\/p>\n
<\/code>wait without a condition<\/a><\/h2>\nHere is the rationale for the rule: “A wait without a condition can miss a wakeup or wake up simply to find that there is no work to do.” What does that mean? Condition variables can be victims of two severe issues: lost wakeup and spurious wakeup. The key concern about condition variables is that they have no memory.<\/p>\n
Before I present this issue, let me first do it right. Here is the pattern of how to use condition variables.<\/p>\n
<\/p>\n
\n\/\/ conditionVariables.cpp<\/span>\r\n\r\n#include <condition_variable><\/span>\r\n#include <iostream><\/span>\r\n#include <thread><\/span>\r\n\r\nstd::<\/span>mutex mutex_;\r\nstd::<\/span>condition_variable condVar; \r\n\r\nbool<\/span> dataReady{false<\/span>};\r\n\r\nvoid<\/span> waitingForWork<\/span>(){\r\n std::<\/span>cout <<<\/span> \"Waiting \"<\/span> <<<\/span> std::<\/span>endl;\r\n std::<\/span>unique_lock<<\/span>std::<\/span>mutex><\/span> lck(mutex_);\r\n condVar.wait(lck, []{ return<\/span> dataReady; }); \/\/ (4)<\/span>\r\n std::<\/span>cout <<<\/span> \"Running \"<\/span> <<<\/span> std::<\/span>endl;\r\n}\r\n\r\nvoid<\/span> setDataReady<\/span>(){\r\n {\r\n std::<\/span>lock_guard<<\/span>std::<\/span>mutex><\/span> lck(mutex_);\r\n dataReady =<\/span> true<\/span>;\r\n }\r\n std::<\/span>cout <<<\/span> \"Data prepared\"<\/span> <<<\/span> std::<\/span>endl;\r\n condVar.notify_one(); \/\/ (3)<\/span>\r\n}\r\n\r\nint<\/span> main<\/span>(){\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n\r\n std::<\/span>thread<\/span> t1(waitingForWork); \/\/ (1)<\/span>\r\n std::<\/span>thread<\/span> t2(setDataReady); \/\/ (2)<\/span>\r\n\r\n t1.join();\r\n t2.join();\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n \r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
How does the synchronization work? The program has two child threads: t1<\/span> and t2<\/span>. They get their work package waitingForWork<\/span> and setDataRead<\/span> in lines (1 and 2). setDataReady<\/span> notifies – using the condition variable condVar<\/span> – that it is done with preparing the work: condVar.notify_one()<\/span>(line 3). While holding the lock, thread t1<\/span> waits for its notification: condVar.wait(lck, []{ return dataReady; })<\/span>( line 4). The sender and receiver need a lock. In the case of the sender, a std::lock_guard<\/span> is sufficient because it calls to lock and unlock only once. In the case of the receiver, a std::unique_lock<\/span> is necessary because it usually frequently locks and unlocks its mutex.<\/p>\nHere is the output of the program.<\/p>\n
![\"conditionVariable\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2016\/05\/conditionVariable.png\")
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Maybe you are wondering why you need a predicate for the wait<\/span> call because you can invoke wait<\/span> without a predicate. This workflow seems quite too complicated for such a simple synchronization of threads. <\/p>\nNow we are back to the missing memory and the two phenomena called lost wakeup and spurious wakeup.<\/p>\n<\/p>\n
Lost Wakeup and Spurious Wakeup<\/h3>\n\n- Lost wakeup<\/strong>: The phenomenon of the lost wakeup is that the sender sends its notification before the receiver gets to its wait state. The consequence is that the notification is lost. The C++ standard describes condition variables as a simultaneous synchronization mechanism: “The condition_variable class is a synchronization primitive that can be used to block a thread, or multiple threads at the same time<\/strong>, …”. So the notification gets lost. The receiver is waiting and waiting and…<\/li>\n
- Spurious wakeup<\/strong>: The receiver may wake up although no notification has happened. At a minimum POSIX Threads<\/a> and the Windows AP<\/a>I can be victims of these phenomena.<\/li>\n<\/ul>\n
To become not the victim of these two issues, you have to use an additional predicate as memory or, as a rule, state it as an additional condition. If you don’t believe it, here is the wait workflow.<\/p>\n
The wait workflow <\/h3>\n
In the initial wait processing, the thread locks the mutex and then checks the predicate []{ return dataReady; }<\/span>.<\/p>\n\n- If the call of the predicated evaluates to\n
\n- true<\/span>: the thread continues its work.<\/li>\n
- false<\/span>: condVar.wait()<\/span> unlocks the mutex and puts the thread in a waiting (blocking) state<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
If the condition_variable condVar<\/span> is in the waiting state and gets a notification or a spurious wakeup, the following steps happen.<\/p>\n\n- The thread is unblocked, and will reacquire the lock on the mutex. <\/li>\n
- The thread checks the predicate.<\/li>\n
- If the call of the predicated evaluates to\n
\n- true<\/span>: the thread continues its work.<\/li>\n
- false<\/span>: condVar.wait<\/span>() unlocks the mutex and puts the thread in a waiting (blocking) state.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
Complicated! Right? Don’t you believe me?<\/p>\n
Without a predicate<\/h3>\n
What will happen if I remove the predicate from the last example? <\/p>\n
\n\/\/ conditionVariableWithoutPredicate.cpp<\/span>\r\n\r\n#include <condition_variable><\/span>\r\n#include <iostream><\/span>\r\n#include <thread><\/span>\r\n\r\nstd::<\/span>mutex mutex_;\r\nstd::<\/span>condition_variable condVar;\r\n\r\nvoid<\/span> waitingForWork<\/span>(){\r\n std::<\/span>cout <<<\/span> \"Waiting \"<\/span> <<<\/span> std::<\/span>endl;\r\n std::<\/span>unique_lock<<\/span>std::<\/span>mutex><\/span> lck(mutex_);\r\n condVar.wait(lck); \/\/ (1)<\/span>\r\n std::<\/span>cout <<<\/span> \"Running \"<\/span> <<<\/span> std::<\/span>endl;\r\n}\r\n\r\nvoid<\/span> setDataReady<\/span>(){\r\n std::<\/span>cout <<<\/span> \"Data prepared\"<\/span> <<<\/span> std::<\/span>endl;\r\n condVar.notify_one(); \/\/ (2)<\/span>\r\n}\r\n\r\nint<\/span> main<\/span>(){\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n\r\n std::<\/span>thread<\/span> t1(waitingForWork);\r\n std::<\/span>thread<\/span> t2(setDataReady);\r\n\r\n t1.join();\r\n t2.join();\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n \r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
Now, the wait call in line (1) does not use a predicate, and the synchronization looks relatively easy. Sad to say, but the program now has a race condition which you can see in the very first execution. The screenshot shows the deadlock.<\/p>\n
![\"conditionVariableWithoutPredicate\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2016\/05\/conditionVariableWithoutPredicate.png\")
<\/p>\n
<\/p>\n
<\/p>\n
The sender sends in line (1) (condVar.notify_one()<\/span>) its notification before the receiver is capable of receiving it; therefore, the receiver will sleep forever. <\/p>\nOkay, lesson learned the hard way. The predicate is necessary, but there must be a way to simplify the program conditionVariables.cpp<\/span>?<\/p>\nAn atomic predicate <\/h3>\n
Maybe, you saw it. The variable dataReady<\/span> is just a boolean. We should make it an atomic boolean and, therefore, eliminate the mutex on the sender.<\/p>\nHere we are:<\/p>\n
\n\/\/ conditionVariableAtomic.cpp<\/span>\r\n\r\n#include <atomic><\/span>\r\n#include <condition_variable><\/span>\r\n#include <iostream><\/span>\r\n#include <thread><\/span>\r\n\r\nstd::<\/span>mutex mutex_;\r\nstd::<\/span>condition_variable condVar;\r\n\r\nstd::<\/span>atomic<<\/span>bool<\/span>><\/span> dataReady{false<\/span>};\r\n\r\nvoid<\/span> waitingForWork<\/span>(){\r\n std::<\/span>cout <<<\/span> \"Waiting \"<\/span> <<<\/span> std::<\/span>endl;\r\n std::<\/span>unique_lock<<\/span>std::<\/span>mutex><\/span> lck(mutex_);\r\n condVar.wait(lck, []{ return<\/span> dataReady.load(); }); \/\/ (1)<\/span>\r\n std::<\/span>cout <<<\/span> \"Running \"<\/span> <<<\/span> std::<\/span>endl;\r\n}\r\n\r\nvoid<\/span> setDataReady<\/span>(){\r\n dataReady =<\/span> true<\/span>;\r\n std::<\/span>cout <<<\/span> \"Data prepared\"<\/span> <<<\/span> std::<\/span>endl;\r\n condVar.notify_one();\r\n}\r\n\r\nint<\/span> main<\/span>(){\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n\r\n std::<\/span>thread<\/span> t1(waitingForWork);\r\n std::<\/span>thread<\/span> t2(setDataReady);\r\n\r\n t1.join();\r\n t2.join();\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n \r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
The program is relatively straightforward compared to the first version because dataReady <\/span>has not to be protected by a mutex. Once more, the program has a race condition that can cause a deadlock. Why? dataReady <\/span>is atomic! Right, but the wait expression (condVar.wait(lck, []{ return dataReady.load(); });<\/span>) in line (1) is way more complicated than it seems.<\/p>\nThe wait expression is equivalent to the following four lines:<\/p>\n
\nstd::<\/span>unique_lock<<\/span>std::<\/span>mutex><\/span> lck(mutex_);
while<\/span> ( !<\/span>[]{ return<\/span> dataReady.load(); }() {\r\n \/\/ time window (1)<\/span>\r\n condVar.wait(lck);\r\n}\r\n<\/pre>\n<\/div>\nEven if you make dataReady<\/span> an atomic, it must be modified under the mutex; if not, the modification to the waiting thread may be published but not correctly synchronized. This race condition may cause a deadlock. What does that mean: published but not correctly synchronized? Let’s look closer at the previous code snippet and assume that data is atomic and is not protected by the mutex mutex<\/span>.<\/p>\nLet me assume the notification is sent while the condition variable condVar<\/span> is in the wait expression but not the waiting state. This means the execution of the thread is in the source snippet, in line with the comment time window ( line 1). The result is that the notification is lost. Afterward, the thread returns to the waiting state and presumably sleeps forever. <\/p>\nThis wouldn’t have happened if dataReady <\/span>had been protected by a mutex. Because of the synchronization with the mutex, the notification would only be sent if the condition variable and, therefore, the receiver thread is in the waiting state. <\/p>\nWhat a scary story! Is there no possibility of making the initial program conditionVariables.cpp<\/span> more straightforward? No, not with a condition variable, but you can use a promise and future pair to complete the job. For the details, read the post Thread Synchronisation with Condition Variables or Tasks<\/a>.<\/p>\nWhat’s next?<\/h2>\n