7.3Adding the Exclusive State (MESI)

book pp. 123–129 · ~3 min read

  • MESI
  • silent E→M upgrade
  • conservative S
  • Exclusive data
  • NoData-E

(First of the optimization sections — the book notes casual readers may skim §7.3–7.6.)

7.3.1 Motivation

The Exclusive state appears in almost all commercial protocols because it optimizes one extremely common pattern: read a block, then write it — typical even in single-threaded programs. Under MSI, that costs two transactions: GetS for the load, GetM for the store. Under MESI, if the GetS finds no other cache has the block, the requestor takes it in E — and the later store upgrades E→M silently, no bus transaction at all. Half the coherence traffic for the scenario, gone.

7.3.2 Getting to Exclusive

How does a GetS requestor learn it’s alone? Two options:

Wired-OR “sharer” signal

Every sharer asserts a shared wire when the GetS is ordered; requestor reads the OR: asserted → S, silent → E. Fine on a shared-wire bus — a serious headache for the non-bus implementations of §7.6.

Extra LLC state the book’s choice

The LLC distinguishes I (no sharers → respond with Exclusive-labeled data) from S (sharers may exist → plain data). Tracking S exactly would require explicit PutS transactions and sharer counts — so the protocol tracks it conservatively: S means “zero or more sharers.” Silent S evictions keep the LLC in S even after the last sharer leaves — forgoing some E opportunities, cheaply.

7.3.3–7.3.4 The protocol

The cache controller adds stable E plus transient EI^A (E’s eviction reuses PutM — no separate PutE — and resolves with a new NoData-E message). The FSM shows the stable-state view (the book’s Figure 7.4); the full table has all 13 states:

Figure 7.4 (recreated): MESI stable states — find the silent E→M arc

Own-GetS (mem not in I)Own-GetS (mem in I)Own-GetMOwn-GetMOther-GetM · Repl (silent)store (silent!)Other-GetSOther-GetM · Own-PutMOther-GetSOther-GetM · Own-PutMI — Invalid: No usable copy. A load's GetS may now return EXCLUSIVE data (→E) when no other cache has the block.IS — Shared: Read-only, not owned; silent eviction; invalidates on Other-GetM.SE — Exclusive: Valid, CLEAN, exclusive, owned (in this primer): the only cached copy, memory up-to-date. A store hits and SILENTLY transitions to M — no bus traffic. As owner, E responds to others' requests.EM — Modified: Read-write owner; potentially dirty.M

Solid = stable state · dashed = transient · click a state or an arrow.

Table 7.11 (recreated): MESI snooping — cache controller

Core eventsBus: own transactionBus: other coresBus: own transaction
StateLoadStoreReplacementOwn-GetSOwn-GetMOwn-PutMOther-GetSOther-GetMOther-PutMOwn DataOwn Data (Exclusive)

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.

Three things to click on: ISD × Own Data (Exclusive) — where the S-vs-E decision lands; E × store — the silent upgrade that pays for everything; and EIA × Own-PutM — why a clean eviction sends NoData-E instead of data.

The memory controller grows more: it must split the old IorS into I (no sharers — license to send Exclusive data) and the conservative S, and merges E and M into EorM — since the E→M upgrade is silent, memory cannot know which one the cache is in:

Figure 7.5 (recreated): MESI memory controller stable states

GetS (Excl. data) · GetMGetMGetS (owner responds)PutM (Data · NoData-E)I — No cache holds the block: MESI's memory needs THIS state split off from S: 'no sharers at all' is what licenses sending Exclusive data. Memory owns the block.IS — Zero or more caches hold S (conservative): The CONSERVATIVE S state: silent evictions mean the LLC may still say S after the last sharer left — forgoing some E opportunities, but avoiding explicit PutS traffic and wired-OR hardware. Memory owns the block and responds.SEorM — One cache holds E or M: Merged state: memory can't distinguish E from M anyway (the E→M upgrade is silent). Some cache owns the block; memory stays quiet.EorM

Solid = stable state · dashed = transient · click a state or an arrow.

Table 7.12 (recreated): MESI snooping — memory controller

Bus events
StateGetSGetMPutMDataNoDataNoData-E

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.

The EorM^D transient now resolves three ways: Data (real dirty writeback → I), NoData (stale PutM from a displaced owner → revert to EorM), NoData-E (clean E eviction → I, nothing to write).

7.3.5 Running example

The MESI run diverges from MSI immediately: C1’s GetS finds the LLC/memory in I, so C1 receives Exclusive data and takes E (not S). When C2’s GetM appears, C1 — as owner — responds and invalidates (in MSI, memory would have responded, since C1 only held S). The rest matches the MSI run, ending with both cores in S and memory freshly updated. Had C1 stored before C2’s GetM arrived, the E→M upgrade would have cost nothing — that’s the whole point.

Check yourself

1.What common pattern does the Exclusive state optimize, and by how much?

2.How does the requestor of a GetS learn it can take the block in E rather than S — and which option does the book's protocol pick?

3.Why does the MESI memory controller merge E and M into one EorM state?

4.The protocol adds a NoData-E message. What does it tell the memory controller that plain NoData doesn't?

5.In the MESI running example, C1's initial GetS returns EXCLUSIVE data (C1 → E). When C2's GetM later appears, who responds — and how does this differ from MSI?

5 questions