“ReadUnique Always Fetches Data”

Module 22 · Chapter 22.5 · CHI Misconceptions Engineers Have

Project thread — 22.4 separated coherence from ordering. 22.5 separates permission from data; 22.6 tackles the CPU-only myth.

1. The Misconception

The belief: "ReadUnique always fetches data — to get a line writable, you read its data." Its subtler form is the assumption that acquiring write ownership always involves a data transfer. It is an Advanced misconception because it hides a real, avoidable cost — fetching a cache line you are about to overwrite — and because the fix requires seeing that CHI separates two things the name fuses: write permission and data.

2. Why It's Tempting

The belief is tempting because ReadUnique genuinely does fetch data — and it is the transaction engineers learn first.

• ReadUnique really returns data. The "Read" is literal: it fetches the line and grants Unique. So "ReadUnique fetches data" is true — of ReadUnique.
• It's the canonical "get writable" transaction. ReadUnique is the textbook way to gain write ownership, so it becomes the default mental model for all write-ownership acquisition.
• Permission and data feel inseparable. Intuitively, "own it to write it" and "have its data" feel like one step — so getting one seems to require the other.

The seed is real: ReadUnique does fetch, and it is the right call when you need the data. The error is generalizing "ReadUnique fetches" to "gaining Unique requires a fetch".

3. Key Terms

4. Previous Chapter Connection

This chapter refines the transaction family (Chapter 7) and the coherence states (Chapter 4). Unique is the writable state; ReadUnique, MakeUnique, and CleanUnique are three ways to reach it, differing in whether data moves. The Home grants the permission (invalidating other copies, Chapter 8) — data is a separate question.

Where 22.4 separated coherence from ordering, 22.5 separates permission from data — the same discipline of not fusing distinct guarantees. And it is a direct payoff of dropping the AXI mental model (Chapter 22.1): AXI thinks in reads that return data, but CHI's ownership transactions include data-less ones — a distinction the AXI frame erases.

5. The Claim, Precisely

State the myth falsifiably.

Claim: "To get a line into the Unique (writable) state, you must fetch its data — write ownership always comes with a data transfer."

Testable. Take a requester that will overwrite an entire line (say, memset of a cache-line-aligned block). Does it need the old data? No — every byte is replaced. Does CHI force a fetch? No — MakeUnique grants Unique and invalidates other copies with no data transfer. A write-ownership acquisition provably occurs with zero data fetched. The claim fails.

6. Why It's Wrong — The Core

Gaining Unique is about permission; data rides along only when needed.

• Unique = exclusive write permission. To reach it, the Home invalidates every other copy so you alone may write. That is a permission operation — independent of data.
• MakeUnique gains Unique with no data. For a full-line overwrite, CHI's MakeUnique invalidates other copies and grants Unique — no data returned, because you will replace it all.
• CleanUnique upgrades without re-fetching. If you already hold a valid copy and just need write permission, CleanUnique invalidates the other sharers and upgrades you to Unique — no data, you have it.
• ReadUnique fetches — when you need it. ReadUnique returns data because it is for a partial modify / read-modify-write, where the current contents matter.

So three paths to Unique — MakeUnique (no data), CleanUnique (no data), ReadUnique (data) — chosen by whether you need the data, not by a rule that ownership requires a fetch.

7. Engineering Diagram — one goal, two costs

Both paths reach Unique. ReadUnique fetches data the requester discards; MakeUnique grants the same permission with no data. The goal — write ownership — is identical; the bandwidth is not.

8. The Mechanism

The three routes to Unique, and when each is right.

The rule to carry: choose the Unique-acquisition transaction by whether you need the data — permission is separate from data. ReadUnique is one of three, correct only when the current contents matter. For a full-line write use MakeUnique; to upgrade a copy you hold use CleanUnique — both skip the fetch.

9. The Kernel of Truth

Steelman the belief.

• ReadUnique genuinely does fetch data. The claim is literally true of ReadUnique — it is a Read transaction and returns the line. The belief correctly describes that transaction.
• You often do need the data. For a partial write or a read-modify-write (increment, compare-and-swap, masked store), you need the current contents — and ReadUnique is exactly right.
• It's the common teaching example. ReadUnique is the first ownership transaction most engineers meet — so "get writable = ReadUnique = fetch" is a reasonable first model.

The truth: ReadUnique fetches, and that is correct when you need the data. The myth is only the over-generalization — that all write-ownership acquisition fetches — which misses MakeUnique and CleanUnique.

10. A Concrete Counterexample

A full-line write done the wasteful way, then the right way.

1. The workload. A requester will overwrite an entire cache line — e.g. zeroing or copying a full, aligned block. It needs none of the old bytes.
2. The wasteful path — ReadUnique. It issues ReadUnique. The Home invalidates other copies and fetches the line's data back to the requester.
3. The waste. The requester immediately overwrites every byte — the fetched data is discarded on arrival. A full cache line of read bandwidth, spent for nothing.
4. The right path — MakeUnique. It issues MakeUnique. The Home invalidates other copies and grants Unique — no data returned. The requester writes the whole line.
5. The difference. Same Unique state, same invalidations, same correctness — but MakeUnique moved zero data where ReadUnique moved a full line of it. At scale (memcpy, memset, DMA-like fills) that is enormous wasted bandwidth.

