{"id":4853,"date":"2016-08-16T05:53:27","date_gmt":"2016-08-16T05:53:27","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/ongoing-optimization-acquire-release-semantic-with-cppmem\/"},"modified":"2023-10-21T20:13:09","modified_gmt":"2023-10-21T20:13:09","slug":"ongoing-optimization-acquire-release-semantic-with-cppmem","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/ongoing-optimization-acquire-release-semantic-with-cppmem\/","title":{"rendered":"Ongoing Optimization: Acquire-Release Semantics with CppMem"},"content":{"rendered":"

With the acquire-release semantics, we break the sequential consistency. In the acquire-release semantics, synchronization occurs between atomic operations on the same atomic and not between threads.<\/p>\n

<\/p>\n

Acquire-release semantic<\/h2>\n

The acquire-release semantic is more lightweight and, therefore, faster than the sequential consistency<\/a> because the synchronization only occurs between atomic operations. But although the intellectual challenge increases.<\/p>\n

<\/p>\n

\n\n\n\n
\n
 1\n 2\n 3\n 4\n 5\n 6\n 7\n 8\n 9\n10\n11\n12\n13\n14\n15\n16\n17\n18\n19\n20\n21\n22\n23\n24\n25<\/pre>\n<\/td>\n
\n
\/\/ ongoingOptimizationAcquireRelease.cpp<\/span>\n\n#include <atomic><\/span>\n#include <iostream><\/span>\n#include <thread><\/span>\n\nstd::atomic<int<\/span>> x{0};\nstd::atomic<int<\/span>> y{0};\n\nvoid<\/span> writing(){  \n  x.store(2000,std::memory_order_relaxed);  \n  y.store(11,std::memory_order_release);\n}\n\nvoid<\/span> reading(){  \n  std::cout << y.load(std::memory_order_acquire) << \" \"<\/span>;  \n  std::cout << x.load(std::memory_order_relaxed) << std::endl;\n}\n\nint<\/span> main(){\n  std::thread<\/span> thread1(writing);\n  std::thread<\/span> thread2(reading);\n  thread1.join();\n  thread2.join();\n};\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
At first glance, you will notice that all operations are atomic. So the program is well-defined. But the second glance shows more. The atomic operations on y are attached with the flags std::memory_order_release<\/span> (line 12) and std::memory_order_acquire <\/span>(line 16). In contrast, the atomic operations on x are annotated with std::memory_order_relaxed<\/span>. So there are no synchronization and ordering constraints<\/a> for x. The key for the possible values for x and y can only be answered by y.<\/p>\n
It holds:<\/p>\n
    \n
  1. y.store(11,std::memory_order_release)<\/span> synchronizes-with<\/strong> y.load(std::memory_order_acquire)<\/span><\/li>\n
  2. x.store(2000,std::memory_order_relaxed<\/span> is visible before <\/strong> y.store(11,std::memory_order_release)<\/span><\/li>\n
  3. y.load(std::memory_order_acquire)<\/span> is visible before <\/strong> x.load(std::memory_order_relaxed)<\/span><\/li>\n<\/ol>\n
    I will elaborate a little bit more on these three statements. The key idea is that the store of y in line 10 synchronizes with the load of y in line 16. The reason is that the operations occur on the same atomic and follow the acquire-release semantic. So y uses std::memory_order_release <\/span>in line 12 and std::memory_order_acquire <\/span>in line 16. But the pairwise operations on y have another very interesting property. They establish a kind of barrier relative to y. So\u00a0x.store(2000,std::memory_order_relaxed)<\/span> can not be executed after <\/strong>y.store(std::memory_order_release)<\/span>, so\u00a0x.load()\u00a0<\/span>can not be executed before<\/strong> y.load()<\/span>.<\/p>\n
    The reasoning was in the case of the acquire-release semantic more sophisticated than in the case of the sequential consistency<\/a>. But the possible values for x and y are the same. Only the combination y == 11 and x == 0 is no possible.<\/p>\n
    Three different interleavings of the threads are possible, producing the three different combinations of x and y.<\/p>\n
      \n
    1. thread1<\/span> will be executed before thread2<\/span>.<\/li>\n
    2. thread2<\/span> will be executed before thread1<\/span>.<\/li>\n
    3. thread1<\/span> executes x.store(2000)<\/span>, before thread2<\/span> will be\u00a0exectued.<\/li>\n<\/ol>\n
      At the end the table.<\/p>\n
      \"sukzessiveOptimierungSequenzielleKonsistenzEng\"<\/p>\n
      CppMem<\/h3>\n
      At first, the program once more with CppMem<\/a>.<\/p>\n
      <\/p>\n
      \n
      int<\/span> main(){\n  atomic_int x= 0; \n  atomic_int y= 0;\n  {{{ { \n      x.store(2000,memory_order_relaxed);\n      y.store(11,memory_order_release);\n      }\n  ||| {\n      y.load(memory_order_acquire);\n      x.load(memory_order_relaxed);\n      } \n  }}}\n}\n<\/pre>\n<\/div>\n
      We already know all results except of (y=11, x=0) are possible.<\/p>\n
      Possible executions<\/h3>\n
      Have a look at the three graphs with consistent execution. The graphs show an acquire-release semantics between the store-release of y and the load-acquire from y. It makes no difference if the reading of y (rf<\/span><\/strong>) occurs in the main thread or a separate thread. The graphs show the synchronizes-with relation with an sw <\/span>arrow.<\/p>\n
      Execution for (y=0, x= 0)<\/h4>\n
      \"first\"<\/p>\n
      Execution for (y= 0, x= 2000)<\/h4>\n
      \"second\"<\/p>\n
      Execution for (y=11, x= 2000)<\/h4>\n
      \"third\"<\/p>\n
      What’s next?<\/h2>\n
      But we can do better. Why should x be atomic? There is no reason. That was my first but incorrect assumption. Why? You will read it in the next post.<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
      With the acquire-release semantics, we break the sequential consistency. In the acquire-release semantics, synchronization occurs between atomic operations on the same atomic and not between threads.<\/p>\n","protected":false},"author":21,"featured_media":4849,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[369],"tags":[505,434,486,521],"class_list":["post-4853","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-multithreading-application","tag-acquire-release-semantic","tag-atomics","tag-cppmem","tag-ongoing-optimization"],"_links":{"self":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/4853","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=4853"}],"version-history":[{"count":2,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/4853\/revisions"}],"predecessor-version":[{"id":8535,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/4853\/revisions\/8535"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media\/4849"}],"wp:attachment":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media?parent=4853"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/categories?post=4853"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/tags?post=4853"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}