Use a generic write-back cache model here, not an ACE opcode-to-state mapping. I means no valid copy; S means a clean readable shared copy; E is a clean exclusive copy; M is a writable dirty copy. In MOESI, O is a dirty shared copy that retains responsibility for supplying or eventually writing back the newest value. Another S copy does not make backing memory current.
The important distinction is permission versus value. Sharing value 7 is safe while memory contains 0 only if the protocol retains a responsible dirty holder and routes reads correctly. A cache cannot silently discard its last dirty copy. Controller construction belongs in the linked Cache Coherency course.
MESI and MOESI: who carries the dirty responsibility? — worked trace
Illustrative isolated example; not measured silicon behaviour.
Step | C0 | C1 | Memory / obligation |
|---|---|---|---|
Initial | M, X=7 | I | 0; C0 holds the newest data |
Generic MESI shared read completes | S, X=7 | S, X=7 | This exercise writes back 7 before declaring both copies clean |
Alternative MOESI shared read completes | O, X=7 | S, X=7 | May remain 0; C0 retains dirty responsibility |
O later leaves the system | Cannot just discard 7 | Retains its valid copy under protocol control | Resolve dirty responsibility by the chosen protocol before releasing it |
No. The O copy identifies unresolved dirty responsibility. The protocol must obtain the newest value 7 or first make memory current. An S copy elsewhere does not prove memory is up to date.
Read first: Specialist course: assumptions behind state/value traces
Modified: line is dirty, only this cache has it. Exclusive: line is clean, only this cache has it. Shared: line is clean, multiple caches may have it. Invalid: line is not in this cache.
This is an abstract plain-MESI example, not the ACE state encoding. Stable states omit work in flight. A local write request from Shared must first obtain unique permission and resolve other copies; it must not update the line merely because an upgrade request was sent. A dirty line cannot simply be discarded on an invalidation that requires its newest data to survive.
Shared-to-writer permission transfer in an abstract MESI system
Initially C0=S/0, C1=S/0 and memory=0 for X in one illustrative line L. C0 wants to store 9. Assume one per-line coordinator, no competing writes or reset, and eventual delivery/service. The coordinator waits for C1's invalidation acknowledgement before granting C0 permission. This chosen sequence is not a complete ACE or CHI encoding.
Milestone | C0 | C1 | Memory / newest value |
|---|---|---|---|
Initial | S/0; may read | S/0; may read | Memory 0; newest 0 |
C0 requests upgrade | Pending; may not store 9 yet | S/0 | Memory 0; newest 0 |
C1 invalidates and acknowledges | Still pending grant | I; no readable copy | Memory 0; newest 0 |
Grant reaches C0; store commits | M/9; only writer | I | Memory 0; newest 9 in C0 |
C0 later writes back and evicts | I after completion | I | Memory 9; newest 9 |
What to notice
Before the grant, a pending request is not a second writable copy.
After the store, memory can lag without a bug; the dirty copy remains responsible for preserving 9.
Only after the grant reaches C0 and the store commits. Until then permission is pending. Afterwards C0 holds the only newest value, 9, while memory is 0; discarding it before a completed transfer of data/responsibility would lose the write.
Conceptually, a clean makes dirty data visible at a specified point while retaining a valid copy; an invalidate removes a local copy under an ownership contract; a combined operation performs both in a defined order. Exact instruction names, cache levels, target point (such as PoC/PoU), completion and effects are architecture-specific—'flush' is too ambiguous without those details.
For non-coherent DMA, follow the platform DMA API for mapping, synchronisation and ownership transfer. CPU-produced data may need cleaning before device reads; device-produced data may require invalidation before CPU reads. The exact sequence also depends on direction, barriers and shared-line ownership. Do not apply a universal flush recipe to hardware-coherent DMA or invalidate unrelated dirty CPU data.
Use the architecture-reported maintenance granule and alignment rules; do not assume a universal 64-byte line.
PoC (Point of Coherency) vs PoU (Point of Unification) matters for maintenance scope.
Hardware coherency doesn't eliminate all software maintenance needs.
MESI letters describe stable permissions; an upgrade request is not yet permission to write.
Cleaning, invalidating and publishing data are different operations with platform-specific completion rules.
For non-coherent DMA, transfer ownership through the platform API instead of guessing a flush instruction.