CPU False Sharing Interview Questions: Cache Lines, Coherence, and Measurements

CPU false sharing happens when cores access different variables that occupy the same cache line, with at least one access writing, and cache coherence creates avoidable traffic between them. The program can be logically correct while scaling poorly because the hardware manages ownership at cache-line granularity.

The interview challenge is to prove that this is the performance problem you have. Adjacent counters, a slower multithreaded benchmark, and the word “cache” are clues, not a diagnosis. You need a controlled comparison and evidence that matches the hypothesis.

This guide uses two independently updated counters and a per-thread aggregation example. All performance numbers below are illustrative unless explicitly described as measured; no universal speedup is promised.

How is false sharing different from true sharing?

True sharing occurs when threads genuinely coordinate through the same data, such as one shared queue index or counter. False sharing occurs when the program treats data as independent but the hardware's cache-line unit places that data together.

Imagine core 0 repeatedly increments counter A while core 1 increments counter B. The counters have different addresses and represent different statistics. If both occupy the same cache line, writes can force coherence activity affecting the line even though neither thread needs the other's counter.

The false-sharing label describes unnecessary sharing at the hardware granularity. It does not mean the values are copied incorrectly or the compiler confused their names. It also does not imply a data race: atomic counters can still suffer from false sharing.

For an interview answer, state both conditions: placement in the same line and access patterns that create interference. Two read-only values on one line are usually a different situation from two frequently written values on separate cores.

Why do cache lines matter?

Caches move and track memory in blocks called cache lines. The size depends on the platform; 64 bytes is a common illustrative value, not a language guarantee. Cache coherence keeps participating cores' views consistent under the architecture's rules.

When a core wants to write, it needs the appropriate ownership or permission for the line. Other cached copies may need to be invalidated or updated according to the coherence protocol. Repeated independent writes to one line can therefore produce traffic and waiting that the application did not intend.

Do not reduce the explanation to “a cache miss happens.” Coherence-related transfer and ownership behavior is more specific than ordinary capacity misses. The performance counters available on the target CPU and operating system determine how directly you can observe it.

Also consider topology. Two cores sharing a nearby cache can behave differently from cores across sockets. Thread placement and migration can change results, so record them when comparing layouts.

Can padding solve the problem?

Separating frequently written independent fields onto different cache lines can reduce false sharing. Padding and alignment are common tools, but verify the actual layout and allocation rather than assuming a few extra bytes guarantee isolation.

#include <atomic>
#include <new>

struct alignas(std::hardware_destructive_interference_size) Counter {
    std::atomic<unsigned long long> value{0};
};

This C++17-style example uses a library constant intended to support separation of concurrently accessed objects. Availability and the value depend on the implementation. Check compiler support, object size, alignment, and the allocation used by the benchmark.

If the exercise explicitly assumes 64-byte lines, you can use that assumption in a small example. Say so. Hard-coding 64 into a production layout without checking the supported platforms is a different claim.

Padding changes memory footprint and sometimes locality. Separating every field can make the program slower by increasing the working set or scattering values that one thread usually reads together. The right repair targets the measured ownership conflict.

How would you design a convincing benchmark?

Create two versions with the same useful work. In version A, independent counters share a cache line. In version B, their placement is separated. Keep iteration count, thread count, update operation, build flags, and measurement boundaries comparable.

Use a release build and prevent the compiler from removing the work. Atomic increments can make the updates observable, but their own cost becomes part of the experiment. If using ordinary per-thread data, ensure the benchmark is race-free and that final results are consumed.

Synchronize the start of the worker phase and separate thread creation from the timed region if startup is not what you intend to measure. Run enough repetitions to see variation. Consider affinity when testing a specific core relationship, while documenting that placement as part of the experiment.

Measure more than one thread count. A layout difference that appears only under concurrent writes is more consistent with the hypothesis than a change equally visible in a single-threaded run. Still inspect other explanations before concluding causality.

What evidence should you collect with perf c2c?

On supported systems, perf c2c can help investigate cache-to-cache sharing behavior and identify heavily contended lines. Combine that evidence with source layout information, using tools such as pahole where appropriate to relate offsets to fields.

The Linux kernel's false-sharing guide emphasizes both detecting hot shared lines and understanding the actual data structure. A line address alone does not tell you whether the sharing is true or false. You must identify which fields different execution paths access and whether those accesses are logically independent.

Availability and interpretation of events vary by CPU and platform. Do not invent a universal counter threshold that proves false sharing. Compare the relevant events and throughput between the controlled variants, and explain what the tool can and cannot observe on your machine.

For an interview, a good response is: “I would locate the contended line, map its offsets to fields, inspect the writers, and test separation while holding the workload constant.” That is a diagnosis plan with falsifiable steps.

