![\"\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2021\/02\/TimelineCpp20Coroutines.png\")
<\/p>\nIt’s a typical requirement for thread management to synchronize them. One thread prepares, in this case, a work-package another thread is waiting for.<\/p>\n
<\/p>\n
<\/p>\n
I assume most of you use condition variables for this sender\/receiver or producer\/consumer workflow. Condition variables have many inherent risks, such as spurious wakeup and lost wakeup. Before I implement thread synchronization with coroutines, let me rephrase from a previous post about the inherent challenges of condition variables.<\/p>\n
Here is the pattern for the correct usage of condition variables.<\/p>\n
\/\/ conditionVariables.cpp<\/span>\n\n#include <condition_variable><\/span>\n#include <iostream><\/span>\n#include <thread><\/span>\n\nstd::<\/span>mutex mutex_;\nstd::<\/span>condition_variable condVar; \n\nbool<\/span> dataReady{false<\/span>};\n\nvoid<\/span> waitingForWork<\/span>(){\n std::<\/span>cout <<<\/span> \"Waiting \"<\/span> <<<\/span> std::<\/span>endl;\n std::<\/span>unique_lock<<\/span>std::<\/span>mutex><\/span> lck(mutex_);\n condVar.wait(lck, []{ return<\/span> dataReady; }); \/\/ (4)<\/span>\n std::<\/span>cout <<<\/span> \"Running \"<\/span> <<<\/span> std::<\/span>endl;\n}\n\nvoid<\/span> setDataReady<\/span>(){\n {\n std::<\/span>lock_guard<<\/span>std::<\/span>mutex><\/span> lck(mutex_);\n dataReady =<\/span> true<\/span>;\n }\n std::<\/span>cout <<<\/span> \"Data prepared\"<\/span> <<<\/span> std::<\/span>endl;\n condVar.notify_one(); \/\/ (3)<\/span>\n}\n\nint<\/span> main<\/span>(){\n \n std::<\/span>cout <<<\/span> std::<\/span>endl;\n\n std::<\/span>thread<\/span> t1(waitingForWork); \/\/ (1)<\/span>\n std::<\/span>thread<\/span> t2(setDataReady); \/\/ (2)<\/span>\n\n t1.join();\n t2.join();\n \n std::<\/span>cout <<<\/span> std::<\/span>endl;\n \n}\n<\/pre>\n<\/div>\nHow does the synchronization work? The program has two child threads: t1<\/span> and t2<\/span>. They get their work package\u00a0waitingForWork<\/span>\u00a0and setDataRead<\/span>\u00a0in lines (1 and 2). setDataReady<\/span>\u00a0notifies – using the condition variable condVar<\/span>\u00a0– that it is done with preparing the work: condVar.notify_one()<\/span>(line 3). While holding the lock, thread t1<\/span>\u00a0waits 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>\u00a0is sufficient because it calls lock and unlock only once. In the case of the receiver, a std::unique_lock<\/span>\u00a0is necessary because it usually frequently locks and unlocks its mutex.<\/p>\nFinally, the output of the program.<\/p>\n
![\"conditionVariable\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2016\/05\/conditionVariable.png\")
<\/p>\n
Maybe you are wondering why you need a predicate for the wait<\/span> call because you can invoke wait<\/span>\u00a0without a predicate. This workflow seems quite too complicated for such a simple synchronization of threads.<\/p>\nNow we are back to the missing memory condition variables and the two phenomena called lost wakeup and spurious wakeup.<\/p>\n
Lost Wakeup and Spurious Wakeup<\/h3>\n\n- Lost wakeup<\/strong>:\u00a0The sender sends its notification before the receiver is in the wait state. The consequence is that the notification is lost.<\/li>\n
- Spurious wakeup<\/strong>: The receiver may wake up although no notification has happened.<\/li>\n<\/ul>\n
To become not the victim of these two issues, you have to use an additional predicate as memory. If not, you have, in this example, a 50\/50 chance of a lost wakeup. A lost wakeup is essentially a deadlock because a thread waits for something that never happens.<\/p>\n