Volatile Variables in C 11

The introduction of a multi-threaded machine model in the C 11 standard raises questions about the behavior of volatile variables, which have traditionally been used to prevent optimization that could result in undefined behavior in concurrent environments.

In C 98/03, the lack of recognition of multi-threading in the memory model meant that the compiler could optimize out the read of a volatile variable, leading to the infamous example of an endless while loop waiting for a variable to change its value.

However, the C 11 memory model acknowledges the possibility of concurrent access to variables. Does this mean that volatile is now deprecated?

Compiler Optimizations and Undefined Behavior

The answer lies in the nuanced nature of the C 11 memory model. While it recognizes multi-threading, it does not eliminate the possibility of undefined behavior when accessing variables without proper synchronization. Even in a multi-threaded environment, non-atomic access to shared variables remains undefined.

volatile int x;
void func() {
x = 0;
while (x == 0) {}
}

Therefore, in our example code, the compiler is still free to optimize away the read of x in the while loop, resulting in undefined behavior. Volatile only affects memory accesses, not threading behavior.

Memory Barriers and Threading Integrity

Threading integrity requires proper synchronization mechanisms to ensure the visibility of writes in one thread to another. The C 11 memory model specifically defines when and how writes become visible to other threads. volatile does not address this requirement.

volatile guarantees that the compiler cannot optimize away memory reads from a variable, but it does not provide any guarantees about thread visibility. Memory barriers, issued by synchronization constructs like locks or atomic operations, are necessary to ensure that writes are synchronized among cores.

Conclusions

In C 11, volatile remains relevant for preventing optimizations that could lead to incorrect memory accesses. However, it is not sufficient for multithreaded programming. Proper synchronization mechanisms are still required to guarantee thread integrity and defined behavior in concurrent environments.