{"id":6053,"date":"2020-12-12T15:34:52","date_gmt":"2020-12-12T15:34:52","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/synchronization-with-atomics-in-c-20\/"},"modified":"2023-06-26T09:35:42","modified_gmt":"2023-06-26T09:35:42","slug":"synchronization-with-atomics-in-c-20","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/synchronization-with-atomics-in-c-20\/","title":{"rendered":"Synchronization with Atomics in C++20"},"content":{"rendered":"

Sender\/receiver workflows are pretty common for threads. In such a workflow, the receiver is waiting for the sender’s notification before it continues to work. There are various ways to implement these workflows. With C++11, you can use condition variables or promise\/future pairs; with C++20, you can use atomics.<\/p>\n

<\/p>\n

 \"TimelineCpp20CoreLanguage\"<\/p>\n

There are various ways to synchronize threads. Each way has its pros and cons. Consequently,  I want to compare them. I assume you don’t know the details of condition variables or promises and futures. Therefore, I will give a short refresher.<\/p>\n

Condition Variables<\/h2>\n

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

 <\/p>\n

<\/p>\n

\n
\/\/ threadSynchronisationConditionVariable.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#include <vector><\/span>\r\n\r\nstd::<\/span>mutex mutex_;\r\nstd::<\/span>condition_variable condVar;\r\n\r\nstd::<\/span>vector<<\/span>int<\/span>><\/span> myVec{};\r\n\r\nvoid<\/span> prepareWork<\/span>() {                                        \/\/ (1)<\/span>\r\n\r\n    {\r\n        std::<\/span>lock_guard<<\/span>std::<\/span>mutex><\/span> lck(mutex_);\r\n        myVec.insert(myVec.end(), {0<\/span>, 1<\/span>, 0<\/span>, 3<\/span>});            \/\/ (3)<\/span>\r\n    }\r\n    std::<\/span>cout <<<\/span> \"Sender: Data prepared.\"<\/span>  <<<\/span> std::<\/span>endl;\r\n    condVar.notify_one();\r\n}\r\n\r\nvoid<\/span> completeWork<\/span>() {                                       \/\/ (2)<\/span>\r\n\r\n    std::<\/span>cout <<<\/span> \"Worker: Waiting for data.\"<\/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> not myVec.empty(); });\r\n    myVec[2<\/span>] =<\/span> 2<\/span>;                                           \/\/ (4)<\/span>\r\n    std::<\/span>cout <<<\/span> \"Waiter: Complete the work.\"<\/span> <<<\/span> std::<\/span>endl;\r\n    for<\/span> (auto<\/span> i:<\/span> myVec) std::<\/span>cout <<<\/span> i <<<\/span> \" \"<\/span>;\r\n    std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n    \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(prepareWork);\r\n    std::<\/span>thread<\/span> t2(completeWork);\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 has two child threads:<\/span>t1<\/code> and t2<\/code>. They get their payload prepareWork<\/code> and completeWork<\/code> in lines (1) and (2). The function prepareWork<\/code> notifies that it is done with the preparation of the work: condVar.notify_one()<\/code>. While holding the lock, the thread t2<\/code> is waiting for its notification: condVar.wait(lck, []{ return not myVec.empty(); })<\/code>. The waiting thread always performs the same steps. When it is waked up, it checks the predicate while holding the lock ([]{ return not myVec.empty();<\/code>). If the predicate does not hold, it puts itself back to sleep. If the predicate holds,  it continues with its work. In the concrete workflow, the sending thread puts the initial values into the std::vector<\/code>(3),  which the receiving thread completes (4).<\/p>\n
\"threadSynchronisationConditionVariable\"<\/p>\n
Condition variables have many inherent issues. For example, the receiver could be awakened without notification or could lose the notification. The first issue is spurious wakeup, and the second is lost wakeup. The predicate protects against both flaws. The notification would be lost when the sender sends its notification before the receiver is in the wait state and does not use a predicate.
Consequently, the receiver waits for something that never happens. This is a deadlock. When you study the program’s output, you see that each second run would cause a deadlock if I would not use a predicate. Of course, it is possible to use condition variables without a predicate.<\/p>\n
If you want to know the sender\/receiver workflow details and the traps of condition variables, read my previous post, “C++ Core Guidelines: Be Aware of the Traps of Condition Variables<\/a>“.<\/p>\n
When you only need a one-time notification, such as in the previous program, promises and futures are a better choice than condition variables. Promises and futures cannot be victims of spurious or lost wakeups.<\/p>\n<\/p>\n
Promises and Futures<\/h2>\n
A promise can send a value, an exception, or a notification to its associated future. Let me use a promise and a future to refactor the previous workflow. Here is the same workflow using a promise\/future pair.<\/p>\n
 <\/p>\n
<\/p>\n
\n
\/\/ threadSynchronisationPromiseFuture.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <future><\/span>\r\n#include <thread><\/span>\r\n#include <vector><\/span>\r\n\r\nstd::<\/span>vector<<\/span>int<\/span>><\/span> myVec{};\r\n\r\nvoid<\/span> prepareWork<\/span>(std::<\/span>promise<<\/span>void<\/span>><\/span> prom) {\r\n\r\n    myVec.insert(myVec.end(), {0<\/span>, 1<\/span>, 0<\/span>, 3<\/span>});\r\n    std::<\/span>cout <<<\/span> \"Sender: Data prepared.\"<\/span>  <<<\/span> std::<\/span>endl;\r\n    prom.set_value();                                     \/\/ (1)<\/span>\r\n\r\n}\r\n\r\nvoid<\/span> completeWork<\/span>(std::<\/span>future<<\/span>void<\/span>><\/span> fut){\r\n\r\n    std::<\/span>cout <<<\/span> \"Worker: Waiting for data.\"<\/span> <<<\/span> std::<\/span>endl;\r\n    fut.wait();                                           \/\/ (2)<\/span>\r\n    myVec[2<\/span>] =<\/span> 2<\/span>;\r\n    std::<\/span>cout <<<\/span> \"Waiter: Complete the work.\"<\/span> <<<\/span> std::<\/span>endl;\r\n    for<\/span> (auto<\/span> i:<\/span> myVec) std::<\/span>cout <<<\/span> i <<<\/span> \" \"<\/span>;\r\n    std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n    \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>promise<<\/span>void<\/span>><\/span> sendNotification;\r\n    auto<\/span> waitForNotification =<\/span> sendNotification.get_future();\r\n\r\n    std::<\/span>thread<\/span> t1(prepareWork, std::<\/span>move(sendNotification));\r\n    std::<\/span>thread<\/span> t2(completeWork, std::<\/span>move(waitForNotification));\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
When you study the workflow, you recognize that the synchronization is reduced to its essential parts: prom.set_value()<\/code> (1)  and fut.wait() (2). <\/code>There is neither a need to use locks or mutexes nor is there a need to use a predicate to protect against spurious or lost wakeups. I skip the screenshot to this run because it is essentially the same, such as in the case of the previous run with condition variables.<\/p>\n
One downside to using promises and futures is that they can only be used once. Here are my previous posts on promises and futures<\/a>, often called tasks.<\/p>\n
If you want to communicate more than once, use condition variables or atomics.<\/p>\n
std::atomic_flag<\/h2>\n
std::atomic_flag<\/span> in C++11 has a simple interface. Its member function clear<\/span> lets you set its value to false,<\/span> with test_and_set<\/span> to true. <\/span>In case you use test_and_set<\/span> you get the old value back. ATOMIC_FLAG_INIT<\/code> enables it to initialize the std::atomic_flag<\/code> to false<\/code>. std::atomic_flag<\/span> has two exciting properties. <\/p>\n
std::atomic_flag<\/span><\/strong> is<\/p>\n