Hacker News Reader

Comment by lisper | Hacker News Reader

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

View on HN

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

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

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

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.

Reply on news.ycombinator.com