Atomics, CAS Loops, Memory Ordering & Thread-Safe Singleton

Even though ++counter looks like a single line of C++, modern hardware executes it as three separate machine steps:

1. Load (Read): The CPU core reads the value of counter from its L1/L2 cache line into an internal general-purpose register (EAX / W0).
2. Modify: The ALU increments the register value by 1 (add eax, 1).
3. Store (Write): The CPU writes the updated register value back to the cache line.

The Interleaving Disaster

If Thread A and Thread B both read counter == 10 concurrently:

• Thread A increments its register to 11.
• Thread B increments its register to 11.
• Both write 11 back to memory. Two increments happened, but the counter only advanced by 1!

This is a classic Read-Modify-Write (RMW) data race, invoking Undefined Behavior (UB) under ISO C++.

The Hardware Fix: Wrapping the integer in std::atomic<int> instructs the CPU to emit a hardware-locked atomic instruction (such as LOCK XADD on x86). The CPU locks the cache line across all cores during the read, increment, and write, preventing clobbered updates.

Atomic variables provide built-in operations for addition and subtraction (fetch_add, fetch_sub). But what if you need an atomic fetch_max or need to update the head pointer of a lock-free stack?

The universal building block for custom atomic transitions is Compare-And-Swap (CAS).

How CAS Works Mechanically

atomic.compare_exchange_weak(expected, desired) performs a single atomic check:

1. Match: Does atomic equal expected? If yes, replace atomic with desired and return true.
2. Mismatch: If another thread modified atomic in the meantime, leave atomic untouched, overwrite expected with the new actual value, and return false.

Weak vs Strong CAS in C++

• compare_exchange_weak (For Retry Loops): May fail spuriously (return false even if values matched) on architectures like ARM (Load-Linked / Store-Conditional) due to cache line invalidations or interrupts. Because it runs inside a while loop that will retry anyway, weak compiles to leaner, faster machine code.
• compare_exchange_strong (For Single Checks): Guarantees failure occurs only when the actual value does not match expected. Use this when CAS is executed once without a retry loop.

By default, every operation on std::atomic uses std::memory_order_seq_cst (Sequentially Consistent). While safe, it imposes a single global timeline across all cores, requiring pipeline-stalling hardware memory barriers (MFENCE).

Modern C++ defines 3 practical memory models:

1. Relaxed (memory_order_relaxed):

   • Guarantees atomicity of that single variable only.
   • Imposes zero ordering constraints with other variables. Fastest possible atomic operation; ideal for standalone counters and metrics.

2. Acquire-Release (memory_order_acquire / release):

   • The Producer-Consumer Boundary:
     • Release Store: "Ensure all my prior memory writes (even plain non-atomic data) commit before marking this flag visible."
     • Acquire Load: "Do not read any payload data until after reading this flag as ready."
   • An acquire load observing a release store forms a synchronizes-with boundary. All preceding writes become safely visible to the consumer without a mutex.

3. Sequential Consistency (memory_order_seq_cst):

   • All cores observe all seq_cst operations in the exact same global order. Safest default, but carries the highest hardware overhead.

In early C++, developers tried to optimize singleton access using Double-Checked Locking (DCLP) to avoid acquiring a mutex on every read:

// BROKEN CLASSIC DCLP:
if (instance == nullptr) {           // 1. Check without lock
    std::lock_guard<std::mutex> lock(mtx);
    if (instance == nullptr) {       // 2. Check with lock
        instance = new Singleton();  // 3. HAZARD: Memory corruption!
    }
}

The Mechanical Reordering Trap

The statement instance = new Singleton() involves three distinct machine operations:

1. Allocate Memory: void* rawMem = operator new(sizeof(Singleton))
2. Construct Object: new (rawMem) Singleton()
3. Assign Pointer: instance = static_cast<Singleton*>(rawMem)

The Hazard: Modern compilers and out-of-order CPUs can reorder step 3 before step 2! instance becomes non-null in memory before the constructor finishes running.

• A concurrent Thread B arrives at the first check if (instance == nullptr).
• It observes a non-null pointer, skips the lock, and returns instance.
• Thread B immediately accesses a half-constructed object, causing memory corruption and segmentation faults!

Modern C++ completely eliminates the need for manual DCLP with two language-guaranteed idioms:

1. Idiom 1: Meyers' Singleton (C++11 Magic Statics - Recommended):

   • Declare a static ClassName instance; inside a function.
   • Under Section §6.7 of the ISO C++ standard, block-scope static variables are guaranteed thread-safe by the compiler and runtime.
   • The compiler automatically injects an atomic guard byte check. The first thread to enter acquires the initialization lock; other threads wait. Subsequent calls compile to a single relaxed read of the guard byte (~0.5 ns).

2. Idiom 2: std::call_once with std::once_flag:

   • Used when initialization requires runtime arguments or custom dynamic heap allocation.
   • Guarantees the initialization lambda executes exactly once across all threads, cleanly propagating exceptions if initialization fails.