x86 gives you three memory fence instructions, and their names suggest a clean symmetry: SFENCE for stores, LFENCE for loads, MFENCE for both. That mental model is wrong, and the wrongness is expensive.

Under x86-TSO, normal WB (write-back) memory already guarantees load-load, store-store, and load-store ordering. The only reordering the hardware allows is a later load passing an earlier store to a different address — the store buffer sits in front of loads, and loads read from cache while the store is still parked. Every fence exists to deal with this one hole, or with the weird memory types that sit outside TSO.

• SFENCE: Orders stores only relative to other stores, and only matters for weakly-ordered stores — non-temporal MOVNT, write-combining memory, CLFLUSHOPT, CLWB. For plain WB stores, SFENCE is nearly a no-op. It does not drain the store buffer.
• LFENCE: Officially "serializes loads," but its real job on modern Intel is to be a dispatch serializer — no younger instruction executes until every older one retires. Since Spectre it's the go-to speculation barrier. It doesn't drain the store buffer either.
• MFENCE: The only fence that drains the store buffer before any subsequent load executes. This is what plugs the store→load reordering hole. It's also the only one that gives you sequential consistency for a store followed by a load to a different address.

Concrete example — Dekker-style handshake:

Thread A: store x=1; load y;
Thread B: store y=1; load x;

Without a fence, both threads can see 0 because each load reads cache while its own store sits in the buffer. SFENCE won't fix it — it doesn't order stores against loads. LFENCE won't fix it — it doesn't drain the store buffer. You need MFENCE, or equivalently a LOCK-prefixed instruction (which also drains).

Rule of thumb for cost on Skylake-class cores:

• SFENCE: ~1 cycle if store buffer is quiet, ~40 cycles if it's flushing NT stores.
• LFENCE: ~4–6 cycles, purely a dispatch stall.
• MFENCE: ~30–100 cycles, because it must drain every outstanding store to L1.
• XCHG (implicit LOCK) is often faster than MFENCE — ~20–25 cycles — and gives the same ordering. GCC's __atomic_thread_fence(seq_cst) emits lock or [rsp], 0 for exactly this reason.

The asymmetry exists because x86 already gives you three-quarters of what "memory barrier" means for free. The fences only pay for the corners TSO refuses to close.