5 ms·
The headline is misleading. "We propose deprecating most of volatile. [...] The proposed deprecation preserves the useful parts of volatile, and removes the du
by 0xcde4c3db 7y ago
The headline is misleading.
"We propose deprecating most of volatile. [...] The proposed deprecation preserves the useful parts of volatile, and removes the dubious / already broken ones."
This is an important distinction to make because people sometimes overreact to misuses of volatile by effectively claiming that it's useless or has no meaning.
- deaddodo 7y agoCorrect. More specifically: "Continue supporting the time-honored usage of volatile to load and store variables that are used for shared memory, signal handling, setjmp / longjmp, or other external modifications such as special hardware support." Which is what people want and use volatile for in the vast majority of cases. Removing that functionality would render driver, OS and embedded development a pain.
- lisper 7y ago> Removing that functionality would render driver, OS and embedded development a pain. It would be worse than "a pain", it would actually make it impossible. There is no way other than "volatile" to guarantee that a load or a store to/from a particular memory address happens at a particular time (AFAIK).
- sokoloff 7y agoThere are non-portable means in most implementations (via asm extensions). Obviously, this is more work and much less convenient than a volatile keyword that gives you the functionality.
- saagarjha 7y agoDoesn’t this need volatile itself since the compiler can’t introspect what the assembly is doing?
- jacobush 7y agoEhm, no, once you are in assembly, you do whatever you want to do. There is no compiler to mess things up for you. (Although, it's leaving that to you hehe... :-)
- notimetorelax 7y agoI think the compiler still needs to know that the value might be modified from the outside. Otherwise it might optimize the read operation away from the codepath.
- simcop2387 7y agoYou'd have to do all the reads in ASM too then, but it would still be possible. It'd be terrible ergonomically.
- srfilipek 7y agoYes, that is part of creating inline assembly in C or C++ code: http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
- aardvark179 7y agoYou should.be able to enforce it with the memory ordering supported since either C++11 or 14 (can’t recall which). It wouldn’t be quite as easy to write down, but might provide stronger guarantees than the volatile semantics.
- the8472 7y agocompilers are still allowed to optimize atomics, e.g. eliminating redundant reads. they are not with volatile, e.g. when you need exactly-once semantics for IO ports.
- asveikau 7y agoI disagree. Guaranteeing that the system behave as if operations have relative ordering is not the same as making sure an operation explicitly happens due to its side effects. They are entirely separate problems. A valid optimization for the former but not for the latter would be to coalesce redundant operations.
- FartyMcFarter 7y agoHow would you do something like this [1] using those? [1] https://godbolt.org/z/Aj5bJ8 https://godbolt.org/z/Aj5bJ8
- amluto 7y agoI would argue that this particular example is useless. A volatile variable at file scope can easily be IO memory. A volatile static at function scope? Not so easy.
- FartyMcFarter 7y agoIt can be set by a debugger for example. In any case, the scope of the variable was not the point of the question. The behaviour doesn't really change if you make the variable a static file-scoped one.
- kabdib 7y ago"volatile" is really insufficient to work with modern memory systems. Is there total ordering, or is it another episode of Bus Master Wild West? Are writes combined? Do reads bypass the write queue, stall, or dig out as-yet-uncommitted values? How sensitive is the hardware to "harmless" extra reads or writes? Let's not forget cache protocols, and what happens to in-flight operations on a fault (sometimes partially executed instructions have to be "finished-up" by fault handlers, whose memory operations can be different in emulation from the actual native instructions). volatile is a weak tool in the face of all the stuff that hardware folks do to achieve performance or cost goals. Most of the platforms I've worked with use abstraction layers that bottom-out in compiler intrinsics or assembly language. I'm deeply suspicious when I see code using bare volatile declarations, as the code is often wrong.
- MaxBarraclough 7y agoI don't think that's right. At least according to [0] it's neither sufficient nor even necessary to use volatile for concurrent code. My understanding is that it's really only useful for memory-mapped IO, and to get setjmp/longjmp to play nice. [0] https://stackoverflow.com/a/2485177 https://stackoverflow.com/a/2485177
- WalterBright 7y agoI thought a lot about what to do about volatile when designing D. volatile is deeply embedded in the C++ type system, and is a very semantically expensive feature for what seems like little gain. The solution was to replace volatile with a compiler intrinsic load and an intrinsic store. Those get special treatment in the code generator, and the rest of the type system does not have to carry the burden. https://dlang.org/phobos/core_bitop.html#.volatileLoad https://dlang.org/phobos/core_bitop.html#.volatileLoad
- kibwen 7y agoIndeed, exposing volatile read/write as library operations rather than making volatility be an intrinsic property of a variable via the type system is also what Rust settled on.
- mehrdadn 7y agoA little bit confused because it never guaranteed anything for other use cases, did it? So what's actually changing?
- antisemiotic 7y agoI guess now compilers will give warnings (and later errors) for usages that are pointless?
- mehrdadn 7y agoThey could already do that though?
- antisemiotic 7y agoBut now if anyone complains about such errors you can throw the standard at them.
- FartyMcFarter 7y agoWhat is an example of using volatile that the compiler can conclude is pointless? I find it hard to imagine non-contrived examples, since the point of volatile is to tell the compiler "don't assume or optimize any access to this variable - entities unknown to you can read/write it at any moment". If the compiler can't make such assumptions, how can it diagnose whether there's a point or not?
- antisemiotic 7y agoThere are some examples mentioned in the link, like volatile non-pointer non-reference variables. This can't be used for the real purpose of volatile (memory-mapped IO, etc) and could only result from someone confusing volatile with atomic, so it's safe to deprecate these.
- deleted 7y ago[deleted]