{"id":4758,"date":"2016-05-17T06:01:23","date_gmt":"2016-05-17T06:01:23","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/condition-variables\/"},"modified":"2023-06-26T12:56:56","modified_gmt":"2023-06-26T12:56:56","slug":"condition-variables","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/condition-variables\/","title":{"rendered":"Condition Variables"},"content":{"rendered":"

Condition variables allow us to synchronize threads via notifications. So, you can implement workflows like sender\/receiver or producer\/consumer. In such a workflow, the receiver waits for the sender’s notification. If the receiver gets the notification, it continues its work.<\/p>\n

<\/p>\n

std::condition_variable<\/h2>\n

The condition variable can fulfill the roles of a sender or a receiver. As a sender, it can notify one or more receivers.<\/p>\n

That’s all you have to know to use condition variables.<\/p>\n

<\/p>\n

\n\n\n\n
\n
 1\r\n 2\r\n 3\r\n 4\r\n 5\r\n 6\r\n 7\r\n 8\r\n 9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n26\r\n27\r\n28\r\n29\r\n30\r\n31\r\n32\r\n33\r\n34\r\n35\r\n36\r\n37\r\n38\r\n39\r\n40\r\n41<\/pre>\n<\/td>\n
\n
\/\/ conditionVariable.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <condition_variable><\/span>\r\n#include <mutex><\/span>\r\n#include <thread><\/span>\r\n\r\nstd::mutex mutex_;\r\nstd::condition_variable condVar;\r\n\r\nvoid<\/span> doTheWork(){\r\n  std::cout << \"Processing shared data.\"<\/span> << std::endl;\r\n}\r\n\r\nvoid<\/span> waitingForWork(){\r\n    std::cout << \"Worker: Waiting for work.\"<\/span> << std::endl;\r\n\r\n    std::unique_lock<std::mutex> lck(mutex_);\r\n    condVar.wait(lck);\r\n    doTheWork();\r\n    std::cout << \"Work done.\"<\/span> << std::endl;\r\n}\r\n\r\nvoid<\/span> setDataReady(){\r\n    std::cout << \"Sender: Data is ready.\"<\/span>  << std::endl;\r\n    condVar.notify_one();\r\n}\r\n\r\nint<\/span> main(){\r\n\r\n  std::cout << std::endl;\r\n\r\n  std::thread<\/span> t1(waitingForWork);\r\n  std::thread<\/span> t2(setDataReady);\r\n\r\n  t1.join();\r\n  t2.join();\r\n\r\n  std::cout << std::endl;\r\n  \r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
The program has two child threads: t1<\/span> and t2<\/span>. They get their callable payload (functions or functors)<\/em> waitingForWork<\/span> and setDataReady<\/span> in lines 33 and 34. The function setDataReady<\/span> notifies  – using the condition variable condVar<\/span> – that it is done with the preparation of the work: condVar.notify_one()<\/span>. While holding the lock, thread t2<\/span> awaits its notification: condVar.wait(lck)<\/span>. The waiting thread always performs the same steps. It wakes up, tries to get the lock, checks if it’s holding it, if the notifications arrived, and, in case of failure,  puts itself back to sleep. In case of success, the thread leaves the endless loop and continues with its work.<\/p>\n
 <\/p>\n
The output of the program is not so thrilling. That was my first impression. But wait. <\/p>\n
\"conditionVariable\"<\/h2>\n<\/p>\n
Spurious wakeup<\/h2>\n
The devil is in the details. It can happen that the receiver finished its task before the sender sent its notification. How is that possible? The receiver is susceptible to spurious wakeups. So the receiver wakes up, although no notification happens. I had to add a predicate to the wait method to protect it from this. That’s precisely what I had done in the following example<\/p>\n
<\/p>\n
\n\n\n\n
\n
 1\r\n 2\r\n 3\r\n 4\r\n 5\r\n 6\r\n 7\r\n 8\r\n 9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n26\r\n27\r\n28\r\n29\r\n30\r\n31\r\n32\r\n33\r\n34\r\n35\r\n36\r\n37\r\n38\r\n39\r\n40\r\n41\r\n42\r\n43\r\n44\r\n45<\/pre>\n<\/td>\n
\n
\/\/ conditionVariableFixed.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <condition_variable><\/span>\r\n#include <mutex><\/span>\r\n#include <thread><\/span>\r\n\r\nstd::mutex mutex_;\r\nstd::condition_variable condVar;\r\n\r\nbool<\/span> dataReady;\r\n\r\nvoid<\/span> doTheWork(){\r\n  std::cout << \"Processing shared data.\"<\/span> << std::endl;\r\n}\r\n\r\nvoid<\/span> waitingForWork(){\r\n    std::cout << \"Worker: Waiting for work.\"<\/span> << std::endl;\r\n\r\n    std::unique_lock<std::mutex> lck(mutex_);\r\n    condVar.wait(lck,[]{return<\/span> dataReady;});\r\n    doTheWork();\r\n    std::cout << \"Work done.\"<\/span> << std::endl;\r\n}\r\n\r\nvoid<\/span> setDataReady(){\r\n    std::lock_guard<std::mutex> lck(mutex_);\r\n    dataReady=true;\r\n    std::cout << \"Sender: Data is ready.\"<\/span>  << std::endl;\r\n    condVar.notify_one();\r\n}\r\n\r\nint<\/span> main(){\r\n\r\n  std::cout << std::endl;\r\n\r\n  std::thread<\/span> t1(waitingForWork);\r\n  std::thread<\/span> t2(setDataReady);\r\n\r\n  t1.join();\r\n  t2.join();\r\n\r\n  std::cout << std::endl;\r\n  \r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
The key difference from the first example conditionVariable.cpp<\/span> is the boolean dataReady<\/span> used in line 11 as an additional condition. dataReady<\/span> is set to true<\/span> in line 28. It is checked in the function waitingForWork: condVar.waint(lck,[]return dataReady;})<\/span>. The wait()<\/span> method has an additional overload that accepts a predicate. A predicate is a callable returning true<\/span> or false.<\/span> In this example, the callable is a lambda function. So, the condition variable checks whether the predicate is true<\/span> or if the notification happened.<\/p>\n
A short remark –  dataReady.<\/span> dataReady<\/span> is a shared variable that will be changed. So I had to protect it with a lock. Because thread t1<\/span> sets and releases the lock just once, std::lock_guard<\/span> is fine for that job. That will not hold for thread t2<\/span>. The wait method will continuously lock and unlock the mutex. So I need the more powerful lock: std::unique_lock.<\/span><\/p>\n
But that’s not all. Condition variables have a lot of challenges. They must be protected by locks and are susceptible to spurious wakeups. Most use cases are easier to solve with tasks. More about tasks in the next post.<\/p>\n
 Lost wakeup<\/a><\/span><\/h2>\n
 <\/p>\n
