Il 13/10/26 12:24, Andrey Semashev via Std-Discussion ha scritto:
> You got it backwards. If the standard doesn't say volatile operations
> are atomic then they are not. Or put it another way, you cannot rely on
> them being atomic. Atomicity is not implied, the standard must
> explicitly require an operation to be atomic for an implementation to
> make an effort in making them atomic in the compiled program.

Devil's advocate here: can an implementation say that reading a
`volatile int x` is defined as doing `atomic_ref<int>(x).load()`?

(Same for the rest of operations.)

If yes, would that make concurrent access to volatile ints not subject
to data races?

Thanks,
--
Giuseppe D'Angelo