No, volatile wouldn’t be helpful at all, and certainly not for this reason. It would just give that first read “acquire” semantics instead of effectively relaxed, but either way will compile to similar asm that runs a load instruction. if you get a dirty value from a CPU cache CPU caches are coherent, so anything … Read more
Basically, volatile announces that a value might change behind your program’s back. That prevents compilers from caching the value (in a CPU register) and from optimizing away accesses to that value when they seem unnecessary from the POV of your program. What should trigger usage of volatile is when a value changes despite the fact … Read more
Up through the C++20 standard, ostream::operator<< has the following overloads, among others: ostream& operator<< (bool val ); ostream& operator<< (const void* val ); When you pass in a volatile pointer, the second overload can’t apply because volatile pointers cannot be converted to non-volatile without an explicit cast. However, any pointer can be converted to bool, … Read more
asm volatile(“” ::: “memory”); creates a compiler level memory barrier forcing optimizer to not re-order memory accesses across the barrier. For example, if you need to access some address in a specific order (probably because that memory area is actually backed by a different device rather than a memory) you need to be able tell … Read more
There are read barriers and write barriers; acquire barriers and release barriers. And more (io vs memory, etc). The barriers are not there to control “latest” value or “freshness” of the values. They are there to control the relative ordering of memory accesses. Write barriers control the order of writes. Because writes to memory are … Read more
I’ve used volatile where I’m not sure it is necessary. Let me be very clear on this point: If you are not 100% clear on what volatile means in C# then do not use it. It is a sharp tool that is meant to be used by experts only. If you cannot describe what all … Read more
Before I go into this explanation, you need to understand one optimization that compilers do (my explanation is very simplified). Suppose that somewhere in your code you have such a sequence: int x = a; int y = a; It is perfectly valid for a compiler to re-order these into: // reverse the order int … Read more
Rather than explaining what volatile does, allow me to explain when you should use volatile. When inside a signal handler. Because writing to a volatile variable is pretty much the only thing the standard allows you to do from within a signal handler. Since C++11 you can use std::atomic for that purpose, but only if … Read more
A pointer of the form volatile int* p; is a pointer to an int that the compiler will treat as volatile. This means that the compiler will assume that it is possible for the variable that p is pointing at to have changed even if there is nothing in the source code to suggest that … Read more
The effect of the volatile keyword is approximately that each individual read or write operation on that variable is made atomically visible to all threads. Notably, however, an operation that requires more than one read/write — such as i++, which is equivalent to i = i + 1, which does one read and one write … Read more