{"id":4818,"date":"2016-07-16T09:48:02","date_gmt":"2016-07-16T09:48:02","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/acquire-release-semantic-the-typical-misunderstanding\/"},"modified":"2023-06-26T12:50:00","modified_gmt":"2023-06-26T12:50:00","slug":"acquire-release-semantic-the-typical-misunderstanding","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/acquire-release-semantic-the-typical-misunderstanding\/","title":{"rendered":"Acquire-Release Semantics – The Typical Misunderstanding"},"content":{"rendered":"

A release operation synchronizes-with an acquire operation on the same atomic variable. So we can easily synchronise threads, if<\/strong><\/span> … . Today’s post is about the if<\/strong>.<\/span><\/p>\n

<\/p>\n

What’s my motivation for writing a post about the typical misunderstanding of the acquire-release semantic? Sure, I and many of my listeners and trainees have already fallen into the trap. But at first the straightforward case.<\/p>\n

Waiting included<\/h2>\n

<\/span>I use this simple program as a starting point.
<\/span><\/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<\/pre>\n<\/td>\n
\n
\/\/ acquireReleaseWithWaiting.cpp<\/span>\r\n\r\n#include <atomic><\/span>\r\n#include <iostream><\/span>\r\n#include <thread><\/span>\r\n#include <vector><\/span>\r\n\r\nstd::vector<int<\/span>> mySharedWork;\r\nstd::atomic<bool<\/span>> dataProduced(false);\r\n\r\nvoid<\/span> dataProducer(){\r\n    mySharedWork={1,0,3};\r\n    dataProduced.store(true, std::memory_order_release);\r\n}\r\n\r\nvoid<\/span> dataConsumer(){\r\n    while<\/span>( !dataProduced.load(std::memory_order_acquire) );\r\n    mySharedWork[1]= 2;\r\n}\r\n\r\nint<\/span> main(){\r\n    \r\n  std::cout << std::endl;\r\n\r\n  std::thread<\/span> t1(dataConsumer);\r\n  std::thread<\/span> t2(dataProducer);\r\n\r\n  t1.join();\r\n  t2.join();\r\n  \r\n  for<\/span> (auto<\/span> v: mySharedWork){\r\n      std::cout << v << \" \"<\/span>;\r\n  }\r\n      \r\n  std::cout << \"\\n\\n\"<\/span>;\r\n  \r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
The consumer thread t1 in line 17 waits until the consumer thread t2 in line 13 has set dataProduced<\/span> to true.dataPruduced <\/span>is the guard because it guarantees access to the non-atomic variable mySharedWork<\/span> is synchronized. That means, at first, the producer thread t2 initializes mySharedWork,<\/span> then the consumer thread t2 finishes the work by setting mySharedWork[1]<\/span> to 2. So the program is well-defined.<\/p>\n
\"acquireReleaseWithWaiting\"<\/p>\n
The graphic shows the happens-before<\/em> relation within the threads and the synchronized-with<\/em> relation between the threads. synchronize-with<\/em> establishes a happens-before<\/em> relation. The rest of the reasoning is the transitivity of the happens-before<\/em> relation. mySharedWork={1,0,3} happens-before<\/em> mySharedWork[1]=<\/span> 2.<\/p>\n
\"withWaiting\"<\/p>\n
But what aspect is often missing in this reasoning. The if.<\/span><\/strong><\/p>\n<\/p>\n
If, …<\/h2>\n
What is happing if<\/span> <\/strong>the consumer thread t2 in line 17 is not waiting for the producer thread?<\/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<\/pre>\n<\/td>\n
\n
\/\/ acquireReleaseWithoutWaiting.cpp<\/span>\r\n\r\n#include <atomic><\/span>\r\n#include <iostream><\/span>\r\n#include <thread><\/span>\r\n#include <vector><\/span>\r\n\r\nstd::vector<int<\/span>> mySharedWork;\r\nstd::atomic<bool<\/span>> dataProduced(false);\r\n\r\nvoid<\/span> dataProducer(){\r\n    mySharedWork={1,0,3};\r\n    dataProduced.store(true, std::memory_order_release);\r\n}\r\n\r\nvoid<\/span> dataConsumer(){\r\n    dataProduced.load(std::memory_order_acquire);\r\n    mySharedWork[1]= 2;\r\n}\r\n\r\nint<\/span> main(){\r\n    \r\n  std::cout << std::endl;\r\n\r\n  std::thread<\/span> t1(dataConsumer);\r\n  std::thread<\/span> t2(dataProducer);\r\n\r\n  t1.join();\r\n  t2.join();\r\n  \r\n  for<\/span> (auto<\/span> v: mySharedWork){\r\n      std::cout << v << \" \"<\/span>;\r\n  }\r\n      \r\n  std::cout << \"\\n\\n\"<\/span>;\r\n  \r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
The program has undefined behavior because there is a data race <\/a>on the variable mySharedWork. <\/span>In case I let the program run, the undefined behavior gets immediately visible. That holds for Linux and Windows.  <\/span><\/p>\n
\"acquireReleaseWithoutWaiting\"\"acquireReleaseWithoutWaitingWin\"<\/p>\n
What’s the issue? It holds: store(true, std::memory_order_release)<\/span> synchron<\/em>izes-with<\/em> dataProduced.load(std::memory_order_acquire).<\/span> Yes, of course, but that doesn’t mean the acquire operation is waiting for the release operation. Exactly that is displayed in the graphic. In the graphic the d<\/span>ataProduced.load(std::memory_order_acquire)<\/span> instruction is performed before the instruction dataProduced.store(true, std::memory_order_release). <\/span>So we have no synchronize-with<\/em> <\/span>relation. <\/p>\n
\"withoutWaiting\"<\/p>\n
The solution<\/h3>\n
synchronize-with means in this specific case: If<\/span><\/strong> dataProduced.store(true, std::memory_order_release)<\/span> happens before dataProduced.load(std::memory_order_acquire)<\/span>, then<\/span><\/strong> all visible effects of operations before dataProduced.store(true, std::memory_order_release)<\/span> are visible after dataProduced.load(std::memory_order_acquire). <\/span>The key is the word if.<\/span><\/strong> <\/span>Exactly that if<\/span> <\/strong>will be guaranteed in the first program with (while(!dataProduced.load(std::memory_order_acquire)<\/span>).<\/span><\/p>\n
Once again, but formal.
<\/em><\/p>\n