3 ms·

you had to mark x volatile though which is suboptimal and generally not something that you can always do [1]: for example if you are writing a queue that transp

you had to mark x volatile though which is suboptimal and generally not something that you can always do [1]: for example if you are writing a queue that transport pointers as a library, you can't guarantee that all stores and loads to the pointed objects (and anything transitively reachable from them) are made through a pointer-to-volatile, nor you would want to. That would be equivalent to having to mark volatile objects accessed in a critical section which is obviously wrong. [1] I'm also ignoring the fact that volatile really doesn't have the right semantics in C++11/C11.

kazinator 3y ago
> volatile really doesn't have the right semantics So let's not fix that, but invent new cruft. C defines volatile for several purposes of its own, and that's it. - In a function that uses setjmp, volatile must be used to mark variables that are modified after the context is saved with setjmp but before control returns with longjmp. Otherwise there is a problem, like the longjmp spuriously restoring the original values of those variables (due to those variables having been pulled into the machine state being saved and restored, like registers). - When an asynchronous signal handler (e.g. for SIGINT) sets a global variable which is checked by the interrupted code, that variable has to be "volatile sig_atomic_t". Any usefulness of volatile for actual concurrency is courtesy of the compiler, whether empirical or documented.
- gpderetta 3y ago
  Volatile already has semantics that are both too strong and too weak to implement atomics. Reusing volatile for atomics was rejected very early during the memory model standardization process. As an extension, MSVC did for a time add atomic and acquire/release semantics to volatile. This was deprecated because it broke too much stuff. edit: after your edit, I'm not sure if you arguing for volatile-for-atomic or not.
  - kazinator 3y ago
    Well, yes; it's painfully obvious that you won't obtain, say, an atomic increment or compare-swap out of any simple combination of volatile anything, and it's more harmful than good to even try.
- jcranmer 3y ago
  volatile is truly a semantic mess. The effective definition of "suppresses optimizations" is difficult to work with, because the boundary between an optimization and weird feature interactions is incredibly murky. (e.g., don't ask what happens with volatile bitfields. Just don't.) It's better to replace it with things that have clearer semantics, even if they don't have the full functionality. The use of dedicated atomic intrinsics is one such clear replacement. Indeed I've worked with hardware where it was more obvious how to lower an atomic load or store than it was to lower a volatile load or store, because the technical definition of volatile really doesn't comport with the practical meaning of "don't optimize this" (crazy hardware does things like that).

kazinator 3y ago

> volatile really doesn't have the right semantics So let's not fix that, but invent new cruft. C defines volatile for several purposes of its own, and that's it. - In a function that uses setjmp, volatile must be used to mark variables that are modified after the context is saved with setjmp but before control returns with longjmp. Otherwise there is a problem, like the longjmp spuriously restoring the original values of those variables (due to those variables having been pulled into the machine state being saved and restored, like registers). - When an asynchronous signal handler (e.g. for SIGINT) sets a global variable which is checked by the interrupted code, that variable has to be "volatile sig_atomic_t". Any usefulness of volatile for actual concurrency is courtesy of the compiler, whether empirical or documented.

gpderetta 3y ago
Volatile already has semantics that are both too strong and too weak to implement atomics. Reusing volatile for atomics was rejected very early during the memory model standardization process. As an extension, MSVC did for a time add atomic and acquire/release semantics to volatile. This was deprecated because it broke too much stuff. edit: after your edit, I'm not sure if you arguing for volatile-for-atomic or not.
- kazinator 3y ago
  Well, yes; it's painfully obvious that you won't obtain, say, an atomic increment or compare-swap out of any simple combination of volatile anything, and it's more harmful than good to even try.
jcranmer 3y ago
volatile is truly a semantic mess. The effective definition of "suppresses optimizations" is difficult to work with, because the boundary between an optimization and weird feature interactions is incredibly murky. (e.g., don't ask what happens with volatile bitfields. Just don't.) It's better to replace it with things that have clearer semantics, even if they don't have the full functionality. The use of dedicated atomic intrinsics is one such clear replacement. Indeed I've worked with hardware where it was more obvious how to lower an atomic load or store than it was to lower a volatile load or store, because the technical definition of volatile really doesn't comport with the practical meaning of "don't optimize this" (crazy hardware does things like that).