False Sharing

Also Known As

TL;DR

Explanation

False sharing is a subtle performance bug that occurs on multi-core systems when two or more threads modify logically independent variables that happen to reside on the same CPU cache line (typically 64 bytes on x86-64). Even though the threads never touch each other's data, the cache coherence protocol (MESI or similar) must invalidate the entire cache line on other cores whenever any core writes to it. This turns what looks like embarrassingly parallel code into a memory bus bottleneck, often making the multi-threaded version slower than the single-threaded one.

The classic example is an array of per-thread counters where each thread increments its own slot. Logically these operations are independent, but if counters[0] through counters[7] fit within one 64-byte cache line, every increment forces a cross-core cache line transfer. Symptoms include: multi-threaded code that fails to scale with core count, unexpectedly high CPU cache miss rates in profilers (perf's cache-misses or LLC-load-misses counters), and performance that improves dramatically when unrelated struct fields are reordered or padded.

Detection typically requires hardware performance counters - tools like Linux perf, Intel VTune, or AMD uProf can highlight HITM (hit-modified) events indicating cross-core cache line contention. The fix is to force each thread's data onto its own cache line via padding, alignment attributes (alignas(64) in C++, #[repr(align(64))] in Rust, @Contended in Java), or by using thread-local storage. In garbage-collected languages, be aware that the runtime may still colocate objects. False sharing is language-agnostic - it affects C, C++, Rust, Java, Go, and any runtime that runs threads on real cores.

Common Misconception

Why It Matters

Common Mistakes

• Placing per-thread counters in a small contiguous array without padding so multiple slots share a cache line.
• Interleaving hot mutable fields with other frequently-written fields in a struct without considering the 64-byte cache line boundary.
• Assuming lock-free atomic counters have no contention cost - atomics still trigger coherence traffic when they share a line.
• Reading and writing adjacent elements of an array from different threads in parallel loops (e.g. OpenMP with static scheduling of tiny chunks).
• Ignoring cache line alignment in ring buffers where producer and consumer indices sit next to each other.

Avoid When

• Single-threaded code - there is no coherence traffic to eliminate.
• Read-mostly data shared across cores - shared reads do not invalidate cache lines, so padding wastes memory.
• Cold code paths where the increased memory footprint from padding hurts more than the rare contention.
• Small embedded targets where memory is scarce and cache lines may be smaller (e.g. 32 bytes) or coherence is not an issue.

When To Use

• Hot per-thread counters, statistics, or accumulators written millions of times per second.
• Producer/consumer ring buffer indices where head and tail are written by different threads.
• Per-CPU or per-worker data structures in queue workers or thread pools that fail to scale linearly.
• Any struct where hardware performance counters show high HITM or cross-core cache line transfer rates.

Code Examples

// C++: per-thread counters share a cache line - severe false sharing
#include <thread>
#include <vector>
#include <atomic>

struct Counters {
    long a; // thread 0 writes here
    long b; // thread 1 writes here
    long c; // thread 2 writes here
    long d; // thread 3 writes here
    // All four longs (32 bytes) fit in one 64-byte cache line.
    // Every increment invalidates the line on the other 3 cores.
};

void worker(long& counter) {
    for (long i = 0; i < 100'000'000; ++i) ++counter;
}

int main() {
    Counters c{};
    std::thread t0(worker, std::ref(c.a));
    std::thread t1(worker, std::ref(c.b));
    std::thread t2(worker, std::ref(c.c));
    std::thread t3(worker, std::ref(c.d));
    t0.join(); t1.join(); t2.join(); t3.join();
}

// C++: pad each counter to its own cache line
#include <thread>

struct alignas(64) PaddedCounter {
    long value;
    // alignas(64) forces sizeof(PaddedCounter) to be a multiple of 64,
    // so consecutive instances never share a cache line.
};

struct Counters {
    PaddedCounter a; // own cache line
    PaddedCounter b; // own cache line
    PaddedCounter c;
    PaddedCounter d;
};

void worker(long& counter) {
    for (long i = 0; i < 100'000'000; ++i) ++counter;
}

int main() {
    Counters c{};
    std::thread t0(worker, std::ref(c.a.value));
    std::thread t1(worker, std::ref(c.b.value));
    std::thread t2(worker, std::ref(c.c.value));
    std::thread t3(worker, std::ref(c.d.value));
    t0.join(); t1.join(); t2.join(); t3.join();
    // Typically 5-10x faster than the unpadded version on 4+ cores.
}

Tags

Related Terms

References

• https://en.wikipedia.org/wiki/False_sharing
• https://www.intel.com/content/www/us/en/developer/articles/technical/avoiding-and-identifying-false-sharing-among-threads.html
• https://mechanical-sympathy.blogspot.com/2011/07/false-sharing.html