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.
> 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.
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).
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.
Oh wow. This literally sent a shiver down my spine. Imagine debugging that.
Also love the randmoness based ones!