False Sharing

Learning objective

Explain why two threads writing to independent, unrelated variables can destroy each other's throughput, and be able to tell that failure mode apart from a data race or lock contention — then know when padding is worth its memory cost and when it isn't.

Prerequisites

• Comfortable reading Java or Rust concurrent code (atomics, threads).
• A basic idea of what a CPU cache is — a fast copy of main memory kept close to a core. You do not need prior knowledge of coherence protocols; this lab builds that from scratch.

Theory

Cache-line theory

CPUs do not move memory between cache and RAM one byte, or one variable, at a time. They move it in fixed-size blocks called cache lines — commonly 64 bytes on current x86-64 and ARM64 parts, but the exact size is a hardware detail, not an architectural guarantee (query CPUID or sysctl hw.cachelinesize at runtime if it matters to you). This lab treats 64 bytes as a common example, never a universal constant.

When a core reads a memory address, the whole line containing it is pulled into that core's cache. If two independent long counters happen to sit inside the same 64-byte line — because they're adjacent fields in the same object, or elements of the same small array — the hardware has no way to know they are logically unrelated. As far as the coherence protocol is concerned, there is exactly one cache line, and only one core may hold it writable at a time.

False sharing is what happens when two threads on different cores repeatedly write to different variables that live on that same line. Each write by core A forces core B's copy of the line to be invalidated — even though core B never touched core A's variable — and vice versa. The line ping-pongs between cores, and every write pays the cost of a cross-core transfer instead of hitting a warm local cache.

A simplified coherence model

Real coherence protocols (MESI and its variants — MESIF, MOESI) have more states and more nuance than this lab models. The interactive visualisation below uses three states, which is enough to see the mechanism:

The rule that produces false sharing: a write always forces every other core's copy of that line to Invalid, regardless of which bytes in the line were actually written.

False sharing vs. a data race

