The Exclusive exclusive (e) Valid, exclusive, and clean; read-only; no other cache has a valid copy and the LLC/memory is up-to-date; treated as an ownership state in this primer (not all protocols agree). defined in Chapter 6 — open in glossary state buys the same thing here as in snooping: read-then-write in one transaction instead of two, thanks to the silent E→M upgrade. The optimization is independent of protocol class — but the ownership question returns with new consequences.
The ownership decision
As before, the crux: after the directory grants a block in E, who responds to the next request? The cache may have silently upgraded to M — or not.
E is owned this primer’s choice
Simple: the E (or M) cache is the owner, so the directory forwards requests to it. The cost: no silent E eviction — an explicit PutE tells the directory it owns the block again. Since E blocks are clean, the PutE carries no data.
E is not owned
Silent PutE becomes legal — but on a request, the cache might be in E (either may respond), M (the cache MUST respond), or gone (the directory must). Solutions: have both respond and let the requestor sort it out (the SGI Origin’s way — §8.8.1), or forward-and-notify.
The protocol
Two significant changes from MSI: the I→E transition (a GetS reaching a directory in I returns Exclusive-labeled data) and the PutE transaction. Explore — the cells that matter are ISD × Exclusive Data, E × store (silent!), and EIA × Put-Ack (a clean eviction where no data ever moved):
Table 8.3 (recreated): MESI directory protocol — cache controller
| Core events | Forwarded network | Response network | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| State | Load | Store | Replacement | Fwd-GetS | Fwd-GetM | Inv | Put-Ack | Exclusive Data from Dir | Data from Dir (ack=0) | Data from Dir (ack>0) | Data from Owner | 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.
At the directory, the E state deserves a careful reading — it really means E-or-M, because the silent upgrade is invisible from here. Watch how its row accepts either a PutE (clean, no data) or a PutM (dirty, with data) from the owner:
Table 8.4 (recreated): MESI directory protocol — directory controller
| Requests | Responses | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| State | GetS | GetM | PutS (not last) | PutS (last) | PutM+data from Owner | PutM from Non-Owner | PutE (no data) from Owner | PutE from Non-Owner | Data (from old 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.
One more subtlety the directory inherits: PutS-Last now carries extra weight. Only a precise sharer count can tell when the last sharer leaves — and only then does the directory return to I, re-arming the Exclusive-data grant for the next reader. Explicit PutS and the E optimization reinforce each other (§8.7.4 completes that argument).
Check yourself
1.In this MESI directory protocol, why must an E block's eviction use an explicit PutE?
2.The directory has separate E and M states, yet its E state 'really means E-or-M.' Why?
3.How would the protocol change if E were NOT an ownership state?
4.Why does PutS-Last matter MORE in MESI than it did in MSI?