Parallelized sequential composition, pipelines, and hardware weak memory models

Abstract

Since the introduction of the CDC 6600 in 1965 and its "scoreboarding" technique processors have not (necessarily) executed instructions in program order. Programmers of highlevel code may sequence independent instructions in arbitrary order, and it is a matter of significant programming abstraction and computational efficiency that the processor can be relied upon to make sensible parallelizations/reorderings of low-level instructions to take advantage of, for instance, multiple arithmetic units. At the architectural level such reordering is typically implemented via a per-processor pipeline, into which instructions are fetched in order, but possibly committed out of order depending on local considerations, provided any reordering preserves sequential semantics from that processor's perspective. However, multiprocessing and multicore architectures, where several pipelines run in parallel, can expose these processor-level reorderings as unexpected, or "weak", behaviours. Such weak behaviours are hard to reason about, and (via speculative execution) underlie at least one class of widespread security vulnerability.In this paper we introduce a novel program operator, parallelized sequential composition, which can be instantiated with a function that controls the reordering of atomic instructions. The operator generalises both standard sequential composition and parallel composition, and when appropriately instantiated exhibits many of the weak behaviours of the well-known hardware weak memory models TSO, Release Consistency, ARM, and RISC-V. We show that the use of this program-level operator is equivalent to sequential execution with reordering via a pipeline. Encoding reordering as a programming language operator admits the application of established compositional techniques (such as Owicki-Gries) for reasoning about weak behaviours, and is convenient for abstractly expressing properties from the literature such as sequential consistency. The semantics and theory is encoded and verified in the Isabelle/HOL theorem prover, and we give an implementation of the pipeline semantics in the Maude rewriting engine and use it empirically to show conformance of the semantics against established models of ARM and RISC-V, and elucidate some stereotypical weak behaviours from the literature.

Separation of concerning things: a simpler basis for defining and programming with the C/C++ memory model (extended version)

“…As we show elsewhere [11,12,14], the parameter can be instantiated to give the behaviour of hardware weak memory models, but in this paper we focus mostly on C's memory model, denoted formally by ' ', and the special cases of sequential and parallel composition. The ⊲ operator essentially allows the construction of a sequence of instructions that may be reordered under some circumstances, similar to a hardware pipeline.…”

“…This is a relatively convenient way to express reorderings, especially as it is agnostic about global traces and behaviours. As shown empirically in [12] it is suitable for explaining observed behaviours on architectures such as Arm, x86 and RISC-V. It specialises to the notions of sequential and parallel conjunction straightforwardly.…”

“…Note that acquire loads may come before release stores, that is, C follows the pc model rather than the the stronger sc model in [26] (it is of course straightforward to accommodate either; see also [12]). We extend the syntax of instructions to incorporate ordering constraints, allowing variables and fences to be annotated with a set thereof, as shown in Fig.…”

“…We now show how reordering according to the C memory model can be embedded into a more realistic imperative language that has conditionals and loops, based on the previously described wide-spectrum language IMP+pseq [11,12,14]. We give a small-step operational semantics and define trace equivalence for its notion of correctness.…”

“…Syntactically and semantically the key aspect is the parallelized sequential composition operator, formalising a processor-pipeline concept that has been around since the 1960s, and which has been previously shown to have good explanatory power for most behaviours observed on hardware weak memory models [11,12]. Reasoning in this setting involves making explicit at the program level what effects the memory model has, either reducing to a sequential form where the use of atomics.h features prevents the compiler or hardware from making problematic reorderings, or making the residual parallelism explicit; in either case, standard techniques (such as Owicki-Gries or rely/guarantee) apply to the reduced program.…”