How can a benchmark produce a false conclusion?

A padded version may accidentally change something else: total allocation, loop structure, compiler optimization, NUMA placement, or which threads share a core. A speedup does not automatically identify which change caused it.

Another common mistake is comparing a single global atomic counter with independent per-thread counters and attributing the entire difference to false sharing. That changes true sharing and synchronization frequency as well as placement. Separate those experiments.

Confounder	Why it matters	Control
Thread creation in timed region	Startup may dominate short tests	Time the intended worker phase
Different operation counts	Less work looks faster	Verify equal completed updates
Thread migration	Cache and topology effects change	Observe or control placement
Changed allocation layout	Several locality properties change	Inspect addresses and sizes
Unused results	Compiler may remove work	Consume results correctly
Data races	Behavior is not a valid baseline	Establish correctness first

When results vary widely, investigate measurement conditions before increasing confidence in the narrative. An honest noisy result is more useful than a precise explanation attached to an uncontrolled benchmark.

Is memory_order_relaxed enough to avoid false sharing?

No. Relaxed ordering changes the synchronization constraints associated with the atomic operation. It does not change the fact that the core must perform an atomic update to memory on a cache line.

Two relaxed atomic counters in the same line can still compete for coherence ownership. Conversely, separating them may improve performance without changing their memory-order choice. Ordering correctness and data placement are distinct dimensions of the design.

Use relaxed ordering only when the program's synchronization argument permits it, such as an independent statistic whose surrounding lifetime is already safe. Do not weaken ordering to chase a benchmark result without proving that the application remains correct.

In an interview, explain the two questions separately: what order must other memory effects obey, and which line does this update touch? That prevents a common confusion between the language memory model and the hardware locality problem.

When is per-thread aggregation better than padding?

If every event updates a shared statistic but the exact global value is only needed periodically, accumulate locally and combine less often. This can reduce the frequency of shared writes rather than merely moving them to different lines.

For example, each worker counts processed records in its own local accumulator. At the end of a batch it adds the total to a shared counter, or a coordinator sums the per-worker totals at a defined point. The design trades immediate global visibility for lower coordination frequency.

Be explicit about the reporting contract. A dashboard can often tolerate slightly delayed statistics; a strict admission limit may not. You cannot replace a globally synchronized limit with stale local counts without changing correctness.

If a coordinator reads per-worker counters while workers update them, those accesses need a valid synchronization strategy too. “Per-thread” ownership does not make concurrent reads from another thread automatically safe in C++.

How should you lay out a mixed data structure?

Consider a worker record containing configuration read by everyone and a counter updated by one thread. Keeping read-mostly data next to a frequently written field can cause readers to experience coherence traffic even if they never inspect the counter.

Separate fields by access pattern when measurements justify it. Group values read together, and isolate independently hot writes when they interfere. The layout should reflect which threads use which fields, how often, and during which phases.

Do not automatically convert every array of structures into a structure of arrays. That transformation changes locality in several ways and can help one access pattern while hurting another. Draw the hot loops and identify the lines they actually touch.

A useful design review question is: “Which bytes does each core write during the hot phase?” It leads to a concrete layout discussion instead of a blanket rule about object size or alignment.

What if separating the counters does not help?

Treat that result as evidence. The bottleneck may be true sharing elsewhere, lock contention, memory bandwidth, an expensive atomic operation independent of false sharing, or overhead outside the measured update loop.

Check that the separated layout really placed the fields on different relevant lines and that the intended threads ran concurrently. Then compare profiles. If the hot time moved or the sharing events dropped without a throughput change, another bottleneck may now dominate.

Avoid repeatedly adding more padding without a new hypothesis. A performance investigation should narrow causes, not accumulate structural changes until one run looks better.

How do you answer a false-sharing interview question?

Give the mechanism, a minimal example, and a measurement plan. Two independent hot counters can share a cache line and cause ownership traffic. Compare shared and separated placement under equal work, inspect coherence evidence and field offsets, and evaluate the memory-footprint trade-off.

Then connect the fix to the application. Padding may fit a small number of hot counters; per-thread aggregation may fit delayed statistics; redesigning a queue's ownership can address a larger issue. State which guarantee must remain unchanged while you optimize.

That answer demonstrates more than knowing cache terminology. It shows you can distinguish correctness from performance, form a testable hypothesis, and stop when the evidence points somewhere else.

Sources and Further Reading

• Linux kernel: false sharing
• Linux perf c2c documentation
• C++ working draft: hardware interference sizes
• Linux perf tools

Research checked September 24, 2026. The 64-byte example is illustrative; verify cache behavior, tool support, and layout on the target platform.