Menu
Are there any C or C++ compilers out there that implement "aggressive" memory consistency model for volatile variables? By "aggressive" consistency model I mean accompanying all writes to volatile variables with memory barriers in generated code.
AFAIK, this is customary behavior for C or C++ compilers on IA64 (Itanium) platform. What about x86? Is there a compiler out there that implements (or can be configured to implement) Itanium-like approach to handling volatile variables on x86 platform?
Edit: I'm looking at the code VS 2005 generates (after reading the comments) and I don't see anything that would resemble any sort of memory barrier when accessing volatile variables. This is perfectly fine to ensure memory consistency on a single-CPU multi-core x86 platform, because of MESIF (Intel) and MOESI (AMD) cache protocols.
However, this seems to be insufficient on a multi-CPU SMP x86 platform. An SMP platform would require memory barriers in the generated code to ensure the memory consistency between CPUs. What am I missing? What exactly does Microsoft mean when they claim that they already have acquire-release semantics on volatile variables?
868
Because the value of a volatile-qualified variable can change at any time, the actual variable in memory must always be accessed whenever the variable is referenced in code. This means the compiler cannot perform optimizations on the variable, for example, caching its value in a register to avoid memory accesses.
A volatile keyword in C is nothing but a qualifier that is used by the programmer when they declare a variable in source code. It is used to inform the compiler that the variable value can be changed any time without any task given by the source code. Volatile is usually applied to a variable when we are declaring it.
The volatile keyword is intended to prevent the compiler from applying any optimizations on objects that can change in ways that cannot be determined by the compiler. Objects declared as volatile are omitted from optimization because their values can be changed by code outside the scope of current code at any time.
If an array type is declared with the volatile type qualifier (through the use of typedef), the array type is not volatile-qualified, but its element type is. An array type and its element type are always considered to be identically volatile-qualified.
It should be noted that x86 CPUs reorder neither loads with other loads nor stores with other stores. As such, no explicit barriers are necessary.
The MSVC compiler will ensure that loads are not reordered with volatile loads and stores are not reordered with volatile stores (I'm now talking about reordering load and store instructions, of course), thus guaranteeing acquire and release semantics for volatile loads and stores respectively.
183
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
