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 serves the same master here as in snooping: keep dirty data in the fast cache, out of the slow LLC/memory. Adding it changes the directory protocol in three ways:
- A cache in M that observes a Fwd-GetS transitions to O without (immediately) copying the block back to the LLC/memory.
- More requests are satisfied cache-to-cache — the O owner keeps answering readers and writers that MSI’s directory would have had to serve from stale-prone memory.
- The flip side: more transactions take three hops. Requests the MSI directory answered itself in two hops now get forwarded to the O owner.
The cache controller — and a real upgrade at last
This is the largest table in the chapter — fifteen states. Two new transients earn the spotlight. Start with the O row and its store event:
Table 8.5 (recreated): MOSI directory protocol — cache controller
| Core events | Forwarded network | Response network | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| State | Load | Store | Replacement | Fwd-GetS | Fwd-GetM | Inv | Put-Ack | Data from Dir (ack=0) | Data from Dir (ack>0) | Data from Owner | AckCount from Dir | Inv-Ack | Last-Inv-Ack |
Cell format: action / next state (next state omitted when unchanged) · blank = event ignored · shaded = impossible. Click any cell or state chip.
Click a transition cell for its plain-English explanation, or a state chip for its invariants.
OMAC: the data-less upgrade MSI never had
An O owner that wants to write already holds valid data — the only things missing are permission and the sharers’ invalidations. So its GetM waits for the directory’s AckCount (the C) and the Inv-Acks (the A) — and no data ever moves. Compare MSI’s admitted simplification back in §8.2, where the directory shipped a full data block even to a cache that already had one. (Note the superscript here reads awaiting-Acks/AckCount — the ch08 notation, not ch07’s awaiting-own-request.)
The demotion race: OMAC (or SMAD) sees a Fwd-GetM or Inv
Another core’s GetM was serialized at the directory before ours. We must respond as the state we were — data if owner, Inv-Ack if sharer — and demote to IMAD: our own GetM is still in flight, but the cheap upgrade has degraded into a full I→M transaction that now needs data too. It is the directory-protocol echo of chapter 7’s window of vulnerability — issue order means nothing; directory serialization order rules.
The directory controller — no transients at all
MSI’s directory needed SD to wait for the old owner’s data during an M→S handback. MOSI deletes the wait itself: on a GetS, the M owner answers the reader directly, keeps ownership, and downgrades to O — no data ever flows to the directory, so the directory hops straight from M to O with nothing to wait for:
Table 8.6 (recreated): MOSI directory protocol — directory controller
| Requests | |||||||||
|---|---|---|---|---|---|---|---|---|---|
| State | GetS | GetM from Owner | GetM from Non-Owner | PutS (not last) | PutS (last) | PutM+data from Owner | PutM from Non-Owner | PutO+data from Owner | PutO from Non-Owner |
Cell format: action / next state (next state omitted when unchanged) · blank = event ignored · shaded = impossible. Click any cell or state chip.
Click a transition cell for its plain-English explanation, or a state chip for its invariants.
Read the O row’s two GetM columns side by side — the protocol splits on who is asking:
- GetM from the Owner (the upgrade): send the AckCount directly to the requestor — there is no Fwd message to piggyback it on — plus Inv to the sharers. No data.
- GetM from a Non-Owner: append the AckCount to the Fwd-GetM; the old owner passes it along inside its Data[ack=n] response. The sharers’ Inv-Acks flow straight to the requestor either way.
Eviction bookkeeping rounds out the row: an O owner leaves with PutO+data (its copy is dirty, so unlike PutE the data must travel), returning the directory to S if sharers remain.
Check yourself
1.Adding O changes the directory protocol in three ways. Which three?
2.What does the state OM^AC mean, and why is there no D in it?
3.MOSI's DIRECTORY controller has no transient state at all — MSI's needed S^D. What eliminated it?
4.A cache in OM^AC (or SM^AD) receives a Fwd-GetM or Inv. What happened, and what must it do?
5.How does the AckCount reach a GetM requestor when the block's directory state is O?