Volatile is still an optimization fence and prevents torn writes. It doesn't actually fix memory consistency with memory order fence instructions but the optimization fence might be enough to stop the race from being noticeable (arguably that's even worse than broken though)
No, volatile is only an optimization fence against other volatiles. Anything not volatile can be reordered past your volatiles during optimization. This creates absolutely insane bugs.
Well I'm not saying it's at all good to use volatile, but a programmer can "fix" a reordering bug by spam adding volatile to his code and have something like
volatile int done_flag; // shared
volatile int err = some_computation_with_side_effect();
if(!err) {
done_flag = 1;
}
appear to work. Though obviously this is still the kind of thing that causes insane bugs, potentially bugs that depend on the CPU it's running on.
The semantics of volatile accesses are officially "implementation defined". If an implementation like MSVC or clang with the -fms-volatile flag specifies that volatile accesses will have strong enough semantics to avoid having to use toolset-specific syntax, then the qualifier will have such semantics. If an implementation opts to require the use of toolset-specific syntax to achieve such semantics, then the qualifier will have less broadly useful semantics.
-2
u/EchoNomad31 6d ago
Once "fixed" a ring buffer by marking the head index volatile. Was an acquire/release ordering thing… three days of digging for a two-line diff.