Memory visibility & the memory model

Why a write can go missing

Reading and writing main memory is slow — hundreds of times slower than a CPU instruction. So every core keeps a small private cache and a store buffer in front of it. When a thread writes a variable, the value first lands in that core's private storage; hardware will push it out to RAM and invalidate other cores' copies eventually, but your program's rules don't promise when. Meanwhile the other core happily serves reads out of its cache, which still holds the old value.

• The core's cache — a private copy of the data each core is working on. Two cores can hold two different values for the same variable at the same moment.
• The store buffer — a write queue in front of the cache, so the core doesn't stall waiting for memory. A write parked here hasn't reached anybody else yet.
• Registers — the fastest storage of all, and the one that isn't memory at all. If the compiler decides to keep done in a register, no cache protocol on earth can help you: the thread has stopped reading memory.

The infinite-spin bug

This is the canonical example, and it's mostly a compiler bug rather than a hardware one. You write a loop that waits for a flag. The compiler notices that inside the loop body nothing ever assigns to done, so re-reading it every iteration is (from this thread's point of view) pointless work. So it hoists the read out of the loop into a register:

// what you wrote                      // what the JIT is allowed to run
boolean done = false;                   boolean r1 = done;      // read ONCE
                                        if (!r1) {
while (!done) {          ───────▶           while (true) { }    // never re-reads
    // spin                             }
}

That transformation is perfectly legal, because it is invisible in a single thread: no single-threaded program could tell the difference. It becomes catastrophic the moment another thread writes the flag. Marking the field volatile removes the compiler's permission: every read must go to the shared location, every write must go to the shared location.

What volatile actually promises

• A volatile read is guaranteed to see the most recent write — no register copy, no stale cache line. Read the whiteboard, not your notebook.
• A volatile write is immediately made visible to any thread that subsequently reads that variable. Write on the whiteboard, not in your notebook.
• No reordering across it — the compiler and CPU may not move ordinary reads/writes across a volatile access in a way another thread could observe. Everything Amy wrote before putting the flag on the board is on the board too.
• No atomicity. volatile does not make a read-modify-write indivisible. It is a visibility and ordering tool, full stop.

class Worker implements Runnable {
    private volatile boolean done = false;   // ← the whole fix

    public void run() {
        while (!done) {        // volatile read: goes to shared memory every time
            doWork();
        }
    }

    public void stop() {
        done = true;           // volatile write: published immediately
    }
}

Reordering: the second surprise

The compiler and the CPU may execute independent statements out of order — again, because it's undetectable from inside one thread. Write data = 42; then ready = true; and another thread may genuinely observe ready == true while data is still 0. It saw the flag before the payload. This is the ⇄ Swap demo in the prototype, and it is the reason "set the data, then set the flag" is not, by itself, safe. Making ready volatile fixes it: everything written before the volatile write is visible to anyone who reads that volatile and sees the new value.

Happens-before, in plain words

Happens-before is the rule the memory model uses to answer "is this write guaranteed visible?". It is not about wall-clock time. It means: if action A happens-before action B, then everything A wrote is guaranteed to be visible to B. If there is no happens-before edge between two actions, the memory model promises you nothing at all — and "nothing" includes never. You create these edges with a small, fixed set of moves:

• Unlock → lock on the same lock. Everything a thread did before releasing a lock is visible to the next thread that acquires it. This is why consistent locking gives you visibility for free.
• Volatile write → volatile read of the same variable. Same deal, without the exclusion.
• Thread.start() — everything the parent did before starting a thread is visible to that new thread.
• Thread.join() — everything the finished thread did is visible to whoever joins it.
• Final-field publication — a properly constructed object's final fields are visible to any thread that gets a reference to it, with no extra synchronization.
• Transitivity — if A happens-before B and B happens-before C, then A happens-before C. Edges chain.

Safe publication and the half-built object

The nastiest version of this bug isn't a boolean, it's an object. Thread A does config = new Config(...) and thread B reads config. Without a happens-before edge, B can see a non-null reference to a half-constructed object: the reference write became visible before the writes that filled in the fields. B reads config.timeout and gets 0. Publishing an object safely means handing it over across a happens-before edge — store it in a volatile field or an AtomicReference, store it while holding a lock that readers also hold, initialise it in a static initialiser, or make it immutable with all-final fields.

One line per language

• Java — the Java Memory Model (rewritten by JSR-133 in Java 5) is the specification that defines happens-before, volatile, final-field safety, and what a data race is; before JSR-133, volatile and double-checked locking were genuinely broken.
• C++ — std::atomic<T> with memory orders: the default memory_order_seq_cst is the safe, intuitive one (a single global order everyone agrees on); memory_order_relaxed is faster but gives you visibility with no ordering, and acquire/release is the middle ground. A plain data race in C++ is formally undefined behaviour, not just a wrong answer.
• Go — the official advice from the Go memory model is don't be clever: "Don't communicate by sharing memory; share memory by communicating." Use channels, sync.Mutex, or sync/atomic — and run your tests with the built-in race detector (go test -race), which catches missing happens-before edges at runtime.
• Python — CPython's GIL makes many races look impossible, but it does not make compound operations atomic and it is not a portable guarantee. Use threading.Event, Lock, or queue.Queue to publish state between threads.

Reach for volatile when...

• One thread writes a simple flag, others only read it — a running/shutdown boolean, a "config reloaded" marker. This is volatile's home turf and a lock would be pure overhead.
• You publish an immutable object by swapping a reference — build it fully, then assign it to a volatile field. Readers either see the old object or the fully-built new one, never a half-built one.
• A value is written independently of its previous value — that's the dividing line. If the new value doesn't depend on the old one, volatile is enough.
• Double-checked locking — the classic lazy singleton needs the instance field to be volatile, or a second thread can get a non-null reference to a half-constructed object.

Use a lock or an atomic instead when...

• The operation is read-modify-write — counters, check-then-act, if (map.get(k) == null) map.put(k, v). Use AtomicInteger/std::atomic/sync/atomic, or a lock.
• Two or more fields must change together — volatile protects one variable at a time and can't give you an all-or-nothing update across several.
• You already hold a lock on that state everywhere — then stop worrying: consistent locking already gives you visibility, and adding volatile on top just adds noise.
• You're reaching for relaxed memory orders to go faster — measure first. Almost every real bottleneck is elsewhere, and relaxed ordering is one of the easiest ways to write code that is wrong only on some machines.