Myths and Misconceptions about Threads

The semantics of variables shared across threads, usually called "memory models", have evolved significantly over the last decade, but open problems and some controversy remains. I'll briefly review where we are, and argue that a number of assumptions that still appear common in large parts of the research and programming communities are wrong, or at least questionable, especially for programming languages like C and C++. In particular, I will argue that:. Full, unrestricted sequential consistency is not a particularly desirable or useful programming model, in that it depends on access granularity, a property often, and for excellent reasons, hidden by both programming language and library specifications. Hardware level violations of sequential consistency are often not an indication of bugs. For example, correctly synchronized programs based on spin-locks can be expected to violate sequential consistency at the hardware level, while appearing sequentially consistent at the source level. There are no benign data races in C and C++, certainly not in theory, but also not in practice. Any data race gives license to the compiler to mis-compile your program. A future compiler is likely to use that license, even if your current one does not. Condition variable wait and notify, as provided by mainstream programming languages, do not impact program partial correctness beyond the fact that waiting temporarily releases a mutex. They do not, in any other way, ensure "happens-before" ordering. For partial correctness purposes, notify is a no-op. Relaxed memory ordering, as currently defined by Java, C, or C++, is not well-defined at the programming language, as opposed to machine architecture, level. We're working on that, but stronger ordering is much easier to define than really weak ordering.