the abstract memory model

Imagine two people editing the same shared document. If you only know what each person typed, but never the order the edits actually landed, you cannot reason about the final text at all. A memory model is the rulebook that pins down exactly what one thread is allowed to SEE of what another thread wrote, and in what order. Without such a rulebook, multi-threaded code has no defined meaning.

Concretely, a language-level memory model (C11, C++11, and Rust all share essentially the same one) defines the abstract machine's view of shared memory: which writes are guaranteed visible to which reads, and which reorderings of operations a correct program is allowed to observe. It is deliberately abstract — it does NOT say 'this runs on x86' or 'this uses a cache'. Instead it gives you a small vocabulary (atomic operations, memory orderings, the happens-before relation) and a contract: if you use that vocabulary correctly, your program behaves as if there were a single consistent order of the relevant operations.

Why have one at all? Because both the compiler and the CPU aggressively reorder, cache, and eliminate memory operations to go fast, and those transformations are invisible in single-threaded code but become visible the instant a second thread observes the same memory. The memory model is the precise, portable boundary that says: here is what the optimizer and the hardware are still required to preserve. Everything else in this field — atomics, fences, orderings — is just the concrete machinery this model is built from.