The Load-Store Queue lets your CPU reorder memory operations for performance. But reordering loads is speculation — the CPU is betting that no other core wrote to that address between when it speculatively loaded the value and when the load should have architecturally executed. The Memory Order Buffer (MOB) is what catches the CPU when it loses that bet.

Here's the scenario. Your code does load A; load B. The CPU executes load B first because A missed cache. Meanwhile, another core writes to B, then writes to A. Under x86's TSO model, your loads must appear to execute in program order — but you already returned the old B before seeing the new A. That's a memory ordering violation, and now you're running with wrong data.

The MOB prevents this by snooping the cache coherence traffic. Every speculatively-executed load records its address in the load buffer. When another core's invalidation message arrives for a cache line matching a not-yet-retired load, the MOB raises a machine clear — the entire pipeline is flushed back to that load and re-executed. It's like a branch misprediction, but for memory.

Real-world example: A producer-consumer ring buffer where the producer writes data then updates a tail pointer, and the consumer reads the tail then reads data. On a busy system, every consumer iteration that races a producer write triggers a machine_clears.memory_ordering event. You can see this with perf stat -e machine_clears.memory_ordering ./your_program. A well-tuned lock-free queue shows under 1000/sec; a poorly-tuned one shows millions/sec, and throughput collapses to roughly 1/10th of expected because each clear costs ~100+ cycles of refetch and re-execute.

Rule of thumb: A machine clear costs roughly the same as a full pipeline flush — about 50-200 cycles. If you see machine_clears.memory_ordering exceeding 0.1% of your retired instructions, you have contended cache lines being speculatively loaded. The fix is usually padding hot variables to separate cache lines (avoiding false sharing) or restructuring the producer/consumer to write less frequently.

This is also why pause instructions in spin loops aren't just power hints — they also tell the CPU to slow down speculative load issue, reducing the window where a speculative load can be invalidated and cause a machine clear. A tight spin without pause can saturate the MOB with doomed speculative loads, slowing the eventual real load when the lock is released.