7.1Introduction to Snooping

Snooping protocols snooping protocol Cache controllers broadcast requests to all coherence controllers, which collectively "do the right thing" (the owner responds); relies on ordered — typically totally ordered — request delivery. defined in Chapter 6 — open in glossary were the first widely deployed class of coherence protocols, and they still appear in a variety of systems. Their attractions: low-latency transactions and a conceptually simpler design than the alternative, directory protocols directory protocol Cache controllers unicast requests to the block's home memory controller, whose directory tracks owner/sharer state and responds or forwards to the owner; scalable but adds indirection. defined in Chapter 6 — open in glossary (chapter 8). This chapter introduces snooping (§7.1), builds a complete MSI baseline (§7.2), then layers on optimizations — the Exclusive state (§7.3), the Owned state (§7.4), and faster interconnects (§7.5, §7.6) — before two case studies (§7.7) and a look at snooping’s future (§7.8). (The book’s own note: casual readers may skim §7.3–7.6.)

One idea

All coherence controllers observe (snoop) coherence requests in the same order and collectively “do the right thing.” Requests are broadcast — traditionally on an ordered network like a bus — to every controller, including the requestor. Seeing the same requests in the same order is what lets the distributed per-block state machines stay mutually consistent.

Watch it work, then watch it fail. Both cores want block A in M (initially owned by the LLC/memory):

Per-block order is not enough

Coherence needs only a per-block order — but traditional snooping builds a total order of coherence requests total order of coherence requests All coherence controllers observe ALL requests in one single order; subsumes every per-block order and eases implementing SC/TSO. defined in Chapter 7 — open in glossary across all blocks, because consistency models like SC and TSO care about the interleaving of different blocks. In Table 7.3’s execution, each block is requested exactly once — per-block order is trivially satisfied — yet C2 observes C1’s GetM (block A) and its own GetS (block B) in an order that lets it read the new B but the old A:

r1 = 1, r2 = 0 violates SC and TSO — even though coherence’s per-block orders all held.

With a total order (the book’s Table 7.4), the fix is automatic: C2 must process the GetM for A before the GetS for B, so once it reads B = 1 it can only read A = 1. Same start, same requests — but r1 = 1, r2 = 1.

Where the order comes from — and what it doesn’t constrain

However the network fixes the order, that mechanism is the protocol’s serialization (ordering) point serialization point The mechanism where the network fixes the order of coherence requests (bus arbitration logic, tree root); a requestor learns its own request's place by snooping the request stream. defined in Chapter 7 — open in glossary . On a bus, it’s the arbitration logic: a request is ordered the instant arbitration serializes it — though a controller may only learn its request’s position several cycles later, by snooping the stream and seeing which requests precede its own.

Requests hog the attention; responses barely matter to ordering: