Cache invalidation really is one of the hardest problems in computer science
&gt; Cache coherency ensures that the behavior is correct, but every time a cache is invalidated and the same memory has to be retrieved from main memory again, it pays the performance penalty of reading from main memory.<p>1. First no. If any such rereads occur, they will be from the LLC (last-level cache, or L3 cache for Intel&#x2F;AMD CPUs).<p>2. Second no. IIRC, modern caches are snooping and&#x2F;or directory caches. This means that when Core#0 says &quot;I&#x27;m changing cacheline X&quot;, Core#0 knows that Core#1 has it in its L2 (or deeper) caches. So Core#0 will publish the results of that change to Core#1<p>3. The examples they gave are missing read&#x2F;write barriers, which are rather important. #2 will only happen during read&#x2F;write barriers. That is to say: your code is memory-unsafe by default. If order and cache-invalidation matters, you actually need a barrier instruction (!!!) to make sure all these messages are passed to the right place at the right time.<p>---------<p>For better or for worse, modern CPU design is about doing things thread-unsafe by default. If the programmer recognizes a problem may occur, it is the responsibility of the programmer to put the memory barriers in the right place.<p>This is because the CPU is not the only thing that can reorder things... but also the cache system... as well as the compiler. So memory barriers inform the compiler + CPU + cache system when to synchronize.<p>The original Netflix article is more precisely worded.<p>&gt; This consistency is ensured with so-called “cache coherency protocol.”<p>With a link to MESIF (F for Forwarding state, which is one such protocol &#x2F; way to share L1 cache info without going all the way to LLC or DRAM)<p>I&#x27;m pretty sure that GPUs actually invalidate the cache dumbly, without any MESI &#x2F; MESIF (or whatever). GPUs are actually really bad at these kinds of ping-pong operations and synchronization... preferring thread-fences and other synchronization mechanisms instead.<p>------<p>That being said, I think the blogpost is a good introduction to the subject. But note that its a bit imprecise with some of the low level details. I guess its correct for the GPU-world though, so its not completely inaccurate...<p>-----<p>The original Netflix article has an even more difficult problem revolving around Java&#x27;s Superclass cache and how it is affecting &quot;true sharing&quot; of caches. I&#x27;m not very familiar with JVM internals, so I lost track of the discussion at that point.