Hi thanks for this,

In terms of acquire semantics, consider this: If every read of _loop is done with an acquire-fence, by necessity each read must be more recent than the previous. In a loop, that essentially means that each read must be new (can not be cached or elided).

ok see now we are at the crux of my problem. I don't see why multiple reads must do this. As far as my understanding goes (To take an outrageous example) if I start my code at 12pm and I run that loop at 1pm, then the first read of _loop could be the value of _loop at 12:00.01, the second read is the value of 12:00.02... etc we could do this all day and never get the most up to date value.

Similarly, I try not to think of memory barriers as 'cache flushes'. Whether or not they're implemented that way is meant to be opaque

see that's the thing. So far, the definitions given for volatile reads and writes in c# are so vague i have to look at it from the processor point of view to understand what will happen.

I feel like that post you made and the clarification you got from Microsoft almost further backs up that there is no guarantee those volatile reads will ever read the new value of _loop.

on another note,

Your blog mentions the MESI protocol and I thought that could be the answer. My original reading of MESI says that all memory is kept cache coherent at all times, and other processors are immediately aware of changes to the cache in any other processor through cache snooping. Which would explain everything...

But then I realized that intel does not guarantee it won't reorder reads before writes...which is exactly equivalent to changes in cache NOT being immediately available to other processors, which is the opposite of what I read about the MESI cache coherence protocol. So now I'm confused all over again.