The definition, made precise
§3.1 showed that shared memory behavior is subtle, which gives value to precisely defining (a) what behaviors programmers can expect and (b) what optimizations implementors may use. A memory consistency model memory consistency model The precise, architecturally visible definition of shared-memory correctness in terms of loads and stores; usually admits multiple correct executions. defined in Chapter 1 — open in glossary disambiguates both at once:
A memory consistency model — or memory model — is a specification of the allowed behavior of multithreaded programs executing with shared memory. For a multithreaded program executing with specific input data, it specifies what values dynamic loads may return. Unlike single-threaded execution, multiple correct behaviors are usually allowed.
The partition view
The book adds a framing that will do quiet work for the rest of the consistency track. A memory model MC gives rules that partition executions into those obeying MC (MC executions) and those disobeying it (non-MC executions). That partition of executions in turn partitions implementations:
The model’s rules split executions; implementations are judged by which side of the split they can land on.
Two consequences worth pausing on:
- An MC implementation need not permit every MC execution. The naive implementations coming in §3.6 permit very few SC executions — they are still SC implementations. Only permitting a forbidden execution disqualifies a system.
- “Sometimes” is enough to disqualify: a non-MC implementation doesn’t produce forbidden behavior on every run — that’s what makes consistency bugs so miserable to find, and why chapter 11’s validation techniques exist.
The level of programming
One more scoping decision. A memory model could be defined at several levels of the stack; the book begins with executables in a hardware instruction set architecture, with memory accesses to locations identified by physical addresses (virtual memory and address translation are not considered). Chapter 5 will climb to high-level languages — where, for example, a compiler allocating a variable to a register affects the HLL memory model in much the same way hardware reordering of memory references affects the ISA model.
Check yourself
1.For a multithreaded program running with specific input data, what exactly does a memory consistency model specify?
2.What makes a system an "MC implementation" for a memory model MC?
3.At what level are memory models defined in this part of the book, and what analogous issue awaits at the high-level-language level?