False sharing and ownership-aware layout

Place two independent counters in the same line and assign one writer to each. If both cores repeatedly write, permission for the line can pass back and forth even though neither core needs the other's counter. A read-only field beside a frequently updated field can also suffer invalidations. By contrast, two cores reading an unmodified line do not create the same write-ownership conflict merely because their data share storage. The access pattern supplies the harmful interaction.

True sharing means threads communicate through the same logical data, such as updating one common total. Padding cannot remove that dependency. False sharing means the coherence granularity is larger than the independent pieces of application state. Both can occur in one structure, and fixing one can expose the other. Inspect actual field offsets and alignment in the built program instead of inferring layout from source declaration order or an allocator's usual behavior.

An aligned per-worker record can place independently written state on separate lines. Both record size and starting alignment matter. Adding a few unused bytes without verifying boundaries may merely move the conflict elsewhere. In portable code, use a layout abstraction appropriate to the language and target platform, and confirm its compiled representation. Keep deliberately shared control fields separate from per-worker payloads when their ownership patterns differ, rather than blindly padding every scalar.

The cost is larger live storage, more lines, and potentially more translations and memory traffic. A dense read-mostly scan may become slower when padding expands its footprint. Aggregating local counters periodically can reduce writes to a common total, but readers then observe a different freshness contract unless synchronization supplies an exact snapshot. A performance change is valid only if it preserves the application's required accuracy, visibility, and ownership rules.

Compare dense and separated variants with identical atomic operations, worker count, useful updates, and aggregation behavior. Bind workers deliberately if the experiment requires stable placement, and document whether they share a core, cache, or socket. A cache-to-cache analysis tool may identify a hot line and accessing instructions; verify that their addresses correspond to the independent fields. An ordinary last-level miss total cannot uniquely diagnose false sharing, and a speedup alone cannot identify the coherence transition involved.

The function lab provides a limited arithmetic sensitivity check with y=ax². Hold positive x fixed and increase positive a to represent a larger normalized per-record footprint for a square worker-by-bucket table. Predict the linear change with a. It does not show invalidations, ownership handoffs, or processor timing. Use the readout only to examine the storage side of a padding choice, then explain what an actual ownership trace would have to establish about the performance side.