A concurrency semantics for relaxed atomics that permits optimisation and avoids thin-air executions

Abstract

Despite much research on concurrent programming languages, especially for Java and C/C++, we still do not have a satisfactory definition of their semantics, one that admits all common optimisations without also admitting undesired behaviour. Especially problematic are the "thin-air" examples involving high-performance concurrent accesses, such as C/C++11 relaxed atomics. The C/C++11 model is in a per-candidate-execution style, and previous work has identified a tension between that and the fact that compiler optimisations do not operate over single candidate executions in isolation; rather, they operate over syntactic representations that represent all executions. In this paper we propose a novel approach that circumvents this difficulty. We define a concurrency semantics for a core calculus, including relaxed-atomic and non-atomic accesses, and locks, that admits a wide range of optimisation while still forbidding the classic thin-air examples. It also addresses other problems relating to undefined behaviour. The basic idea is to use an event-structure representation of the current state of each thread, capturing all of its potential executions, and to permit interleaving of execution and transformation steps over that to reflect optimisation (possibly dynamic) of the code. These are combined with a non-multi-copy-atomic storage subsystem, to reflect common hardware behaviour. The semantics is defined in a mechanised and executable form, and designed to be implementable above current relaxed hardware and strong enough to support the programming idioms that C/C++11 does for this fragment. It offers a potential way forward for concurrent programming language semantics, beyond the current C/C++11 and Java models.

Weakening WebAssembly

“…We have begun to see a new generation of models with the explicit aim of disallowing out-ofthin-air while preserving efficient compilation schemes Pichon-Pharabod and Sewell 2016;Podkopaev et al 2018]. As these models become more mature, it may be possible to use aspects of them to disallow our out-of-thin-air executions.…”

Bridging the gap between programming languages and hardware weak memory models

“…developed RC11, a repaired version of C/C++11, and established (by pen-and-paper proof) the correctness of the suggested compilation schemes to x86-TSO, POWER and ARMv7. Beyond (R)C11, however, there are a number of other proposed higher-level semantics, such as JMM [Manson et al 2005], OCaml [Dolan et al 2018], Promise , LLVM [Chakraborty and Vafeiadis 2017], Linux kernel memory model [Alglave et al 2018], AE-justification [Jeffrey and Riely 2016], Bubbly [Pichon-Pharabod and Sewell 2016], and WeakestMO [Chakraborty and Vafeiadis 2019], for which only a handful of compilation correctness results have been developed.…”

Promising-ARM/RISC-V: a simpler and faster operational concurrency model

“…For higher-level languages such as C/C++ [16] only non-atomic accesses and the sequential consistency and release/acquire fragments are well-understood. High-performance algorithms, however, also involve relaxed 'atomics' and 'consume' atomics, for which there still is not an accepted high-level language semantics [15,27,29,38]. Hence, in practice programmers often write code that does not follow the C/C++ concurrency model, relying instead on the compiled code to provide stronger guarantees, e.g.…”