Why did we have to read from memory in line 3? Isn't x in P3's cache?

Was also coming here to post this. It seems like a mistake to me but then the same pattern is replicated on actions 5/6. I suppose it doesn't make sense to specify where the data is coming from in the case of a write action since the data being written is computed by P3, not read from a cache or memory. Maybe the "Data from" column refers to the location the data stored in x was originally read from?

Agreed. It looks like a BusRdx only needs to fetch on a write miss here. If there's no miss, I don't think it needs to fetch from mem first.

https://en.wikipedia.org/wiki/MSI_protocol

I also wonder, why for action 4 we don't do a bus write? I thought that since P3 modified x, when P1 goes to read x, we need both a bus read and a bus write, since P3 needs to write x back to memory.

@Claire I don't think that P3 actually needs to write the value of X to memory when it writes to X -- this is one of the funky things with the write-back policy -- I think as long as the dirty bit is marked and all other caches invalidate their lines that contain X (if they contain such lines), then no costly write to memory is necessary. It's imperative, however, that action 4 reads from P3's cache because that's the only place where a valid copy of X's cache line exists!

@trip Agree with the point that P3 can directly provide data to P1 without writing back to memory. But in this case, I think there is still a write back to memory, because in step 5 P2 reads from memory.

In step 4 when P1 reads x from P3's cache, at some point the value of x must get written from P3's cache to memory. Does this bus write occur before or after P1 reads from P3's cache? Or is my question flawed since P1 cannot even read directly from P3's cache, so P3 has to write to memory first?

I believe your question is flawed since different processors can't read from other processor caches. My understanding is that when a cache block is modified, its new value is announced over the bus, and is only announced once.

@swkonz Actually I think cache controllers can communicate with each other without first going through system memory. I'm drawing from slide 24 here. In that diagram, P1's cache controller is reading directly from P0's cache controller.

This seems like a simple model where each cache miss for each processor would require the processor to fetch data from memory. But once the processor has the value in cache, the cache controller would assign a state to that cache line and be able to communicate with other processors’ cache controller through the bus.

So, what we're learning from this is that each processor can read from another processor's cache. In this case, when do we actually need to trigger a writeback? In the previous slide, the state diagram indicated that when we move from M to S for a cache line we need to trigger a writeback?

Whenever a processor needs to give up the M state for a cache line, regardless of whether it's going to I or S, it has to flush the line out to memory first. That way, whoever else wanted access (whether it was a readX or just a read) can get access to the most recent version of the variable. Even if the 'read' was from the cache of another processor, under the hood I believe the flush is still necessary (at least that's what subsequent class examples have shown).