Comparison and exchange for x86 - why is it a complete barrier?

According to this answer to the question, it looks like the LOCK CMPXCHG on x86 actually causes a complete barrier. Presumably this is what is Unsafe.compareAndSwapInt()also generated under the hood. I'm struggling to understand why this is so: with the MESI protocol, after you update the cache line, can the processor just invalidate only this cache line on other kernels, instead of flushing all the kernel storage / load buffers that performed CAS? Seems pretty wasteful to me ...

+6
source share
1 answer

Your answer, as far as I can see, is in the comments - MESI updates caches, not Store/Load buffers. But lock LOCK CMPXCHGsays: locked operations serialize all outstanding load and store operation- that’s why it needs to unload the Store / Load buffer from this CPU (and not others as detailed here ).

Thus, the current processor must perform an atomic operation with the most recent value that may be in the Store / Load buffers, so a fence is needed to actually merge this.

+1
source

All Articles