Staff / expert · Memory and runtime
Memory layout and false sharing
Two independent counters slow down when updated concurrently. Why?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
CPU caches move cache lines, so different variables sharing a line may still contend when different cores write them. This is false sharing; there need not be a language-level data race.
An atomic counter can be race-free and still expensive under contention. Sharding, per-worker aggregation or batching can reduce cache coherence traffic, while padding trades memory for potential isolation.
Demonstrate the bottleneck with a realistic benchmark and profiles on target hardware. Do not hardcode a universal cache-line size or rearrange every struct on speculation. Preserve synchronization correctness while measuring layout changes.
Common trap
The absence of race detector warnings says nothing about cache-line contention.
Try it
Design a throughput metric for 64 workers that does not require one global atomic on every item.
Worked solution
Use per-worker counts and aggregate after joining, or periodically batch increments if live estimates are needed. Explain how often a reader needs fresh data and how that choice changes synchronization.
Change the constraint
Why can a mutex outperform a spin-based retry loop under heavy contention?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.