The Typical Misunderstanding of Acquire-Release Semantics

Clarifying the conditional nature of acquire-release ordering and avoiding common synchronization pitfalls in C++ lock-free code.

The Typical Misunderstanding of Acquire-Release Semantics

Overview

Modern C++ Concurrency Performance Pitfalls

Acquire-Release semantics do not create a global timing clock between threads. They only create ordering constraints within each individual thread.

The Common Fallacy

Many developers assume that if Thread A uses std::memory_order_release and Thread B uses std::memory_order_acquire, the CPU physically forces Thread B to wait or synchronizes their execution in real time.

That is incorrect. Acquire-Release semantics do not force Thread B to wait for Thread A. Instead, they establish a conditional contract: IF Thread B happens to read the value written by Thread A’s release store, THEN all memory writes made by Thread A before that store are guaranteed to be visible to Thread B.

Real-World Analogy: The Mailbox

Imagine two people interacting through a mailbox:

Person A (Producer / Release): Writes a letter, puts a package in the mailbox, and drops a flag on the mailbox indicating “Mail is inside.”
Person B (Consumer / Acquire): Checks the mailbox.

Misunderstanding vs. Actual Guarantee

The Misunderstanding: Dropping the flag does not magically teleport Person B to the mailbox, nor does it force Person B to check the mailbox at that exact millisecond. Person B might check the mailbox immediately, 10 minutes later, or never.
The Actual Guarantee: If Person B opens the mailbox and observes that the flag is up, Person B is 100% guaranteed to find the package inside as well.

Code Breakdown: What Can Go Wrong?

Consider two threads interacting with non-atomic data through an atomic flag:

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

std::atomic<int> myAtomic{0};
int data = 0;

void writeData() {
    data = 2026;                                  // 1. Write non-atomic payload
    myAtomic.store(1, std::memory_order_release); // 2. Release store
}

void readData() {
    // MISUNDERSTANDING: This single 'if' check DOES NOT wait for writeData()!
    if (myAtomic.load(std::memory_order_acquire) == 1) { 
        std::cout << data << std::endl; // Safe, but ONLY runs IF load saw 1!
    } else {
        std::cout << "Data not ready!" << std::endl;
    }
}

Execution Breakdown & Analysis

If readData() executes before writeData() sets myAtomic to 1, the if condition evaluates to false.

The program prints "Data not ready!" and continues execution. No error occurs, but no synchronization happens either because the acquire load never observed the value published by the release store.

Resolving the Issue: Active Waiting

To turn Acquire-Release into actual thread synchronization, the receiving thread must repeatedly poll the atomic variable until it successfully reads the released value:

void readDataCorrectly() {
    // Spin/poll until the acquire load reads the release value (1)
    while (myAtomic.load(std::memory_order_acquire) != 1) {
        // Waiting...
    }
    
    // NOW synchronization is established! Safe to read data.
    std::cout << data << std::endl; 
}

Key Takeaways

Conditional Contract: Acquire-Release is a contract that only takes effect after an acquire load successfully reads the specific value written by a release store.
No Automatic Waiting: It does not stop, pause, or delay a thread by default. You must implement a polling loop or use synchronization primitives if one thread must wait for another.
One-Way Directional Barriers:
- std::memory_order_release prevents preceding operations from being reordered below the store.
- std::memory_order_acquire prevents subsequent operations from being reordered above the load.