The semantics of transactions and weak memory in x86, Power, ARM, and C++

Abstract

Weak memory models provide a complex, system-centric semantics for concurrent programs, while transactional memory (TM) provides a simpler, programmer-centric semantics. Both have been studied in detail, but their combined semantics is not well understood. This is problematic because such widely-used architectures and languages as x86, Power, and C++ all support TM, and all have weak memory models. Our work aims to clarify the interplay between weak memory and TM by extending existing axiomatic weak memory models (x86, Power, ARMv8, and C++) with new rules for TM. Our formal models are backed by automated tooling that enables (1) the synthesis of tests for validating our models against existing implementations and (2) the model-checking of TM-related transformations, such as lock elision and compiling C++ transactions to hardware. A key finding is that a proposed TM extension to ARMv8 currently being considered within ARM Research is incompatible with lock elision without sacrificing portability or performance.

Modular transactions

“…Our lower-level assumes only that the underlying transactional machinery provides order between transactions that have a direct dependency, e.g., as in the publication idiom. We note that hardware transactions [5,6,10] support the ordering assumptions of our lower-level model. Fences are necessary only to provide order when there is no direct dependency, as in the privatization idiom.…”

“…Lifted Relations. A common technique to enforce transactional atomicity is to lift orders from individual actions to the level of transactions [6,10,32]. Notationally, we indicate a lifted relation by prefixing "l." For example, the lifting of wr is written lwr .…”

BMC for Weak Memory Models: Relation Analysis for Compact SMT Encodings

“…A successful approach to formalizing weak memory models is CAT [11,12,16], a flexible specification language in which all memory models considered so far can be expressed succinctly. CAT, together with its accompanying tool Herd [4], has been used to formalize the semantics not only of assembly for x86/TSO, Power, ARMv7 and ARMv8, but also high-level programming languages, such as C/C++, transactional memory extensions, and recently the Linux kernel concurrency primitives [11,15,16,18,20,24,29]. This success indicates the need for universal verification tools that are not limited to a specific memory model.…”

Weak persistency semantics from the ground up: formalising the persistency semantics of ARMv8 and transactional models

“…More generally, experimental validation of memory persistency models remains an interesting open problem, and we plan to pursue it in future work. Litmus testing for memory consistency models is well established [Alglave et al 2015[Alglave et al , 2011Chong et al 2018], but it remains unclear how best to insert the crashes that would be needed to test memory persistency models. One option would be to use a simulator (which is how Bornholt et al [2016] validated their crash-consistency models for filesystems) but this would not necessary reveal all the concurrency behaviours that real processors can exhibit.…”