Why are compilers and CPUs allowed to execute memory reads and writes in an order different from the source code, and what rule limits how far they can go?

## The core idea The order in which memory operations appear in your source is not the order in which they execute, nor the order in which other threads observe them. That is not a toolchain bug; it is the bargain every mainstream language and CPU makes in exchange for speed. ## Two independent reorderers **The compiler.** An optimizer treats memory access as data flow, not as a script. It hoists a load out of a loop into a register (so a later change by another thread is never re-read), sinks a store past other work, merges two stores into one, deletes a store that is overwritten later, and reassociates independent expressions. Every one of these changes when — or whether — a value hits memory. **The hardware.** Modern cores post stores into a *store buffer* and retire the instruction before the value is visible to other cores; they execute independent instructions out of order; they prefetch and speculate past branches; some architectures let two loads complete out of order. The commit order of memory operations is not the program order. ## The only rule they honour: as-if-serial Both layers preserve the illusion for *one* thread in isolation: a thread always sees its own writes, and dependencies within the thread (this load feeds that add) are respected. Formally, they may reorder any two operations that are not related by a dependency the single-thread semantics can detect. The crucial gap: dependency analysis is per-thread. Two stores to *different* locations have no dependency, so their order is arbitrary from outside. Two loads of different locations, likewise. The optimizer literally cannot see the other thread that cares. ## What this breaks The classic publication idiom: ``` Producer: Consumer: data = 42 while (!ready) {} ready = true use(data) ``` Without synchronization, four things can go wrong: the producer's two stores commit in the opposite order; the consumer's `use(data)` load is hoisted above the loop by the compiler or executed early by speculation; the consumer's `ready` load is hoisted out of the loop into a register and spins forever; or `data` is read from a stale cached value. Any of these yields `use(0)` or a hang. The code is *racy*, and a racy program has no defined ordering at all. ## Where ordering comes from A memory model is a contract: the program marks the few places where cross-thread order matters, and the implementation is free everywhere else. The markers are synchronization — acquiring and releasing a lock, an ordered atomic read/write, a fence instruction, thread start/join. At those points the compiler suppresses motion across the marker and emits whatever hardware barrier the target architecture needs. Everything between markers stays fully optimizable, which is exactly why the model is worth having. ## Why 'it works on my machine' proves nothing Strong hardware (x86-family, TSO) hides most reordering, and an unoptimized debug build hides most compiler motion. The same source on a weakly ordered CPU, or at a higher optimization level, or after a JIT recompiles a hot loop, can expose it immediately. Testing cannot establish ordering; only the synchronization you wrote can. ## What to say in an interview Name both layers, state as-if-serial as the single constraint, point out that it is per-thread and therefore blind to other observers, and conclude that cross-thread order must be requested explicitly. That framing is the whole answer.