{"id":4807,"date":"2016-07-12T06:08:00","date_gmt":"2016-07-12T06:08:00","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/transivity-of-the-acquire-release-semantic\/"},"modified":"2025-02-06T16:16:05","modified_gmt":"2025-02-06T16:16:05","slug":"transivity-of-the-acquire-release-semantic","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/transivity-of-the-acquire-release-semantic\/","title":{"rendered":"Transitivity of the Acquire-Release Semantic"},"content":{"rendered":"

A release operation synchronizes with an acquire operation on the same atomic variable and establishes, in addition, ordering constraints. These are the components to synchronize threads in a performant way in case they act on the same atomic. But how can that work, if two threads share no atomic variable? We want no sequential consistency because that is too heavy. We want the light acquire-release semantic.<\/p>\n

<\/p>\n

The answer to the riddle is easy. Because of the transitivity of the acquire-release semantic, threads can be synchronized, which act independently of each other.<\/p>\n

Transitivity<\/h2>\n

In the following example, thread t2<\/span>, with its work package deliveryBoy <\/span>is the glue between the two independent threads t1<\/span> and t3<\/span>.<\/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\n26\n27\n28\n29\n30\n31\n32\n33\n34\n35\n36\n37\n38\n39\n40\n41\n42\n43\n44\n45<\/pre>\n<\/td>\n
\n
\/\/ transitivity.cpp<\/span>\n\n#include <atomic><\/span>\n#include <iostream><\/span>\n#include <thread><\/span>\n#include <vector><\/span>\n\nstd::vector<int<\/span>> mySharedWork;\nstd::atomic<bool<\/span>> dataProduced(false);\nstd::atomic<bool<\/span>> dataConsumed(false);\n\nvoid<\/span> dataProducer(){\n    mySharedWork={1,0,3};\n    dataProduced.store(true, std::memory_order_release);\n}\n\nvoid<\/span> deliveryBoy(){\n    while<\/span>( !dataProduced.load(std::memory_order_acquire) );\n    dataConsumed.store(true,std::memory_order_release);\n}\n\nvoid<\/span> dataConsumer(){\n    while<\/span>( !dataConsumed.load(std::memory_order_acquire) );\n    mySharedWork[1]= 2;\n}\n\nint<\/span> main(){\n    \n  std::cout << std::endl;\n\n  std::thread<\/span> t1(dataConsumer);\n  std::thread<\/span> t2(deliveryBoy);\n  std::thread<\/span> t3(dataProducer);\n\n  t1.join();\n  t2.join();\n  t3.join();\n  \n  for<\/span> (auto<\/span> v: mySharedWork){\n      std::cout << v << \" \"<\/span>;\n  }\n      \n  std::cout << \"\\n\\n\"<\/span>;\n  \n}\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
The output of the program is deterministic. mySharedWork<\/span> will have the values 1,2, and 3.<\/p>\n
\"trans\"<\/p>\n
Why is the program deterministic? There are two critical observations:<\/p>\n
    \n
  1. Thread t2<\/span> waits in line 18 until thread t1<\/span> has set dataProduced<\/span> on true<\/span> (line 14).<\/li>\n
  2. Thread t3<\/span> waits in line 23 until thread t2<\/span> has set dataConsumed<\/span> on true<\/span> (line 19).<\/li>\n<\/ol>\n
    The rest is easier explained with a picture.<\/p>\n
    \"transitivity\"<\/p>\n
    The critical parts of the picture are the arrows.<\/p>\n