Hacker News Reader

Comment by gpderetta | Hacker News Reader

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.

View on HN

> 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.

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.

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.

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).

Reply on news.ycombinator.com