Deprecating Volatile in C++ | Hacker News Reader

Deprecating Volatile in C++

wg21.link

70 pointsfanf228 comments

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.

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

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

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

Doesn’t this need volatile itself since the compiler can’t introspect what the assembly is doing?

Ehm, 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... :-)

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

You'd have to do all the reads in ASM too then, but it would still be possible. It'd be terrible ergonomically.

At that point you’re really not writing C++ at all; you’re writing assembly in a .cpp file.

Nah. You could just define an inline function that'd do volatile read or write of a particular type. You don't have to hit assembly all the time.

Yes, that is part of creating inline assembly in C or C++ code:

http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html

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

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

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

How would you do something like this [1] using those?

[1] https://godbolt.org/z/Aj5bJ8

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

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

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

I 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

I 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

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

A little bit confused because it never guaranteed anything for other use cases, did it? So what's actually changing?

I guess now compilers will give warnings (and later errors) for usages that are pointless?

They could already do that though?

But now if anyone complains about such errors you can throw the standard at them.

What 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?

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

As mentioned in the link, the first version of the proposal - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p115... - has a simpler summary of what the actual changes are.

Reply on news.ycombinator.com