7.4Adding the Owned State (MOSI)

7.4.1 Motivation

The Owned owned (o) Valid, owned, and potentially dirty but NOT exclusive; read-only; other caches may hold read-only copies; the LLC/memory copy is potentially stale. defined in Chapter 6 — open in glossary state targets one specific, important situation: a cache holds a block in M (or E) and another core issues a GetS. In MSI and MESI, the owner must downgrade to S and send the data twice — to the requestor and to the memory controller, because ownership returns to the LLC/memory, which then needs an up-to-date copy. Adding O buys two things:

1. No extra data message to update the LLC/memory on that downgrade;
2. No potentially useless LLC write — if the block is written again before ever being evicted, the update was wasted anyway.

(Historically there was a third: cache-to-cache responses beat far-slower off-chip memory. With an inclusive on-chip LLC, that advantage has shrunk.)

7.4.2–7.4.3 The protocol

The high-level change is one arc: M —Other-GetS→ O, with the cache retaining ownership. From O — valid, potentially dirty, read-only, owner — the cache answers others’ GetS requests (staying O) and hands the block to GetM requestors. The detailed protocol adds two transient states: OM^A (upgrading O→M — note no D: the owner already has the data, and waits only for its GetM’s serialization) and OI^A (evicting O — via the consolidated PutM transaction; there is no separate PutO, purely for specification conciseness):

Cells worth clicking: M × Other-GetS (one message, keep ownership), O × store (the data-less upgrade begins), and OMA × Other-GetM — the subtle one: an upgrading owner that loses the race must respond with data (it’s still the owner!) and restart from IM^AD, where data will be needed.

The memory controller simplifies rather than grows: it merges M and O into MorO, because memory has no reason to distinguish them — either way a cache owns the block and memory stays quiet. Watch what happens on a GetS in MorO: nothing — no transient state, no data reclaim, unlike MSI’s M state:

7.4.4 Running example

The MOSI run tracks the MSI run exactly until C1’s second GetS reaches the bus. In MSI, C2 (the M owner) answered it with data to C1 and to the LLC/memory, downgrading to S. In MOSI, C2 answers C1 alone and moves to O — retaining ownership, leaving memory untouched (it sits happily in MorO), and deferring any memory update until C2 actually evicts the block (if ever). One data message saved now, one possibly-pointless LLC write saved later.