1

I am reading Directory-Based Cache Coherence Protocols: The Basics of the book Computer architecture A quantitative approach. The following is a picture of the state transition diagram for the directory on the textbook. The state transition diagram for the directory My question is: why the block in the shared state does not handle the write hit event? In my opinion, if the block is in the shared state and the write hit event occurs, the block should go to the exclusive state. I believe that I read this chapter carefully but did not find any explanation. Is it because the diagram is only for the basic directory-based protocol?

Follow up question: The picture below is the cache state diagram of Snooping protocol. The read-only shared block is able to receive the event called Write miss for this block. Does it imply that writing a read-only block is allowed?enter image description here

cyanbuckeye
  • 25
  • 4

1 Answers1

1

Same as with MESI, a Read-For-Ownership (invalidate request) is needed to invalidate other copies of the line, so they can't get stale read hits after we modify this copy.

Otherwise the cache wouldn't be coherent. This cache doesn't need to actually receive a new copy of the data, but it does need to wait for confirmation that other caches have processed the invalidate message. So it has to go off-core and is basically the same as a cache miss, except it can avoid going to DRAM through the memory controllers.

(Note that in real CPUs, MESI is implemented more like a directory than a shared bus, despite some material defining MESI in terms of a shared bus.)

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
  • But the set of nodes that have a copy of block, or Sharers, should update, right? It seems not reasonable to contain those invalidated nodes in Sharers after a write hit. However, the state transition diagram for the directory does not include it. – cyanbuckeye Jun 07 '20 at 03:05
  • @cyanbuckeye: The picture of your textbook says `Sharers = {P}`, clearing the set and replacing it with this one member. Unlike transitions *to* shared state that do `Sharers += {P}`, adding to the existing set. So yes, you're right that's necessary, but unless I'm misinterpreting something, your book does say that for shared->exclusive. – Peter Cordes Jun 07 '20 at 03:12
  • But that line is for write miss. – cyanbuckeye Jun 07 '20 at 03:52
  • 1
    @cyanbuckeye: Yeah, a write does miss unless the line is already in Exclusive state, triggering that transition. Note that Shared state is marked as "read only", so you can't get a write hit on it. But Exclusive state is read/write, so can give write hits. It's a confusing diagram because it shows a "write miss" possibility for Exclusive. I think that's referring to the case where the tags don't match, so there's a different line in that state. Doesn't make much sense unless it's a direct-mapped cache so there's only one line that could be replaced with the line we want. – Peter Cordes Jun 07 '20 at 04:27
  • It sounds reasonable. But I took a look at the cache coherence state diagram for the snooping protocol. Then I noticed that the read-only shared block is able to receive the signal called **Write miss for this block**. Does it mean that it allows to write a read-only shared block? I put that picture under the question description. – cyanbuckeye Jun 07 '20 at 05:20
  • 1
    @cyanbuckeye: When another core writes this cache line, it has to invalidate our Shared copy to maintain coherence. Any line can be written by any core; it might have to wait for a state transition by its own and/or other caches, but it's not going to fault. As the diagram shows, a write by another core to a block that was cached in Shared state results in it not being cached anymore. So in that sense, no, you can't write a shared block. – Peter Cordes Jun 07 '20 at 05:32