Position paper: nondeterminism is unavoidable, but data races are pure evil

Modern mainstream programming languages distinguish between "atomic" (or sometimes "volatile") variables, and ordinary data. Atomic accesses are treated as synchronization constructs, and support concurrent access with well-defined semantics. In contrast, concurrent accesses to ordinary data, if at least one access is an update, constitute a data race. Code with data races does not have well-defined semantics. Such code may fail completely when recompiled or run on a different operating system version. In C and C++ data races are equivalent to assignments to out-of-bounds array elements; any data race can result in arbitrary failures, including application crashes, hangs, and inexplicably and completely wrong answers. These language specifications, combined with implementation realities, make it unsafe to exploit "benign" data races to obtain performance, even if we are willing to tolerate approximate answers. Furthermore, even if we happen to get lucky, and code with data races happens to execute correctly with our current compiler, data races provide at best inconsequential performance advantages over atomics. In fact, there are interesting, and probably common, cases in which data races provide only a minor performance advantage, even over pervasive locking to avoid them, it at sufficiently large core counts. We demonstrate such a case.