A data race is a correctness bug: two threads access the same memory location without synchronization, and at least one is a write. The language memory model (JMM, Rust's) gives no guarantee about what value is observed. Fixing it requires synchronization — locks, atomics, happens-before edges.

False sharing is a performance bug on code that is already correct. The two threads write to genuinely independent variables — there is no shared logical state and no synchronization needed for correctness. The cost is purely the extra coherence traffic caused by physical layout. Fixing it requires separating the variables onto different cache lines, not adding synchronization. A data race can exist without false sharing, and false sharing can exist without any race — the two are orthogonal.

False sharing vs. lock contention

Lock contention happens when threads want the same critical section at the same time and must serialize — one waits while another holds the lock. The cost is explicit: queuing, context switches, or spin-wait cycles, visible as threads blocked on the same lock in a profiler or thread dump.

False sharing requires no lock at all. Both threads run concurrently and never wait for each other in the logical sense. The threads make forward progress the whole time; the cost is hidden inside a slower memory subsystem, not visible as blocking — a profiler has to look at cache-miss counters or coherence-traffic hardware counters, not lock wait time, to see it. The two can compound (a lock's own state can itself be a false-sharing victim), but eliminating one does not eliminate the other.

Java and Rust

public class SharedCounters {
    // Adjacent fields of the same object are very likely to land on the
    // same 64-byte cache line — the JVM makes no promise either way, but
    // in practice contiguous long fields with no padding between them do.
    public volatile long counterA;
    public volatile long counterB;
}

public class PaddedCounters {
    public volatile long counterA;
    // 7 longs = 56 bytes of padding. Combined with the 8-byte counterA,
    // that pushes counterB onto the next 64-byte line on a machine with
    // that line size — a documented assumption, not a guarantee.
    public long p1, p2, p3, p4, p5, p6, p7;
    public volatile long counterB;
}

import jdk.internal.vm.annotation.Contended;

public class ContendedCounters {
    @Contended
    public volatile long counterA;
    @Contended
    public volatile long counterB;
}

import org.openjdk.jmh.annotations.*;
import java.util.concurrent.TimeUnit;

@State(Scope.Group)
@BenchmarkMode(Mode.Throughput)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@Fork(value = 1, jvmArgsAppend = {"-XX:-RestrictContended"})
@Warmup(iterations = 5, time = 1)
@Measurement(iterations = 10, time = 1)
public class FalseSharingBenchmark {

    private final SharedCounters shared = new SharedCounters();
    private final PaddedCounters padded = new PaddedCounters();

    @Benchmark
    @Group("shared")
    public void writeA_shared() { shared.counterA++; }

    @Benchmark
    @Group("shared")
    public void writeB_shared() { shared.counterB++; }

    @Benchmark
    @Group("padded")
    public void writeA_padded() { padded.counterA++; }

    @Benchmark
    @Group("padded")
    public void writeB_padded() { padded.counterB++; }
}

use std::sync::atomic::AtomicU64;

#[repr(C)]
pub struct SharedCounters {
    pub counter_a: AtomicU64,
    pub counter_b: AtomicU64,
}

impl SharedCounters {
    pub fn new() -> Self {
        Self { counter_a: AtomicU64::new(0), counter_b: AtomicU64::new(0) }
    }
}

use std::sync::atomic::AtomicU64;

#[repr(align(64))]
pub struct CacheLineAligned<T>(pub T);

pub struct PaddedCounters {
    pub counter_a: CacheLineAligned<AtomicU64>,
    pub counter_b: CacheLineAligned<AtomicU64>,
}

impl PaddedCounters {
    pub fn new() -> Self {
        Self {
            counter_a: CacheLineAligned(AtomicU64::new(0)),
            counter_b: CacheLineAligned(AtomicU64::new(0)),
        }
    }
}

use criterion::{criterion_group, criterion_main, Criterion};
use std::sync::atomic::Ordering;
use std::sync::Arc;
use std::thread;

fn run_concurrent_increments<F: Fn() + Send + Sync + 'static>(iters: u64, op_a: Arc<F>, op_b: Arc<F>) {
    let a = op_a.clone();
    let b = op_b.clone();
    let t1 = thread::spawn(move || { for _ in 0..iters { a(); } });
    let t2 = thread::spawn(move || { for _ in 0..iters { b(); } });
    t1.join().unwrap();
    t2.join().unwrap();
}

fn bench_shared(c: &mut Criterion) {
    c.bench_function("shared_counters", |b| {
        b.iter(|| {
            let counters = Arc::new(SharedCounters::new());
            let c1 = counters.clone();
            let c2 = counters.clone();
            run_concurrent_increments(
                100_000,
                Arc::new(move || { c1.counter_a.fetch_add(1, Ordering::Relaxed); }),
                Arc::new(move || { c2.counter_b.fetch_add(1, Ordering::Relaxed); }),
            );
        });
    });
}

criterion_group!(benches, bench_shared);
criterion_main!(benches);

Benchmark methodology

Method: two threads, each incrementing its own dedicated counter in a tight loop, for the shared, padded, and (Java only) @Contended layouts above. JMH @Group/Scope.Group (Java) and two joined std::thread::spawn handles (Rust) ensure both counters are written concurrently from separate OS threads — a single-threaded run of the same code shows no difference between layouts and is not a valid reproduction (see the investigation task below, step 3).

Java (JMH, ops/ms, higher is better):

Rust (Criterion, time per 100,000-increment batch, lower is better):

On this run: padding gave roughly a 3.7× throughput improvement in Java and a 3.8× reduction in time-per-batch in Rust; @Contended slightly outperformed manual padding in Java. These ratios — not the absolute numbers — are the part worth trusting across machines. The runnable projects (content/labs/false-sharing/code/java/, content/labs/false-sharing/code/rust/) each emit raw per-iteration samples (JMH -rf json; Criterion's target/criterion/**/new/raw.csv plus its generated HTML report) — inspect those, and replace this table with your own environment's numbers, before treating any of it as authoritative for a design decision.

Common mistakes

• Padding by declaration order alone, without @Contended or an explicit alignment attribute, and trusting it survives optimization or field reordering across every JVM/compiler version.
• Assuming a universal 64-byte cache line — query it or state the assumption explicitly.
• Diagnosing false sharing as "just make it volatile" or adding a lock — neither addresses layout, and a lock introduces contention that wasn't there before.
• Padding everything defensively instead of only identified hot, independently-written fields.
• Benchmarking on one thread — false sharing is invisible in a single-threaded microbenchmark; it only appears with genuinely concurrent access from different cores.

Investigation task

Using the Java or Rust project in code/, and a profiler or hardware counter tool available to you:

1. Run the shared-counters benchmark and the padded-counters benchmark and record throughput for both.
2. Look for a cache-miss or coherence-event counter (e.g. perf stat -e cache-misses, or perf c2c on Linux for cache-to-cache transfer detection) and compare it between the two runs.
3. Reduce the benchmark to a single thread and confirm the shared-vs-padded gap disappears — this isolates the effect to concurrent cross-core access, not the layout alone.
4. Write down your CPU model and core topology (are the two threads pinned to different physical cores, or could they land on SMT siblings of the same core?), your measured numbers, and explain any difference from the disclosed numbers above.

Accessibility notes

• The interactive model is fully keyboard operable: the scenario selector and the Java/Rust code tabs are roving-tabindex tablists (arrow keys, Home/End); every write/read/step/reset control is a native <button>.
• Every state change is announced to screen readers via an aria-live="polite" region, in addition to the visible state badges and the state inspector table — state is never colour-only.
• The coherence-bus pulse is the only animation on this page; it plays once per action and is fully collapsed under prefers-reduced-motion: reduce (this page has no auto-playing or looping animation to separately gate on that preference).
• With JavaScript disabled, this page's theory, Java and Rust code, benchmark methodology, trade-offs and sources remain fully readable — only the interactive model and the graded quiz require script.

Review questions

Self-check before or after the graded quiz below:

1. Why does writing to counterA ever affect a thread that only ever reads or writes counterB?
2. What observable difference distinguishes false sharing from a data race, in both symptom and fix?
3. Why does the JMH example need @Group/Scope.Group rather than two independent single-threaded benchmarks?
4. Give one situation where adding padding would make performance worse, not better.

Sources

• Java Concurrency in Practice — Goetz et al., Addison-Wesley, 2006.
• Intel 64 and IA-32 Architectures Software Developer's Manual, Vol. 3A §11 (Memory Cache Control) — intel.com/sdm
• A Primer on Memory Consistency and Cache Coherence — Sorin, Hill, Wood, Morgan & Claypool, 2011.
• JEP 142: Reduce Cache Contention on Specified Fields (@Contended) — openjdk.org/jeps/142
• The Rust Reference — Type Layout (repr(align)) — doc.rust-lang.org/reference/type-layout
• JMH Samples — JMHSample_22_FalseSharing — github.com/openjdk/jmh
• Criterion.rs User Guide — bheisler.github.io/criterion.rs