Why coherence can’t be the whole story
Recall chapter 2’s two invariants, informally: the SWMR invariant swmr invariant Single-writer–multiple-reader: for any memory location at any moment, either one core may write (and read) it, or some number of cores may only read it. defined in Chapter 2 — open in glossary ensures that at any time a location has either one writer (who may also read) or any number of readers; the data-value invariant data-value invariant The value of a memory location at the start of an epoch equals its value at the end of its last read-write epoch. defined in Chapter 2 — open in glossary ensures updates propagate so that cached copies always hold the most recent version.
It may seem that this defines shared memory behavior. It does not. The coherence protocol simply provides the processor core pipeline with an abstraction of a memory system. Where operations enter that abstraction — and in what order — is the pipeline’s doing:
Figure 3.1 (recreated): the consistency model is enforced by the processor core pipeline combined with the coherence protocol.
If the pipeline reorders memory operations and presents them to the coherence protocol in an order contrary to program order, then — even if the coherence protocol does its job perfectly — shared memory correctness may not ensue. That is precisely what happened in §3.1’s examples: coherent caches, wrong behavior. And it is the same division of labor identified in §2.3: consistency-agnostic coherence hides the caches, and the pipeline owns the ordering.
The rest of the chapter cashes in the second bullet: §3.7 builds a fully parallel SC implementation that treats coherence exactly as such a black box.
Check yourself
1.A system has a provably correct coherence protocol. Why can it still produce incorrect shared-memory behavior?
2.Which pair of statements is the book's summary of §3.3?
3.In the consistency-agnostic world of chapters 3–9, which component is responsible for enforcing the consistency model's ordering rules?