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

We develop a new intermediate weak memory model, IMM, as a way of modularizing the proofs of correctness of compilation from concurrent programming languages with weak memory consistency semantics to mainstream multi-core architectures, such as POWER and ARM. We use IMM to prove the correctness of compilation from the promising semantics of Kang et al. to POWER (thereby correcting and improving their result) and ARMv7, as well as to the recently revised ARMv8 model. Our results are mechanized in Coq, and to the best of our knowledge, these are the first machine-verified compilation correctness results for models that are weaker than x86-TSO. Following the standard declarative (a.k.a. axiomatic) approach of defining memory consistency models [Alglave et al. 2014], the semantics of IMM programs is given in terms of execution graphs which partially order events. This is done in two steps. First, the program is mapped to a large set of execution graphs in which the read values are completely arbitrary. Then, this set is filtered by a consistency predicate, and only IMM-consistent execution graphs determine the possible outcomes of the program under IMM. Next, we define IMM's programming language ( §2.1), define IMM's execution graphs ( §2.2), and present the construction of execution graphs from programs ( §2.3). The next section ( §3) is devoted to present IMM's consistency predicate. 3 Recall that RMWs are relatively rare. The performance cost of this fixed compilation scheme is beyond the scope of this paper, and so is the improvement of the promising semantics to recover the correctness of the barrier-free compilation.

Section: Discussionmentioning

confidence: 99%

Bridging the gap between programming languages and hardware weak memory models

Podkopaev

Lahav

Vafeiadis

2019

“…We then develop constraints that characterize the LTSs that we are interested in: those that are well-formed, guaranteed to terminate under a fair progress model, and prone to non-termination under an unfair progress model. We invoke Alloy in an iterative manner, following Lustig et al [2017] and Chong et al [2018], with the aim of finding as many LTSs as possible that satisfy those constraints. From the LTS, we can derive a concurrent program, i.e.…”

Section: Automatic Synthesis Of Progress Litmus Testsmentioning

confidence: 99%

“…[2017] and Chong et al [2018], with the aim of finding as many LTSs as possible that satisfy those constraints. From the LTS, we can derive a concurrent program, i.e.…”

Section: Automatic Synthesis Of Progress Litmus Testsmentioning

confidence: 99%

Specifying and testing GPU workgroup progress models

Sorensen

Salvador

Raval

et al. 2021

Self Cite

As GPU availability has increased and programming support has matured, a wider variety of applications are being ported to these platforms. Many parallel applications contain fine-grained synchronization idioms; as such, their correct execution depends on a degree of relative forward progress between threads (or thread groups). Unfortunately, many GPU programming specifications (e.g. Vulkan and Metal) say almost nothing about relative forward progress guarantees between workgroups. Although prior work has proposed a spectrum of plausible progress models for GPUs, cross-vendor specifications have yet to commit to any model. This work is a collection of tools and experimental data to aid specification designers when considering forward progress guarantees in programming frameworks. As a foundation, we formalize a small parallel programming language that captures the essence of fine-grained synchronization. We then provide a means of formally specifying a progress model, and develop a termination oracle that decides whether a given program is guaranteed to eventually terminate with respect to a given progress model. Next, we formalize a set of constraints that describe concurrent programs that require forward progress to terminate. This allows us to synthesize a large set of 483 progress litmus tests. Combined with the termination oracle, we can determine the expected status of each litmus test -- i.e. whether it is guaranteed to eventually terminate -- under various progress models. We present a large experimental campaign running the litmus tests across 8 GPUs from 5 different vendors. Our results highlight that GPUs have significantly different termination behaviors under our test suite. Most notably, we find that Apple and ARM GPUs do not support the linear occupancy-bound model, as was hypothesized by prior work.

“…Test generation from declarative memory consistency axioms is well understood in the literature [Chong et al 2018;Lustig et al 2017]. The key observation is that one can use a solver such as Alloy [Jackson 2012] to search for executions that violate the given axioms, and then to construct from each execution a litmus test that passes only when that particular execution has occurred.…”

Section: Automated Litmus Test Generationmentioning

confidence: 99%

Persistency semantics of the Intel-x86 architecture

Raad

Wickerson

Neiger

et al. 2019

Self Cite

Emerging non-volatile memory (NVM) technologies promise the durability of disks with the performance of RAM. To describe the persistency guarantees of NVM, several memory persistency models have been proposed in the literature. However, the persistency semantics of the ubiquitous x86 architecture remains unexplored to date. To close this gap, we develop the Px86 ('persistent x86') model, formalising the persistency semantics of Intel-x86 for the first time. We formulate Px86 both operationally and declaratively, and prove that the two characterisations are equivalent. To demonstrate the application of Px86, we develop two persistent libraries over Px86: a persistent transactional library, and a persistent variant of the MichaelśScott queue. Finally, we encode our declarative Px86 model in Alloy and use it to generate persistency litmus tests automatically.