Hacker News Reader

Comment by Kenji | Hacker News Reader

Of course :)

Basically this removes the volatile keyword from your code and replaces it with... nothing.

If a variable is declared volatile, it disables compiler optimizations and signals the compiler that this variable can be modified at any time (e.g. by hardware or other threads). Omitting volatile can lead to nasty concurrency bugs (e.g. if the optimizer optimizes spin locks away). In the worst case, such bugs are extremely hard to reproduce (and thus debug) but lead to deadlocks and/or crashes in case they do occur.

View on HN

> Omitting volatile can lead to nasty concurrency bugs (e.g. if the optimizer optimizes spin locks away). In the worst case, such bugs are extremely hard to reproduce (and thus debug) but lead to deadlocks and/or crashes in case they do occur.

In C and C++, volatile is not intended and must not be used for synchronisation primitives, it is not a memory fence (so it does not force cache coherency and does not prevent operations reordering) and operations on volatile variables are not atomic. Its primary use case is memory-mapped IO (with a sub-use case of preventing eliding memory operations affected by inline assembly). If a lock is broken because `volatile` is disabled, it's probably incorrect in the first place.

All `volatile` does[0] is forbid elision of loads and stores.

[0] again in C or C++, Java and C# have completely different semantics

While you are absolutely correct, you will find no shortage of experienced employees at large companies that will disagree. In fact, they will insist that the only purpose of volatile is a primitive for synchronization. I actually had a conversation where a developer insisted that by declaring a variable volatile all operations on it were atomic.

Of course at this same company a developer insisted that if you use the mongoDB client libraries in your software, your software can never have data consistency problems.

If those developers target Visual Studio exclusively, they are actually correct: https://msdn.microsoft.com/en-us/library/12a04hfd.aspx

That is pretty entertaining. It is also a good reason to never use microsoft development tools.

Except on ARM where the volatile mode is iso unless /volatile:ms is explicitly specified.

Thanks for clearing that up. I worked with threading a lot in C# hence my misconception that it could be used for spinlocks in C/C++ too.

Yeah C#'s volatile has much larger semantics. IIRC on top of preventing the elision of loads and stores on the volatile, it prevents reordering of memory accesses across accesses to the volatile[0] and disables thread-unsafe optimisations (e.g. thread-local caching).

And It looks so ... non threatening. No weird obfuscated instructions, no strange looking if ... Just defining something.

That would also break the trick of declaring something `const volatile`. While that seems like a contradiction, I've heard of it being used to force the compiler to include a symbol in the final object file. In particular, I've seen it used to make a poor-man's plugin architecture.

It's not as crazy as you think. "volatile" means that something else other than us can change the value, somehow. "const" means that we aren't allowed to write to it.

So what is that? It's any kind of input. Like memory mapped GPIO.

Reply on news.ycombinator.com