Maintaining Cache Coherence with MESI

Explains the need for cache coherence in multi-core systems, the use of snoopy protocols to monitor when shared data changes state, and the specific case of MESI: Modified, Exclusive, Shared, Invalid.

[@aliorkunozkan1910]

Hi professor, this is a wonderful video, thanks for the ramp-up!

[@88564894654984561653]

Goat

[@user-um8qs6vs5z]

Thank you sir

[@nitinagrawal6637]

Thanks for nice explanation. I have doubt about if both CPUs issue write request to the same data location, then how it is resolved? As it seems to be the race condition then do I need to synchronize this scenario or what?

[@JacobSchrum]

It absolutely would be a race condition, and you would need to assure correct behavior with synchronization at the level of code. However, this coherence protocol would assure that any subsequent reads make sense, meaning that you can't do two simultaneous reads and get different values.

[@koustav2826]

When CPU 1 performs the Read operation will it fetch the new data which is modified by CPU 2 or it will get the old data that was there before CPU 2 modified it?

[@nitinagrawal6637]

If CPU-2 modifies the data then it will invalidate the data with CPU-1, so CPU-1 will be fetching the data from CPU-2 cache.

[@DhananjaySureshGade]

In Invalid state, does modified cache update the memory or it will just update the another shared cache?

[@JacobSchrum]

If a cache entry enters an Invalid State, then its contents will never be written back to memory. A cache line enters an Invalid state when the shared data is written/modified within another cache. So, the cache contents that eventually get written back to memory will come from a Modified or Shared cache line that corresponds to the same one that was Invalidated in some other cache.

[@hamdaniibrahim8693]

ESI

[@zxuiji]

Uh, no cache needs to snoop on another, they can all just pay attention to what's on the bus, if the address matches what it's working with then it can do the usual. I would argue however that both the CPU & cache should not be invalidating anything, if they're told to write then they write, f**k the data consistency, that's for the dev EXCLUSIVELY to sort out. The only thing that needs care is the main lock used for syncronising software locks, a simple chip looping through the each core's dedicated inputs to it is enough to decide who gets the main lock. Anywhere else the hardware should not care at all about data consistency, that's fully a problem for software, if at all.

[@JacobSchrum]

At 1:34 I say that the caches are snooping on signals sent by the caches to each other, and these signals are indeed sent on the bus, but I suppose I could have been more precise with my language. As for whether or not MESI or snoopy protocols in general are any good is an issue you need to take up with computer engineers. The point of this video is to explain a protocol that is used in actual multicore systems. However, if by dev you mean the person writing user programs, then they most definitely should not be responsible for the contents of caches. Cache contents are meant to be invisible/transparent to the programmer in most cases, since user programs work at the level of memory, not the cache (though there are a few exceptional commands that allow for some cache manipulation, and these have led to some scary back channel exploits).

[@zxuiji]

@@JacobSchrum No, that one scenario of which to write SHOULD be the devs problem as it's THEIR data it effects, should be caught via the signal handler with something like SIGCLASH, then the dev can check what clashed and decide which to keep or whether to abandon them complety, as far as they're concerned it's still normal memory