x86-TSO

Abstract

Exploiting the multiprocessors that have recently become ubiquitous requires high-performance and reliable concurrent systems code, for concurrent data structures, operating system kernels, synchronization libraries, compilers, and so on. However, concurrent programming, which is always challenging, is made much more so by two problems. First, real multiprocessors typically do not provide the sequentially consistent memory that is assumed by most work on semantics and verification. Instead, they have relaxed memory models, varying in subtle ways between processor families, in which different hardware threads may have only loosely consistent views of a shared memory. Second, the public vendor architectures, supposedly specifying what programmers can rely on, are often in ambiguous informal prose (a particularly poor medium for loose specifications), leading to widespread confusion.In this paper we focus on x86 processors. We review several recent Intel and AMD specifications, showing that all contain serious ambiguities, some are arguably too weak to program above, and some are simply unsound with respect to actual hardware. We present a new x86-TSO programmer's model that, to the best of our knowledge, suffers from none of these problems. It is mathematically precise (rigorously defined in HOL4) but can be presented as an intuitive abstract machine which should be widely accessible to working programmers. We illustrate how this can be used to reason about the correctness of a Linux spinlock implementation and describe a general theory of data-race freedom for x86-TSO. This should put x86 multiprocessor system building on a more solid foundation; it should also provide a basis for future work on verification of such systems. SBProc 0 Proc 1 Mov [x]¬1 Mov eAX¬[y] Mov [y]¬1 Mov ebX¬[x] Allowed Final State: Proc 0:eAX=0 ∧ Proc 1:ebX=0

Lock Cohorting

“…We implemented all of the lock algorithms and benchmarks in C and C++ compiled with GCC 4.7.1 at optimization level -O3 in 32-bit mode. As required, we inserted memory fences to support the memory model on x86 [Sewell et al 2010] and SPARC where a store and load in program order can be reordered by the architecture. While not shown in our pseudo-code, padding and alignment were added in the data structures to avoid false sharing.…”

A Calculus for Relaxed Memory

“…The total-store-ordering semantics [20] provides that all instructions are executed in program order (or, more precisely, cannot be observed to be executed out of program order), each write is visible either globally or only to its own thread, and writes become globally visible in program order. Consequently, visibility-and execution-order edges compile away to nothing, and pushes can be implemented by mfences.…”

“…We take as our reference points the (broadly similar) Power and ARM architectures, and the x86 architecture, because they enjoy rigorous, usable specifications [19,5,20]. We focus on the former because in all cases relevant to this paper, the complexities of Power and ARM subsume those of x86.…”

“…Like Sarkar, et al's model for Power [19], and Sewell, et al's model for x86 [20], our calculus is based on an operational semantics, not an axiomatic semantics. Nevertheless, one aspect of our system does give it some axiomatic flavor.…”

“…Recent work has addressed this difficulty for some important architectures [20,19,4,3,5], but for portable, imperative programming languages the memory models are either insufficiently expressive or quite complex:…”