False Sharing & Memory Barriers

Modern CPUs have multiple cores, each with its own L1/L2 cache. Cache coherence protocols (like MESI) ensure that when one core writes to a cache line, other cores’ copies are invalidated. This creates subtle performance traps.

Cache Lines

Memory is transferred between RAM and CPU caches in fixed-size blocks called cache lines (typically 64 bytes on x86). If a program accesses a single byte, the entire 64-byte block is loaded into the cache.

False Sharing

Two threads access different variables that happen to sit on the same cache line. Neither thread uses the other’s variable, but the cache coherence protocol treats them as the same line.

Thread A writes to x (on cache line N)
→ Core B's copy of line N is invalidated
Thread B writes to y (on the same line N)
→ Core A's copy of line N is invalidated
→ Both cores keep reloading the same line

Result: performance collapses — up to 100x slower. Neither thread shares data (no real sharing), but the hardware treats it as sharing. Hence “false sharing.”

Fix: Padding

// Before: x and y share a cache line
struct { int x; int y; };

// After: padded to separate cache lines
struct { int x; char pad[64]; int y; };

Memory Barriers (Fences)

CPUs reorder memory operations for performance. A memory barrier prevents reordering around the barrier.

// Thread 1                    Thread 2
data = 42;                     while (!flag_ready);
flag_ready = 1;                print(data);

Without a barrier: Thread 2 could see flag_ready == 1 but data == 0 — the write to data might be delayed past the write to flag_ready.

Barrier Types

Barrier	Prevents
mfence (full)	All reordering around the fence
acquire (load)	Later loads/stores moving before
release (store)	Earlier loads/stores moving after

In high-level code: use std::atomic or synchronized — compilers insert the right barriers.