The counterexample shows ReadUnique fetching data that dies on arrival — proof that ownership did not require the fetch, and that the transaction choice matters.

11. What's Actually True

The correct model.

• Gaining Unique is about write permission, not data.
• MakeUnique grants Unique with no data — for full-line overwrites.
• CleanUnique upgrades an existing copy to Unique with no data.
• ReadUnique fetches data — correct only when you need the current contents.
• Choose by data-need — permission and data are separate in CHI.

12. Why The Distinction Matters

Believing "ownership always fetches" has concrete costs.

• You waste read bandwidth. Using ReadUnique for full-line writes fetches data you discard — a real, measurable bandwidth loss (Chapter 15.4), worst on memcpy/memset/fill paths.
• You miss an easy optimization. MakeUnique/CleanUnique are free wins the "always fetch" model hides.
• You mis-size the DAT channel. Assuming every ownership op carries data over-provisions or mis-models data traffic (Chapter 21.4).
• You mis-verify. Not covering the data-less ownership transactions leaves a coverage hole (Chapter 21.3) — MakeUnique/CleanUnique untested.

13. Design Implications

What to do once permission and data are separated.

• Use MakeUnique for full-line writes — never fetch data you will overwrite.
• Use CleanUnique to upgrade a held copy — don't re-fetch data you already have.
• Reserve ReadUnique for real read-modify-write — where the current data matters.
• Model data traffic by transaction type — data-less ownership ops carry no DAT payload (Chapter 15.4).
• Cover all three in DV — MakeUnique, CleanUnique, ReadUnique, each with its data behavior (Chapter 21.3).

14. The Trap

15. Related Confusions

• All ownership transactions fetch data. No — MakeUnique and CleanUnique gain Unique with no data.
• ReadUnique never wastes anything. No — on a full-line write it fetches data that is discarded.
• You need the data to own the line. No — you need to invalidate other copies; data is separate.
• MakeUnique is a rare corner case. No — it is the right transaction for every full-line write (memset/memcpy/fill).
• This is like an AXI read. No — CHI ownership is not an AXI data read (Chapter 22.1); permission ≠ data.

16. Answering It In An Interview

If asked "does ReadUnique always fetch data?" — the strong answer:

1. Concede the literal. "ReadUnique does — it's a Read. But gaining Unique does not require a fetch."
2. Separate the concepts. "Unique is write permission — invalidate other copies. Data is separate."
3. Give the data-less transactions. "MakeUnique gains Unique with no data for a full-line overwrite; CleanUnique upgrades a copy you already hold."
4. State the cost. "Using ReadUnique for a full-line write fetches data you discard — wasted bandwidth on copy/fill paths."

That concedes the literal truth, separates the concepts, names the data-less transactions, and states the cost — reasoning, not recital (Chapter 21.6).

17. Key Takeaways

• Gaining Unique is about write permission, which CHI separates from data.
• ReadUnique fetches data — correct only when you need the current contents.
• MakeUnique gains Unique with no data — for full-line overwrites.
• CleanUnique upgrades a held copy to Unique with no data.
• Using ReadUnique for a full-line write wastes a cache line of read bandwidth.
• The trap: treating ownership and data as one — reach for MakeUnique on full overwrites.

18. Quick Revision

"ReadUnique Always Fetches Data" — refuted. ReadUnique does return data — the "Read" is literal — but the belief over-generalizes that into "acquiring write ownership always fetches data", which is false. CHI separates two things the name fuses: write permission (the Unique state — invalidate every other cache's copy so you alone may write) and the line's data. Whether data moves depends only on whether you need it, and there are three routes to Unique: ReadUnique gains Unique with data (correct when you need the current contents — a partial write or read-modify-write); MakeUnique gains Unique with no data (for a full-line overwrite — the old bytes are irrelevant, so fetching them is pure waste); and CleanUnique upgrades an existing valid copy to Unique with no data (you already have it — just need write permission and to invalidate other sharers). The kernel of truth: ReadUnique genuinely fetches, and that is correct when the data matters — the myth is only the over-generalization that misses the data-less transactions. The trap is reaching for ReadUnique reflexively on a full-line write (memset, memcpy destination, DMA-style fill), which fetches a full cache line of data the requester immediately discards — wasted read bandwidth that is invisible to correctness (it passes every test) and shows up only in a bandwidth profile, worst on the copy/fill paths of bandwidth-bound systems (Chapters 20.2, 20.6), and entirely avoidable with MakeUnique. Separate permission from data: ask "do I need the current contents?" — no ⇒ MakeUnique, already hold it ⇒ CleanUnique, need it ⇒ ReadUnique. Next, 22.6 refutes that CHI is only for Arm CPUs.

Coming Next

Chapter 22.6 — "CHI Is Only For Arm CPUs". A myth about CHI's scope rather than its mechanics. Chapter 22.6 refutes "CHI is only for Arm CPUs" — why CHI is a coherent-interconnect standard used far beyond CPU clusters (accelerators, GPUs, DPUs, I/O-coherent devices, third-party IP), why any agent that needs coherent or I/O-coherent memory access can be a CHI node, and how the node model (RN-F, RN-I, RN-D) was designed precisely to admit non-CPU agents.