Atomics and mutexes constrain memory reordering. Stores and loads while holding a mutex can't be reordered so that they happen outside the mutex lock (because t

Atomics and mutexes constrain memory reordering. Stores and loads while holding a mutex can't be reordered so that they happen outside the mutex lock (because there are compiler/cpu memory barriers in mutex lock/unlock). Given that Rust's "shared xor mutable" is guarded with mutexes, atomics or other synchronization primitives, memory reordering can't violate Rust's memory safety guarantees (assuming the sync primitives are not buggy, of course). But this does not guarantee that your program logic is correct if you are sloppy with memory ordering. If you do two atomic stores, they are not guaranteed to occur in that order if they use "relaxed" ordering. This gets more complex if you're writing device drivers and communicating with peripheral devices using memory mapped i/o.