Atomics, Memory Ordering & Lock-Free — Races, Barriers & When Locks Win

Overview

Most bugs labeled "race" are one of two different failures. A data race is a conflicting access with no happens-before edge. In C++ and Rust that is undefined behavior: the compiler may delete the check. A race condition is a timing-dependent logic bug that can happen even when every access is synchronized. Check-then-act on a balance is the usual example.

This cluster is process-local shared memory: atomics, the C++11 / Java / Go / Rust mental model, CAS loops, lock-free stacks and queues, ABA, and the honest case where a mutex still wins. It does not re-teach condition variables or distributed leases.

By the end of the cluster you should be able to:

• Distinguish a data race from a race condition and name the happens-before edges that close a data race.
• Write a CAS loop and say whether it is wait-free, lock-free, or just a spinlock.
• Choose relaxed, acquire/release, or seq_cst, and know what seq_cst costs on ARM.
• Sketch a Treiber stack, an SPSC ring, and one ABA mitigation.
• Decide from contention, fairness, and review cost when the mutex stays.

Why this shows up in production

Teams reach for AtomicInteger, std::atomic, sync/atomic, or AtomicUsize when a counter must stay coherent, when a mutex is bouncing a cache line, or when a runtime already lives in lock-free code. The failures are quiet:

• A torn 64-bit write on a 32-bit ABI, or a wide struct that was never one word.
• A reorder that is invisible on a laptop and broken on ARM.
• ABA after a freelist reuses a node.
• A CAS spin that pegs CPUs a short critical section would have parked.

Interviews ask whether you can talk about visibility and progress, not whether you can spell synchronized.

Mutex, atomics, and channels

Start with a mutex when the invariant spans fields. Promote a single word to an atomic when a profile says the lock is hot and the protocol stays one word. Prefer a channel when you can stop sharing the memory. Do not invent a lock-free map on the day of a launch.

flowchart TB
  a["Shared mutable state?"]
  b["Copy or pass ownership"]
  c["One word or flag?"]
  d["Mutex for the invariant"]
  a -->|No| b
  a -->|Yes| c
  c -->|No| d

If the word is a custom structure, the next question is whether you will own ABA and reclamation. If you will not, the arrow goes back to the mutex. That choice is when locks win.

What this cluster covers

1. Data races - undefined behavior, happens-before, and the tools that see it.
2. CAS - RMW, retry loops, and progress guarantees.
3. Memory ordering - relaxed, acquire/release, seq_cst, and fences.
4. Lock-free structures - stacks, queues, SPSC rings, and ABA.
5. When locks win - contention, fairness, and hybrids.

The ring returns here after the last page.

Happens-before, at hub level

Thread A happens-before thread B's observation when a synchronization edge connects them: unlock then a later lock of the same mutex, a release store then an acquire load that sees that store, or thread start and join. Without that edge, a non-atomic read of another thread's write is a data race. C++ and Rust call that undefined behavior. Java can still surprise you. Go's race detector flags it. The full edge list is the next page.

Say it in this order in an interview:

1. Publish the payload first. It can be non-atomic if the flag will carry the edge.
2. Release-store the flag or pointer so earlier writes become visible.
3. Acquire-load that same flag.
4. Read the payload only after the acquire succeeds.
5. A relaxed flag does not publish the payload. The data itself must be atomic or immutable, and you should be able to prove it.

What each primitive costs

Progress words you must not mix up

Lock-free is not wait-free. It is not "no lock anywhere in the process" (the allocator may lock). It is not faster under contention. Using an atomic inside a method that also takes a lock does not make the method lock-free.

Sandbox

The first snippet models a lost update: both workers read the same value and both write their own increment. The second is one atomic RMW, so both increments stick. Neither snippet needs a real thread. The bug is the split read and write.

Press Run. Snippets must be self-contained — no network, files, or native modules.

Press Run. Snippets must be self-contained — no network, files, or native modules.

A Go counter with sync/atomic is the same RMW, expressed with the race detector available:

var n atomic.Int64
var wg sync.WaitGroup
for i := 0; i < 4; i++ {
    wg.Add(1)
    go func() {
        defer wg.Done()
        for j := 0; j < 100000; j++ {
            n.Add(1)
        }
    }()
}
wg.Wait()
fmt.Println(n.Load())

CPython's GIL often hides a torn x += 1. That does not make the increment atomic on a free-threaded build, on PyPy, or in a C extension. Prefer a real atomic or a lock.

Interview Q&A

Pitfalls

• Calling a relaxed counter a publish protocol.
• Splitting one increment into a load and a store and calling each half atomic.
• Testing only on x86 and treating that as a memory model.
• Holding a "lock-free" path that takes a mutex on failure and then advertising lock-free.
• Rewriting the mutex tutorial or a Redis lease while answering an ABA question.

Go Deeper

• Jeff Preshing, memory barriers are like source control operations, and the acquire/release series on the same site.
• Herb Sutter, atomic weapons.
• Rustonomicon atomics and Go's sync/atomic.
• LLVM atomics and C++ memory_order.

Next: Data races.