The meanness of condition variables goes on. About every 10th execution of the conditionVariable.cpp<\/span> something strange happens. The program blocks.
 <\/span><\/p>\n
\"conditionVariableWithoutPredicate\"<\/p>\n
I have no idea what’s going on. This phenomenon contradicts my intuition of condition variables. Did I mention that I don’t like condition variables? With the support of Anthony Williams<\/a>, I solved the riddle.<\/p>\n
The problem is that the notification gets lost if the sender sends its notification before the receiver gets to a wait state. The C++ standard describes condition variables as synchronization mechanisms at the same time: “<\/span>The<\/span> condition<\/span>_variable class<\/span> is<\/span> a synchronization<\/span> primitive that<\/span> can<\/span> be<\/span> used<\/span> to<\/span> block a thread<\/span>, or<\/span> multiple threads<\/span> at<\/span> the<\/span> same<\/span> time, …<\/span>“<\/span>. So the notification gets lost, and the receiver is waiting and waiting and ….<\/p>\n
How can this issue be solved? The predicate that got rid of spurious wakeups will also help with lost ones. If the predicate is true,<\/span> the receiver can continue its work independently of the sender’s notification. The variable dataReady<\/span> is like a memory. Because as far as the variable data in line 28 is set to true,<\/span> the receiver assumes in line 21 that the notification was delivered.<\/p>\n
What’s next?<\/h2>\n
With tasks, multithreading in C++ get a lot easier. Stay tuned for the next post<\/a>. (Proofreader Alexey Elymanov<\/strong>)<\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n","protected":false},"excerpt":{"rendered":"
Condition variables allow us to synchronize threads via notifications. So, you can implement workflows like sender\/receiver or producer\/consumer. In such a workflow, the receiver waits for the sender’s notification. If the receiver gets the notification, it continues its work.<\/p>\n","protected":false},"author":21,"featured_media":4756,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[366],"tags":[451],"class_list":["post-4758","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-multithreading","tag-condition-variables"],"_links":{"self":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/4758","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/comments?post=4758"}],"version-history":[{"count":1,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/4758\/revisions"}],"predecessor-version":[{"id":6979,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/4758\/revisions\/6979"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media\/4756"}],"wp:attachment":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media?parent=4758"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/categories?post=4758"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/tags?post=4758"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}