{"id":6074,"date":"2021-01-18T21:31:11","date_gmt":"2021-01-18T21:31:11","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/latches-in-c-20\/"},"modified":"2023-06-26T09:34:00","modified_gmt":"2023-06-26T09:34:00","slug":"latches-in-c-20","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/latches-in-c-20\/","title":{"rendered":"Latches in C++20"},"content":{"rendered":"

Latches and barriers are coordination types that enable some threads to wait until a counter becomes zero. You can use a std::latch<\/code> only once, but you can use a std::barrier<\/code> more than once. Today, I have a closer look at latches.<\/p>\n

<\/p>\n

 \"TimelineCpp20\"<\/p>\n

Concurrent invocations of the member functions of a std::latch<\/code> or a std::barrier<\/code> are no data race. A data race is such a crucial term in concurrency that I want to write more words to it.<\/p>\n

Data Race<\/h2>\n

A data race is a situation, in which at least two threads access a shared variable at the same time and at least one thread tries to modify the variable. If your program has a data race, it has undefined behavior. This means all outcomes are possible and therefore, reasoning about the program makes no sense anymore.<\/p>\n

Let me show you a program with a data race.<\/p>\n

<\/p>\n

\n
\/\/ addMoney.cpp<\/span>\r\n\r\n#include <functional><\/span>\r\n#include <iostream><\/span>\r\n#include <thread><\/span>\r\n#include <vector><\/span>\r\n\r\nstruct<\/span> Account{\r\n  int<\/span> balance{100<\/span>};                                                 \/\/ (3)<\/span>               \r\n};\r\n\r\nvoid<\/span> addMoney<\/span>(Account&<\/span> to, int<\/span> amount){                             \/\/ (2)<\/span> \r\n  to.balance +=<\/span> amount;                                             \/\/ (1)<\/span>       \r\n}\r\n\r\nint<\/span> main<\/span>(){\r\n  \r\n  std::<\/span>cout <<<\/span> '\\n'<\/span>;\r\n\r\n  Account account;\r\n  \r\n  std::<\/span>vector<<\/span>std::<\/span>thread<\/span>><\/span> vecThreads(100<\/span>);\r\n                                           \r\n  for<\/span> (auto<\/span>&<\/span> thr:<\/span> vecThreads) thr =<\/span> std::<\/span>thread<\/span>(addMoney, std::<\/span>ref(account), 50<\/span>); <\/span>\r\n  \r\n  for<\/span> (auto<\/span>&<\/span> thr:<\/span> vecThreads) thr.join();\r\n                                                 \r\n  std::<\/span>cout <<<\/span> \"account.balance: \"<\/span> <<<\/span> account.balance <<<\/span> '\\n'<\/span>;     \/\/ (4)<\/span>\r\n  \r\n  std::<\/span>cout <<<\/span> '\\n'<\/span>;\r\n\r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
100 threads adding 50 euros to the same account (1) using the function addMoney<\/code> (2). The initial account is 100 (3). The crucial observation is that the writing to the account is done without synchronization. Therefore we have a data race and, consequently, undefined behavior. The final balance is between 5000 and 5100 euro (4).<\/p>\n
 \"addMoney\"<\/p>\n
What is happening? Why are a few additions missing? The update process to.balance +=<\/span> amount; <\/code>in line (1) is a so-called read-modify-write operation. As such, first, the old value of to.balance<\/code> is read, then it is updated, and finally is written. What may happen under the hood is the following. I use numbers to make my argumentation more obvious<\/p>\n