> Because we're talking about cross-core guarantees of concurrency. So you actually do care about what another, or all cores are doing. This is mostly about lo

> Because we're talking about cross-core guarantees of concurrency. So you actually do care about what another, or all cores are doing. This is mostly about load/store order of an individual core. How individual core decides to order its reads and writes to memory. > Weaker CPU's (Like say POWER7) that do batching writes (you accumulate 256bits of data, then write it all at once) don't communicate what is in their write-out buffer. So you may write to a pointer, but until that CPU does a batched write the other cores aren't aware. You have to do a fence to flush this buffer (in the other cores). You can actually do same on x86 by using non-temporal stores. Although you're not talking about store ordering, but about visibility to other cores. A store won't ever be visible to other cores until it at least hits L1 cache controller. > There are some scenarios where the same situation can arise on x64 but its rarer. Yup, that's right. That's why x86 (and x64) got mfence and sfence instructions. > This is why x64 uses a MESIF-esque cache protocol [1][2]. It can tell when data is Owned/Forwarded/Shared between cores. Reordering happens before cache controller. When cache controller is involved, the store is already in progress.