5.4.15 · D5Memory Hierarchy & Caches
Question bank — MESI - MOESI coherence protocols
Before we start, the vocabulary these traps lean on (all built in the parent):
True or false — justify
TF1. "In MESI, the E state is logically necessary; without it the protocol breaks."
False. E is a performance optimization (silent E→M writes), not a correctness requirement. A 3-state MSI protocol is still coherent — it just broadcasts on every first write.
TF2. "A line in state M is always dirty."
True. M by definition means you wrote it and memory is stale; if it were clean you'd be in E instead.
TF3. "A line in state S is always clean in MESI."
True in MESI. Sharing requires all copies agree with memory. (In MOESI the owner is dirty-and-shared, but sharers who hold S are still reading a value that the O-owner guarantees — the S copies themselves match what the owner holds.)
TF4. "Two different caches can hold the same line in state E at the same time."
False. E means provably the only copy. Two exclusive holders contradict each other; the moment a second cache reads, both must become S (or O/S in MOESI).
TF5. "Two caches can hold the same line in S at the same time."
True. S is precisely the multiple-reader case — that's its whole purpose.
TF6. "In MOESI, several caches can hold the same line in O simultaneously."
False. There is exactly one owner per line; O designates the single cache responsible for supplying data and eventual write-back. Others are S.
TF7. "A silent E→M transition changes no data, only the state bits."
True. The store writes the cache word locally and flips the state to M; because you were the sole holder, no bus message and no other cache is affected.
TF8. "Write-through caches remove the need for a coherence protocol."
False. Write-through updates memory but does not invalidate stale copies sitting in other caches, so readers can still see old values. You still need coherence — see Write-back vs Write-through caches.
TF9. "Snooping and directory protocols implement different coherence rules."
False. They enforce the same SWMR invariant and often the same MESI/MOESI states; they differ only in how they discover who holds a line — broadcast vs a tracked directory. See Snooping vs Directory-based protocols.
TF10. "MOESI is strictly faster than MESI in every workload."
False. MOESI wins when dirty data is repeatedly shared (cache-to-cache forwarding beats memory round-trips), but it adds a state and complexity; for read-mostly or single-writer patterns MESI's behaviour is identical.
Spot the error
SE1. "After an M line snoops a BusRd and writes back, it becomes E because it's now clean."
Error: it becomes S, not E. A BusRd means another cache now wants a copy, so the line is provably shared afterward — sharing status, not clean/dirty, decides E vs S.
SE2. "BusRdX is a write on the bus; the new value travels with it."
Error. BusRdX (Read-for-Ownership) reads the current data into your cache and invalidates others; the actual store happens locally afterward. No new value is on the bus.
SE3. "A read miss always lands in S because reads are for sharing."
Error. A read that finds no other holder lands in E (sole clean owner). Only a read that observes existing copies lands in S.
SE4. "In MESI you can be dirty and shared — that's normal for shared writable data."
Error. MESI forbids dirty+shared: writing forces invalidation of all others first. The dirty+shared combination is exactly what MOESI's O adds.
SE5. "When the O owner is asked for data, it writes back to memory then forwards."
Error. The whole point of O is to forward cache-to-cache without touching memory; memory is written only when the owner is finally evicted.
SE6. "False sharing is a coherence bug the protocol should fix."
Error. False sharing is correct coherence behaviour applied to a whole cache line: two unrelated variables in one line ping-pong ownership. The fix is software layout, not the protocol. See False Sharing.
SE7. "An I-state line still holds the last value, just marked unusable."
Error. I means the line holds no valid data for that address — a hit is impossible; any access is a miss requiring a bus fetch.
SE8. "Cache coherence and memory consistency are the same guarantee."
Error. Coherence is per-address (all cores agree on the value history of one location); consistency orders operations across different locations. See Cache Coherence vs Memory Consistency.
Why questions
WHY1. "Why can't the 'dirty + shared' cell exist in MESI?"
Because MESI makes a writer invalidate every other copy before writing, so the instant a line becomes dirty it is also exclusive. No mechanism keeps other copies alive alongside a dirty one.
WHY2. "Why does E enable a silent write but S does not?"
E is a proof you're the only holder, so writing endangers no one else's correctness — no notification needed. S admits other readers who could go stale, so you must broadcast BusRdX to invalidate them first.
WHY3. "Why does MOESI avoid a memory write on M→O?"
The dirty value is likely to change again soon or be served to peers, so writing memory now is often wasted work. Keeping it in the owner and forwarding cache-to-cache defers the memory write until eviction.
WHY4. "Why must an M line write back before going to I on a BusRdX?"
M holds the only up-to-date copy. Dropping to I without writing back would destroy the sole good value, leaving memory and everyone else with stale data — violating coherence.
WHY5. "Why does adding E give real speedup for uncontended locks?"
Acquiring an uncontended lock is read-then-write on a line nobody else touches; E lets the write be an E→M with zero bus messages, so the common (uncontended) path is nearly free.
WHY6. "Why do we track state per cache line rather than per byte or per variable?"
The bus and the cache move data in fixed line-sized chunks, so the smallest unit hardware can independently own or invalidate is a line. Finer granularity would need far more state bits and bus complexity. (This is also why false sharing exists.)
Edge cases
EC1. "Core reads an address it already holds in M — what happens on the bus?"
Nothing. It's a read hit; state stays M and no bus traffic occurs — cached reads of your own dirty data are local.
EC2. "Core writes an address it already holds in M — bus traffic?"
None. M→M is a local store; you already have single-writer ownership, so no invalidation is needed.
EC3. "Two cores issue BusRdX for the same line at the same instant — who wins?"
The interconnect serializes them via bus arbitration; one grabs ownership first (lands in M), the loser's request is re-ordered after and effectively re-fetches, ending in M once the first releases.
EC4. "A line is evicted from E — does memory need updating?"
No. E is clean (matches memory), so it can be silently dropped with no write-back — one of E's cost savings.
EC5. "A line is evicted from S — write-back needed?"
No. S is clean too, and other sharers (or memory) still hold the value; silent drop.
EC6. "A line is evicted from O in MOESI — now what?"
The owner holds the only dirty copy, so eviction forces a write-back to memory. This is the deferred write MOESI has been postponing.
EC7. "Only one core ever touches an address — which states does its line pass through?"
I → (read) E → (write) M, and it stays M. It never needs S/O and never emits invalidations — the fully private, cheapest case.
EC8. "Intel's real protocol isn't plain MESI — what changed at the edges?"
MESIF adds an F (Forward) state so exactly one sharer answers read requests (fast cache-to-cache) instead of many caches or memory responding; AMD's MOESI instead keeps dirty data shareable via O. Both refine who supplies data, not the SWMR guarantee.
Recall One-line summary to lock in
Every trap here reduces to two questions per line — Am I the only copy? (E/S) and Am I dirty? (M/E) — plus MOESI's fifth answer, dirty and shared = O, all in service of the one law: SWMR.