Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • Reading Path
  • Cache Coherency Glossary
  • The Shared Course Model
  • Cache Coherency Revision Sheet
  • Why Coherence Exists8
    • Caches and Shared Data
    • Permissions and Values
      • Permission Versus Data
      • Who Has the Newest Data?
      • Dirty Responsibility
      • Epochs and Serialization
  • States and Protocols12
  • Transactions12
  • Races and Controller Design8
  • Progress and the Fabric16
  • Ordering and Synchronization12
  • Performance and Scalability12
  • Real Protocols12
  • SoC Integration12
  • Power, Clocking and Reliability12
  • Verification12
  • Debug and Bring-up12
  • Interview and Design Review17
  • Capstone: A Coherent Model Lab5
Loading lesson

‹Permissions and Values
  1. Topics
  2. Cache Coherency
  3. Why Coherence Exists
  4. Permissions and Values
  5. Permission Versus Data

Part 1 · Why Coherence Exists · All levels

Permission Versus Data

A value, permission to use it, dirty responsibility and the home's metadata answer different questions.

On this page

    Can a cache have the bytes but lack permission?

    Yes. Physical bits can remain in an invalid entry, but the core cannot use them as a coherent copy. Conversely, two caches can hold the right bytes while neither may store. Before reading this lesson, know that X is one location inside a 64-byte line, that permissions cover the whole line, and that write-back caches need not immediately update memory.

    Ask four separate questions: is this a usable copy, may the core read, may it write without another transaction, and must this controller preserve data that memory cannot supply? The SWMR rule permits a single writable copy or read-only copies. It also permits no cached copy and no active writer. See the Primer, second edition, Chapter 2 for the permission and data-value invariants.

    Read the stable states as contracts

    Cache state

    Usable value

    Core permission

    Dirty responsibility

    I

    -

    Neither read nor write

    None in this stable state

    S

    Current readable value

    Read only

    None; MOESI may have an O holder elsewhere

    E (MESI, MOESI)

    Clean value

    Read and exclusive write

    None until a store silently changes E to M

    M

    Newest value

    Read and exclusive write

    Preserve the dirty version

    O (MOESI)

    Newest value, possibly shared

    Read only

    Preserve the dirty version for the readers

    These are contracts from named protocols, not five states that every controller implements. MSI uses I, S and M; MESI adds E; MOESI adds O to MESI's states. 'Dirty' describes responsibility relative to the backing copy, not a test that two integers differ. A line can retain dirty status after software writes the original value again. The home must use protocol metadata rather than compare bytes to guess authority.

    Decision tree distinguishing I, S, E, M and O using usable data, write permission and dirty responsibility.
    Classifying stable copies by permission and responsibility; this is not a transition machine.

    A classification on the course model

    Independent stable snapshot

    C0 state / value

    C1 state / value

    H directory

    Memory

    Interpretation

    Initial

    I / -

    I / -

    U

    0

    Memory is authoritative; no cached reader or writer

    E (MESI, MOESI): clean exclusive

    E / 0

    I / -

    exclusive(C0)

    0

    C0 may store; memory is still current

    Dirty exclusive

    M / 1

    I / -

    exclusive(C0)

    0

    Only C0 may write; memory is stale

    MOESI dirty sharing

    O / 1

    S / 1

    O: C0, sharers {C1}

    0

    Two readers, no writer; C0 has dirty responsibility

    These are separate classification examples, not successive steps. H's U means no cached copy and authoritative memory. S{C0,C1} records read sharers; in MSI and MESI memory is current there. exclusive(C0) records that C0 is the exclusive holder; it need not distinguish cache E from M. O: C0, sharers {C1} records C0 as the dirty-responsible holder and C1 as a reader.

    Common pitfall

    Do not treat the word 'owner' as a universal permission bit. In this course, say exclusive holder when you mean E or M, and dirty-responsible holder when you mean M or O. An O holder cannot store while C1 retains S, even though C0 must preserve the newest value.

    Check yourself C0 is O / 1 and C1 is S / 1 while memory = 0. Can C0 store 2 locally?

    No. O is read-only. C0 must obtain exclusive write permission through H, excluding C1 before it stores. Having the newest data and responsibility for it does not remove that requirement.

    Interview

    Given a state letter, answer with permission, backing-copy freshness and responsibility. Then ask which protocol and which controller the letter belongs to. A directory's record and a private cache's local state encode different knowledge.

    Related topics

    • Course Model

    • Up: Permissions and Values

    Previous

    10 / 167

    Next: Who Has the Newest Data?

    Up next

    Up nextWho Has the Newest Data?

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Dirty Responsibility
    • Epochs and Serialization