Mathematizing C++ concurrency

Abstract

Shared-memory concurrency in C and C++ is pervasive in systems programming, but has long been poorly defined. This motivated an ongoing shared effort by the standards committees to specify concurrent behaviour in the next versions of both languages. They aim to provide strong guarantees for race-free programs, together with new (but subtle) relaxed-memory atomic primitives for highperformance concurrent code. However, the current draft standards, while the result of careful deliberation, are not yet clear and rigorous definitions, and harbour substantial problems in their details.In this paper we establish a mathematical (yet readable) semantics for C++ concurrency. We aim to capture the intent of the current ('Final Committee') Draft as closely as possible, but discuss changes that fix many of its problems. We prove that a proposed x86 implementation of the concurrency primitives is correct with respect to the x86-TSO model, and describe our CPPMEM tool for exploring the semantics of examples, using code generated from our Isabelle/HOL definitions.Having already motivated changes to the draft standard, this work will aid discussion of any further changes, provide a correctness condition for compilers, and give a much-needed basis for analysis and verification of concurrent C and C++ programs.

Overhauling SC atomics in C11 and OpenCL

“…This increases the demands on compilers that implement these memory models, so it is important to check that our changes do not invalidate existing compilation schemes. To this end, we prove that all of the formalised C11 compilation schemes of which we are aware (namely, those for Power [8] and x86 [7] machines) remain sound after our changes, and we argue informally that our OpenCL changes preserve the soundness of the only formalised OpenCL compilation scheme (namely, that for AMD GPUs [41]). …”

“…Correctness in any relaxed memory setting is notoriously evasive; indeed, the subtleties of relaxed memory have previously led to confirmed bugs in language specifications [7,10], deployed processors [1], compilers [27,40] and vendor-endorsed programming guides [3]. The importance of correctness in the context of C11 is well-known.…”

“…The C11 memory model has been formalised by several researchers, in varying degrees of completeness, and with varying degrees of fidelity to the standard [2,7,38]. These formalisation efforts have proved fruitful; they have, for instance, enabled the construction of simulators that automatically explore the allowed behaviours of small C11 programs (called litmus tests) [2,7,13,29], underpinned the design of program logics for specifying and verifying C11 programs [37,38], and they provide a firm foundation for ongoing debate about the design of the C11 memory model itself [10,39]. The OpenCL memory model (introduced in version 2.0 of the standard) has received comparatively little academic attention, with the notable exception of the work of Gaster et al [17], which we discuss further in §7.…”

Programming models for many-core architectures: a co-design approach

“…Additionally, it defines a threaded concurrency model that communicates via shared memory, and a relaxed, but rather complex, memory model [11]. In contrast to C99, handling concurrency and memory consistency mostly relies on the programmer.…”

“…It assumes that the programmer can identify variables that should be declared atomic and access it accordingly. However, Batty et al [11] conclude that this model is not clearly defined by the standard, and the corresponding mathematical model might not be 'sufficiently widely accessible' . Because of the complexity of the model, it is unclear whether it defines the weakest (usable) model.…”