{"id":4829,"date":"2016-07-21T15:59:42","date_gmt":"2016-07-21T15:59:42","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/acquire-release-fences\/"},"modified":"2023-06-26T12:49:09","modified_gmt":"2023-06-26T12:49:09","slug":"acquire-release-fences","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/acquire-release-fences\/","title":{"rendered":"Acquire-Release Fences"},"content":{"rendered":"

Acquire and release fences guarantee similar synchronization and ordering constraints<\/a> as atomics with acquire-release <\/a>semantics. Similar because the differences are in the details.<\/p>\n

<\/p>\n

The most apparent difference between acquire and release memory barriers (fences) and atomics with acquire-release semantics is that memory barriers need no operations on atomics. But there is a more subtle difference. The acquire and release memory barriers are more heavyweight.<\/p>\n

Atomic operations versus memory barriers<\/h2>\n

To simplify my writing job, I will now speak of acquire operations if I use memory barriers or atomic operations with acquire semantics. The same will hold for release operations.<\/p>\n

The key idea of an acquire and a release operation is that it establishes synchronizations and ordering constraints between threads. This will also hold for atomic operations with relaxed semantic or non-atomic operations. So you see, the acquire and release operations come in pairs. In addition, the operations on atomic variables with acquire-release semantic must hold that these act on the same atomic variable. Said that I will, in the first step, look at these operations in isolation.<\/p>\n

I start with the acquire operation.<\/p>\n<\/p>\n

Acquire operation<\/h3>\n

A read operation on an atomic variable attached with std::memory_order_acquire<\/span> is an acquire operation.<\/p>\n

 <\/p>\n

\"acquireOperation\" <\/p>\n

In opposite to that, there is the std::atomic_thread_fence<\/span> with acquire semantics.<\/p>\n

\"acquireFence\"<\/p>\n

This comparison emphasises two points.<\/p>\n

    \n
  1. A memory barrier with acquire semantics establishes stronger ordering constraints. Although the acquire operation on an atomic and a memory barrier requires that no read or write operation can be moved before the acquire operation, there is an additional guarantee with the acquire memory barrier. No read operation can be moved after the acquire memory barrier.<\/li>\n
  2. The relaxed semantic is sufficient for the reading of the atomic variable var<\/span>. The std::atomc_thread_fence(std::memory_order_acquire)<\/span> ensures that this operation can not be moved after the acquire fence.<\/li>\n<\/ol>\n

    The similar statement holds for the release memory barrier.<\/p>\n

    Release operation<\/h3>\n

    The write operation on an atomic variable attached to the memory model std::memory_order_release is a release operation.<\/p>\n

     \"releaseOperation\"<\/p>\n

    And further the release memory barrier.<\/p>\n

    \"releaseFence\"<\/p>\n

    In addition to the release operation on an atomic variable var,<\/span> the release barrier guarantees two points:<\/span><\/p>\n

      \n
    1. Store operations can’t be moved before the memory barrier.<\/li>\n
    2. It’s sufficient for the variable var<\/span> to have relaxed semantics.<\/span><\/li>\n<\/ol>\n

      If you want a simple overview of memory barriers, please read the last post in this blog. But now, I want to go one step further and build a program out of the presented components.<\/p>\n

      Synchronization with atomic operations versus memory barriers<\/h2>\n

      I implement it as a starting point for comparing a typical consumer-producer workflow with acquire-release semantics. I will do this job with atomics and memory barriers.<\/p>\n

      Let’s start with atomics because most of us are comfortable with them. That will not hold for memory barriers. They are almost completely ignored in the literature on the C++ memory model.<\/p>\n

      Atomic operations<\/h3>\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
      \/\/ acquireRelease.cpp<\/span>\r\n\r\n#include <atomic><\/span>\r\n#include <thread><\/span>\r\n#include <iostream><\/span>\r\n#include <string><\/span>\r\n \r\nstd::atomic<std::string*> ptr;\r\nint<\/span> data;\r\nstd::atomic<int<\/span>> atoData;\r\n \r\nvoid<\/span> producer(){\r\n    std::string* p  = new<\/span> std::string(\"C++11\"<\/span>);\r\n    data = 2011;\r\n    atoData.store(2014,std::memory_order_relaxed);\r\n    ptr.store(p, std::memory_order_release);\r\n}\r\n \r\nvoid<\/span> consumer(){\r\n    std::string* p2;\r\n    while<\/span> (!(p2 = ptr.load(std::memory_order_acquire)));\r\n    std::cout << \"*p2: \"<\/span> << *p2 << std::endl;\r\n    std::cout << \"data: \"<\/span> << data << std::endl;\r\n    std::cout << \"atoData: \"<\/span> << atoData.load(std::memory_order_relaxed) << std::endl;\r\n}\r\n \r\nint<\/span> main(){\r\n    \r\n    std::cout << std::endl;\r\n    \r\n    std::thread<\/span> t1(producer);\r\n    std::thread<\/span> t2(consumer);\r\n    \r\n    t1.join();\r\n    t2.join();\r\n    \r\n    delete<\/span> ptr;\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
      I hope this program looks familiar to you. That is the classic that I used in the post to memory_order_consume<\/a>. The graphic directly explains why the consumer thread t2 sees all values from the producer thread t1.<\/p>\n
      \"acquireRelease\"<\/p>\n
      The program is well-defined, because the happens-before<\/em> relation is transitive. I have only to combine the three happens-before<\/span> relations:<\/p>\n
        \n
      1. Line 13 – 15 happens-before<\/em> line 16 (ptr.store(p,std::memory_order_release)<\/span>.<\/li>\n
      2. Line 21 while(!(p2= ptrl.load(std::memory_order_acquire)))<\/span> happens-before <\/em>lines 22 – 24.<\/li>\n
      3. Line 16 synchronizes-with<\/em> line 21. =><\/span><\/strong> Line 16 happens-before<\/em> line 21.<\/li>\n<\/ol>\n
         <\/p>\n
        But now the story gets more thrilling. How can I adjust the workflow to memory barriers?<\/p>\n
        Memory barriers<\/h3>\n
        It’s straightforward to port the program to memory barriers.<\/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<\/pre>\n<\/td>\n
        		\n
        \/\/ acquireReleaseFences.cpp<\/span>\r\n\r\n#include <atomic><\/span>\r\n#include <thread><\/span>\r\n#include <iostream><\/span>\r\n#include <string><\/span>\r\n \r\nstd::atomic<std::string*> ptr;\r\nint<\/span> data;\r\nstd::atomic<int<\/span>> atoData;\r\n \r\nvoid<\/span> producer(){\r\n    std::string* p  = new<\/span> std::string(\"C++11\"<\/span>);\r\n    data = 2011;\r\n    atoData.store(2014,std::memory_order_relaxed);\r\n    std::atomic_thread_fence(std::memory_order_release);\r\n    ptr.store(p, std::memory_order_relaxed);\r\n}\r\n \r\nvoid<\/span> consumer(){\r\n    std::string* p2;\r\n    while<\/span> (!(p2 = ptr.load(std::memory_order_relaxed)));\r\n    std::atomic_thread_fence(std::memory_order_acquire);\r\n    std::cout << \"*p2: \"<\/span> << *p2 << std::endl;\r\n    std::cout << \"data: \"<\/span> << data << std::endl;\r\n    std::cout << \"atoData: \"<\/span> << atoData.load(std::memory_order_relaxed) << std::endl;\r\n}\r\n \r\nint<\/span> main(){\r\n    \r\n    std::cout << std::endl;\r\n    \r\n    std::thread<\/span> t1(producer);\r\n    std::thread<\/span> t2(consumer);\r\n    \r\n    t1.join();\r\n    t2.join();\r\n    \r\n    delete<\/span> ptr;\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 first step is to insert just in place of the operations with acquire and release semantic the corresponding memory barriers with acquire and release semantics (lines 16 and 23). In the next step, I change the atomic operations with acquire or release semantics to relaxed semantics (lines 17 and 22). That was already mechanical. Of course, I can only replace one acquire or release operation with the corresponding memory barrier. The key point is that the release operation establishes with the acquire operation a synchronize-with<\/em> relation and, therefore, a happens-before<\/em> relation.<\/p>\n
        For the more visual reader, the whole description in a picture.<\/p>\n
        \"acquireReleaseFences\"<\/p>\n
        The key question is. Why do the operations after the acquire memory barrier sees the effects of the operations before the release memory barrier? Because data<\/span> is a non-atomic variable and atoData<\/span> is used with relaxed semantics, both can be reordered. But that’s not possible. The std::atomic_thread_fence(std::memory_order_release)<\/span> as a release operation in combination with the std::atomic_thread_fence(std::memory_order_acquire)<\/span> forbids the partial reordering. To follow my reasoning in detail, read the analysis of the memory barriers at the beginning of the post.<\/p>\n
        For clarity, the whole reasoning is to the point.<\/p>\n
          \n
        1. The acquire and release memory barriers prevent the reordering of the atomic and non-atomic operations across the memory barriers.<\/li>\n
        2. The consumer thread t2<\/span> is waiting in the while (!(p2= ptr.load(std::memory_order_relaxed)))<\/span> loop until the pointer ptr.stor(p,std::memory_order_relaxed) <\/span>is set in the producer thread t1.
          <\/span><\/li>\n
        3. The release memory barrier synchronizes-with<\/em> the acquire memory barrier.<\/li>\n<\/ol>\n
          Finally, the output of the programs.<\/p>\n
          \"acquireReleaseAcquireReleaseFences\"<\/p>\n
          What’s next?<\/h2>\n
          But now, to the weakest memory model. The relaxed semantics will be the topic of the next post<\/a>. There are no ordering constraints. <\/p>\n
           <\/p>\n
           <\/p>\n
           <\/p><\/p>\n","protected":false},"excerpt":{"rendered":"
          Acquire and release fences guarantee similar synchronization and ordering constraints as atomics with acquire-release semantics. Similar because the differences are in the details.<\/p>\n","protected":false},"author":21,"featured_media":4824,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[368],"tags":[505,522,434],"class_list":["post-4829","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-multithreading-memory-model","tag-acquire-release-semantic","tag-atomic_thread_fence","tag-atomics"],"_links":{"self":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/4829","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=4829"}],"version-history":[{"count":1,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/4829\/revisions"}],"predecessor-version":[{"id":6962,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/4829\/revisions\/6962"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media\/4824"}],"wp:attachment":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media?parent=4829"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/categories?post=4829"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/tags?post=4829"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}