[klodolph]

With one exception, the relevant details aren't really compiler-specific, and C++20 keeps the relevant parts... if you perform two operations on volatile values, the operations can't be reordered, because the spec says so.

> Accesses through volatile glvalues are evaluated strictly according to the rules of the abstract machine.

Not the best, clearest, most useful part of the C++ spec but the core concept is there... if you perform operation A on a volatile object, then perform operation B on a volatile object, the emitted code must perform A before B. To my knowledge, this part of the C++ standard hasn't even changed wording in C++20, and isn't deprecated either.

The compiler-specific parts are things like:

1. Is this a compiler fence? (If no, the buffer in a ring buffer must also be volatile.)

2. Is this a memory fence?

3. Is there some platform-specific way in which operations on volatile objects are different?

The part you do need to know is if the operation will tear.

[pjmlp]

Thanks for putting it better than my short remark.

As addition, some of the complaints regarding the new changes might be addressed in C++23.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p213...