The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Two threads can update different variables and still slow each other down when those variables occupy the same cache line. This is called false sharing: the variables are logically separate, but the processor’s cache-coherence system manages them as part of one line and may repeatedly transfer or invalidate that line between cores.
Why different variables can interfere
Cache coherence keeps processor cores’ cached copies of memory consistent at the granularity of a cache line, not one source-language variable at a time. When a core writes to a line, it needs the appropriate ownership of that line. If another core also has a copy, the coherence protocol may invalidate or transfer it. Repeated writes from different cores can make the line bounce between them.
As an Amazon Associate I earn from qualifying purchases.
For example, worker A might increment one counter while worker B increments a different counter. If both counters lie in the same cache line, each worker’s writes can disrupt the other’s cached copy. The counters remain distinct; the hardware’s coherence unit does not. This is a conceptual example, not a performance measurement for a particular processor.
Cache-coherence protocols use states and messages to coordinate ownership. Paul E. McKenney’s Is Parallel Programming Hard, And, If So, What Can You Do About It? explains the Modified, Exclusive, Shared, and Invalid states in MESI and illustrates a 64-byte cache line holding eight 64-bit values. That is an example, not a universal line size. Read the book.
#1 Best Overall
When false sharing happens—and what it is not
The key conditions are concurrent access to the same cache line by multiple CPUs and at least one write. Frequent write/write activity can cause repeated ownership changes; a write can also interfere with another CPU’s reads of nearby data. For instance, a frequently updated reference count placed beside a mostly read-only name field may create avoidable traffic.
- Read-only sharing alone is not this pattern. If all cores only read the line, the write-driven invalidation problem described here does not arise.
- False sharing is not automatically a data race. Different variables can be accessed independently without a language-level race and still contend because their addresses fall in the same coherence line.
- Small or unrelated fields can be affected. Closely packed global variables, structure members, locks, or protected data may share a line despite serving unrelated purposes.
The actual cache-line size depends on the target processor. Linux’s documentation describes common examples as usually 64 bytes or more; do not assume one padding size fits every machine. See the Linux kernel’s false-sharing documentation.
How to find a real false-sharing hotspot
Profile the workload before changing data layout. On Linux, the kernel documentation describes perf-c2c as a way to find cache lines with substantial cache-to-cache activity and identify functions, source locations, and offsets accessing them. Use pahole to inspect structure layout at cache-line granularity, and addr2line when you need to decode instruction locations.
- Record a profile: the documented example is
perf c2c record -ag sleep 3. Adapt the command to the application and environment you are profiling. - Review the report: the documented example is
perf c2c report --call-graph none -k vmlinux. Inspect the reported lines, access sites, and offsets rather than treating a tool report alone as proof that a change will help. - Check the layout: use
paholeto see whether hot fields share a line. Correlate the layout with the profiled accesses and the workload’s behavior. - Change one likely cause and measure again: compare performance under the same workload, and check correctness and side effects. A hotspot may move or another bottleneck may become dominant.
The commands above are examples from Linux documentation, not results from a test of your program. A reported line matters only if it is a meaningful bottleneck in the workload you care about.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choose a mitigation that fits the access pattern
| Option | When it may help | Trade-off to check |
|---|---|---|
| Separate frequently written fields or reorganize a structure | Profiling shows unrelated hot fields sharing a line. | More memory use and cache/TLB footprint; moving fields can create sharing elsewhere. |
| Group fields by how they are accessed | Mostly read-only fields can sit together, while fields written together can be grouped separately from frequently read data. | Layout changes should match real access patterns; otherwise the new arrangement may not reduce traffic. |
| Reduce unnecessary writes | A write can be replaced with a read or conditional write without changing program semantics. | Preserve the required behavior and synchronization semantics. |
| Aggregate locally or use per-CPU data | Many updates to shared global state can be accumulated locally and synchronized less often. | Aggregation adds design complexity and must preserve the semantics the program needs. |
| Align or pad selected data | Measurement identifies a specific line-sharing problem and separation is appropriate. | Line size is platform-dependent, padding increases footprint, and no universally optimal padding size is established. |
Linux’s guidance is deliberately cautious: “False sharing does not always need to be mitigated.” It also advises balancing performance gains against complexity and space consumption. Make a change when profiling and repeatable measurements justify it, not merely because two fields happen to be adjacent.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
