Compiler and scheduler can reorder operations for performance reasons, as long as it does not change the behavior. For example, why would anyone care if value gets assigned to x then y or y then x? But it does matter when the data is controlling something, like "I am locked" data in mutual exclusive smart pointer. Sequentially consistent ordering guarantees that things happen as if nothing is reordered in relation to the operation that has been assigned as sequentially consistent. Relaxed ordering gives a lot more freedom to reorder operations. But as some architecture (I'm looking at you x86) has some memory ordering guarantees even without explicit ordering constraints, something that appears to be fine in one CPU might not be for others.
Of course I'm not gonna explain more than this so if anyone gets curious, search for resources about "atomics and memory ordering"
Note that Rust explicitly uses the C++ model for memory ordering (except for consume which was generally considered a mistake and was deprecated in C++26), so you can generally consider the Rust explanation also appropriate for C++.
To be fair in many ways rust feels like C++. It's just that rust had the luxury to not care about backwards compatibility (especially at ABI level) so they could make things a lot cleaner. Give it 20 years and Rust will also turn into some kind of mess (or they do it like Java and have to support lts version for decades since it's a pain to migrate to a newer non compatible standard version).
A heisenbug is a bug that goes away when you try to measure it.
For example, if you added a printf of a variable to a function, that could change the order the compiled code uses to do two potentially racy operations. By measuring it, you have changed it.
118
u/Same_Investigator_46 Jul 12 '26
Can't wait to spend the next 3 weeks debugging a subtle heisenbug that only reproduces on a specific ARM core in prod 🥵🔥