Foundations of the C++ concurrency memory model

Abstract

Currently multi-threaded C or C++ programs combine a singlethreaded programming language with a separate threads library. This is not entirely sound [7].We describe an effort, currently nearing completion, to address these issues by explicitly providing semantics for threads in the next revision of the C++ standard. Our approach is similar to that recently followed by Java [25], in that, at least for a welldefined and interesting subset of the language, we give sequentially consistent semantics to programs that do not contain data races. Nonetheless, a number of our decisions are often surprising even to those familiar with the Java effort:• We (mostly) insist on sequential consistency for race-free programs, in spite of implementation issues that came to light after the Java work.• We give no semantics to programs with data races. There are no benign C++ data races.• We use weaker semantics for trylock than existing languages or libraries, allowing us to promise sequential consistency with an intuitive race definition, even for programs with trylock.This paper describes the simple model we would like to be able to provide for C++ threads programmers, and explain how this, together with some practical, but often under-appreciated implementation constraints, drives us towards the above decisions.

On atomicity enforcement in concurrent software via Discrete Event Systems theory

“…A data race occurs if two threads access the same memory location simultaneously, and at least one of them is a write operation [3]. Figure 1 is an example of a balance transfer function.…”

Computer Memory: Why We Should Care What Is under the Hood

“…For example, in a 2008 version of its System Programming Guide, Intel states that "writes to the same location have a total order," but a 2011 version of the same document replaces this with "any two stores are seen in a consistent order by processors other than those performing the stores." Since many of the intricate interactions that can make seemingly reasonable memory ordering models backfire are still only being discovered, we would recommend following recent work on C++ and Java memory models for details [10,23].…”

Runtime verification of concurrency-specific correctness criteria

“…But consensus has emerged that sequential consistency should be ensured at least for data-race free programs [4,38]. In most programming languages, data-race freedom cannot be checked precisely using static methods, and dynamic data-race detection remains the only alternative for eliminating surprising behaviors such as those described above.…”