Acquire-Release Semantics – The Typical Misunderstanding

A release operation synchronizes-with an acquire operation on the same atomic variable. So we can easily synchronise threads, if … . Today’s post is about the if.

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.

Waiting included

I use this simple program as a starting point.

// acquireReleaseWithWaiting.cpp

#include <atomic>
#include <iostream>
#include <thread>
#include <vector>

std::vector<int> mySharedWork;
std::atomic<bool> dataProduced(false);

void dataProducer(){
    mySharedWork={1,0,3};
    dataProduced.store(true, std::memory_order_release);
}

void dataConsumer(){
    while( !dataProduced.load(std::memory_order_acquire) );
    mySharedWork[1]= 2;
}

int main(){
    
  std::cout << std::endl;

  std::thread t1(dataConsumer);
  std::thread t2(dataProducer);

  t1.join();
  t2.join();
  
  for (auto v: mySharedWork){
      std::cout << v << " ";
  }
      
  std::cout << "\n\n";
  
}

The consumer thread t1 in line 17 waits until the consumer thread t2 in line 13 has set dataProduced to true.dataPruduced is the guard because it guarantees access to the non-atomic variable mySharedWork is synchronized. That means, at first, the producer thread t2 initializes mySharedWork, then the consumer thread t2 finishes the work by setting mySharedWork[1] to 2. So the program is well-defined.

The graphic shows the happens-before relation within the threads and the synchronized-with relation between the threads. synchronize-with establishes a happens-before relation. The rest of the reasoning is the transitivity of the happens-before relation. mySharedWork={1,0,3} happens-before mySharedWork[1]= 2.

Modernes C++ Mentoring

"Fundamentals for C++ Professionals" (open)

"Design Patterns and Architectural Patterns with C++" (open)

"C++20: Get the Details" (open)

"Concurrency with Modern C++" (open)

"Generic Programming (Templates) with C++": October 2024

"Embedded Programming with Modern C++": October 2024

"Clean Code: Best Practices for Modern C++": March 2025

Do you want to stay informed: Subscribe.

But what aspect is often missing in this reasoning. The if.

If, …

What is happing if the consumer thread t2 in line 17 is not waiting for the producer thread?

// acquireReleaseWithoutWaiting.cpp

#include <atomic>
#include <iostream>
#include <thread>
#include <vector>

std::vector<int> mySharedWork;
std::atomic<bool> dataProduced(false);

void dataProducer(){
    mySharedWork={1,0,3};
    dataProduced.store(true, std::memory_order_release);
}

void dataConsumer(){
    dataProduced.load(std::memory_order_acquire);
    mySharedWork[1]= 2;
}

int main(){
    
  std::cout << std::endl;

  std::thread t1(dataConsumer);
  std::thread t2(dataProducer);

  t1.join();
  t2.join();
  
  for (auto v: mySharedWork){
      std::cout << v << " ";
  }
      
  std::cout << "\n\n";
  
}

The program has undefined behavior because there is a data race on the variable mySharedWork. In case I let the program run, the undefined behavior gets immediately visible. That holds for Linux and Windows.

What’s the issue? It holds: store(true, std::memory_order_release) synchronizes-with dataProduced.load(std::memory_order_acquire). 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 dataProduced.load(std::memory_order_acquire) instruction is performed before the instruction dataProduced.store(true, std::memory_order_release). So we have no synchronize-with relation.

The solution

synchronize-with means in this specific case: If dataProduced.store(true, std::memory_order_release) happens before dataProduced.load(std::memory_order_acquire), then all visible effects of operations before dataProduced.store(true, std::memory_order_release) are visible after dataProduced.load(std::memory_order_acquire). The key is the word if. Exactly that if will be guaranteed in the first program with (while(!dataProduced.load(std::memory_order_acquire)).

Once again, but formal.

All operations before dataProduced.store(true, std::memory_order_release)happens-before all operations after dataProduced.load(std::memory_order_acquire), if holds: dataProduced.store(true, std::memory_order_release) happens-before dataProduced.load(std::memory_order_acquire).

What’s next?

Acquire-release semantic with operations on atomic variables. Does this work? Yeah, with fences. Have a look at the next post.

Post Views: 6,278

Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Stephen Kelley, Kyle Dean, Tusar Palauri, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, Marco Parri Empoli, Philipp Lenk, Charles-Jianye Chen, Keith Jeffery, Matt Godbolt, and Honey Sukesan.

Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.

My special thanks to Embarcadero
My special thanks to PVS-Studio
My special thanks to Tipi.build
My special thanks to Take Up Code
My special thanks to SHAVEDYAKS