Oh, you can fix it pretty simple "The compiler can always assume writes to memory via one object don't change values in memory accessed via any other object."

Oh, you can fix it pretty simple "The compiler can always assume writes to memory via one object don't change values in memory accessed via any other object." Then, if you know your code can overlap, you can use some invalidate function to mark that "memory accessed via this object was changed by some statement prior, make sure to re-read values cached in registers". Because that's the odd case where you're doing something unusual. In general, "The compiler is allowed to optimise things assuming that spooky action at a distance isn't happening". You already have something very similar for atomics, which might be hidden behind a standard library, but in any case are a sequence of "lock the bus, read/write, memory barrier", telling your CPU and your compiler that memory access cannot be reordered around the memory barrier.