Data Race Undefined Behavior vs. False Sharing: Separating Concurrent-Only Latency Causes in C11 Handlers

Concurrent-only latency in a C11 request handler

C11 defines a data race as undefined behavior: two threads access the same memory location, at least one access is a write, and no synchronization orders the operations. Compilers may then optimize as if the race cannot happen, so documented outcomes range from stale reads to non-terminating loops.

This raises a design question for a handler that behaves predictably with serialized requests but degrades once they overlap. Three documented mechanisms produce similar symptoms: a genuine data race on shared state, false sharing when independent variables share a cache line, and mutex contention adding context-switch and kernel-transition overhead. The remedies differ sharply — _Atomic with relaxed ordering, aligned or per-thread counters, or sharded locks — and a wrong choice either leaves undefined behavior in place or inserts barriers that needlessly flush pipelines.

Assume C11 with stdatomic.h available and a pthreads-style threading runtime; mutex wakeup behavior remains implementation-specific.

• Which observable signature best separates a data race from false sharing before running a race detector such as ThreadSanitizer?
• When is relaxed memory ordering on a shared counter sufficient to make concurrent access defined without measurable ordering cost?
• Is mutex-driven kernel transition overhead under high request rates a portable assumption, or specific to a given libc and kernel?