Hi All,
I just came across a discussion about how the volatile variables are implemented. Essentially the volatile variable is one which can change its value without the running code actually modifying it. A separate thread, hardware. I have seen the use of volatile keyword in interlocked APIs.
https://msdn.microsoft.com/en-us/windows/desktop/ms683614
There are equivalent kernel APIs as well to achieve this.
I have an understanding that the volatile variables are never cached at achieve this. My questions:-
-
The volatile keyword in itself is a compiler directive. During the time the code is being compiled, the compiler does not know what memory location the variable will be kept in. So it cannot make a decision where the variable lands up during execution. So it cannot decide if the variable will fall in cached area or un-cached region.
-
The only option that the compiler has at this point it to add memory barriers, across the code which is accessing the variable.What this means is that the entire cache line (64bytes), where this variable falls, will be flushed out to the memory (or to the next level of coherency), in order to reflect the updated value of the variable in the memory.
-
Now another dimension to this discussion would be the presence of architecture specific primitives, like “lock” prefix present in X86 processors. If lock guarantees atomic increment of the variable in memory, we can disallow the use of memory barriers IF WE CAN KEEP THE VARIABLE in memory. This will greatly eliminate the cost of barriers. But the problem is how does a variable land in uncached region (compiler does not know where the uncached region is).
Please help with in-sights.
Thanks
Ajitabh