Simplifying ARM concurrency: multicopy-atomic axiomatic and operational models for ARMv8

Abstract

ARM has a relaxed memory model, previously specified in informal prose for ARMv7 and ARMv8. Over time, and partly due to work building formal semantics for ARM concurrency, it has become clear that some of the complexity of the model is not justified by the potential benefits. In particular, the model was originally nonmulticopy-atomic: writes could become visible to some other threads before becoming visible to all Ð but this has not been exploited in production implementations, the corresponding potential hardware optimisations are thought to have insufficient benefits in the ARM context, and it gives rise to subtle complications when combined with other ARMv8 features. The ARMv8 architecture has therefore been revised: it now has a multicopy-atomic model. It has also been simplified in other respects, including more straightforward notions of dependency, and the architecture now includes a formal concurrency model.In this paper we detail these changes and discuss their motivation. We define two formal concurrency models: an operational one, simplifying the Flowing model of Flur et al., and the axiomatic model of the revised ARMv8 specification. The models were developed by an academic group and by ARM staff, respectively, and this extended collaboration partly motivated the above changes. We prove the equivalence of the two models. The operational model is integrated into an executable exploration tool with new web interface, demonstrated by exhaustively checking the possible behaviours of a loop-unrolled version of a Linux kernel lock implementation, a previously known bug due to unprevented speculation, and a fixed version.

Bridging the gap between programming languages and hardware weak memory models

“…Their result handled only a restricted subset of the concurrency features of the promising semantics, leaving release/acquire accesses, RMWs, and SC fences out of scope. In addition, as a model of ARMv8, they used an operational model, ARMv8-POP [Flur et al 2016], that was later abandoned by ARM in favor of a stronger different declarative model [Pulte et al 2018]. Our proof in this paper is mechanized, supports all features of the promising semantics, and uses the recent declarative model of ARMv8.…”

“…• As noted in Example 3.10, the mapping of IMM's strong RMWs requires placing a dmb.ld barrier after the exclusive write. As a model of the ARMv8 architecture, we use its recent official declarative model [Deacon 2017] (see also [Pulte et al 2018]) which we denote by ARM. 8 Its labels are given by:…”

“…Again, due to lack of space, we do not include here the definition of ARMconsistency. For that definition, we refer the reader to [Deacon 2017;Pulte et al 2018] (Appendix C provides the definition we used in our development). N), and let G a be an ARM execution graph that corresponds to G. Then, ARM-consistency of G a implies IMMconsistency of G.…”

“…To support platform-independent concurrent programming, languages like C/C++11 and Java9 provide several types of memory accesses and high-level fence commands. Compilers of these languages are required to map the high-level primitives to instructions of mainstream architectures: in particular, x86-TSO [Owens et al 2009], ARMv7 and POWER [Alglave et al 2014], and ARMv8 [Pulte et al 2018]. In this paper, we focus on proving the correctness of such mappings.…”

On Parallel Snapshot Isolation and Release/Acquire Consistency

“…Among weak memory models, the "multi-copy-atomic" ones, such as x86-TSO [29,34], SPARC PSO [37,38] and ARMv8-Flat [31], also forbid the weak outcome of (IRIW+txs) in the same way as SC, and so are unsuitable for our purpose. We thus consider release-acquire consistency (RA) [8,9,21], a simple and wellbehaved non-multi-copy-atomic model.…”