In computer programming, particularly in the C, C++, C#, and Java programming languages, the volatile keyword indicates that a value may change between different accesses, even if it does not appear to be modified. This keyword prevents an optimizing compiler from optimizing away subsequent reads or writes and thus incorrectly reusing a stale value or omitting writes. Volatile values primarily arise in hardware access (memory-mapped I/O), where reading from or writing to memory is used to communicate with peripheral devices, and in threading, where a different thread may have modified a value.
Contents
- In C and C
- Example of memory mapped IO in C
- Optimization comparison in C
- C11
- Compile time detection of race conditions
- In Java
- In C
- In Fortran
- References
Despite being a common keyword, the behavior of volatile
differs significantly between programming languages, and is easily misunderstood. In C and C++, it is a type qualifier, like const
, and is a property of the type. Furthermore, in C and C++ it does not work in most threading scenarios, and that use is discouraged. In Java and C#, it is a property of a variable and indicates that the object to which the variable is bound may mutate, and is specifically intended for threading. In the D programming language, which is based on C++, there is a separate keyword shared
for the threading usage, but no volatile
keyword exists.
In C and C++
In C, and consequently C++, the volatile
keyword was intended to
setjmp
and longjmp
sig_atomic_t
variables in signal handlers.Operations on volatile
variables are not atomic, nor do they establish a proper happens-before relationship for threading. This is specified in the relevant standards (C, C++, POSIX, WIN32), and volatile variables are not threadsafe in the vast majority of current implementations. Thus, the usage of volatile
keyword as a portable synchronization mechanism is discouraged by many C/C++ groups.
Example of memory-mapped I/O in C
In this example, the code sets the value stored in foo
to 0
. It then starts to poll that value repeatedly until it changes to 255
:
An optimizing compiler will notice that no other code can possibly change the value stored in foo
, and will assume that it will remain equal to 0
at all times. The compiler will therefore replace the function body with an infinite loop similar to this:
However, foo
might represent a location that can be changed by other elements of the computer system at any time, such as a hardware register of a device connected to the CPU. The above code would never detect such a change; without the volatile
keyword, the compiler assumes that the current program is the only part of the system that could change the value (which is by far the most common situation).
To prevent the compiler from optimizing code as above, the volatile
keyword is used:
With this modification the loop condition will not be optimized away, and the system will detect the change when it occurs.
Generally, there are memory barrier operations available on platforms (which are exposed in C++11) that should be preferred instead of volatile as they allow the compiler to perform better optimization and more importantly they guarantee correct behaviour in multi-threaded scenarios; neither the C specification (before C11) nor the C++ specification (before C++11) specifies a multi-threaded memory model, so volatile may not behave deterministically across OSes/compilers/CPUs).
Optimization comparison in C
The following C programs, and accompanying assemblies, demonstrate how the volatile
keyword affects the compiler's output. The compiler in this case was GCC.
While observing the assembly code, it is clearly visible that the code generated with volatile
objects is more verbose, making it longer so the nature of volatile
objects can be fulfilled. The volatile
keyword prevents the compiler from performing optimization on code involving volatile objects, thus ensuring that each volatile variable assignment and read has a corresponding memory access. Without the volatile
keyword, the compiler knows a variable does not need to be reread from memory at each use, because there should not be any writes to its memory location from any other thread or process.
C++11
According to the C++11 ISO Standard, the volatile keyword is only meant for use for hardware access; do not use it for inter-thread communication. For inter-thread communication, the standard library provides std::atomic<T>
templates.
Compile-time detection of race conditions
Although in C/C++ using volatile
keyword on a shared resource does not guarantee that otherwise unsynchronized threads will not attempt to access it simultaneously, it is possible to create more advanced constructs that will help to detect potential race conditions at compile time, in a way similar to how const
keyword prevents unintended modification of data. A possible implementation of such a construct has been proposed by Andrei Alexandrescu.
According to C/C++ specification, for a volatile
-qualified object shared
, a compiler will generate an error on attempting to accessing its value directly from a non-volatile
function. By using a simple helper object that acquires a corresponding mutex and removes the volatile
qualifier, it is possible to access the value of shared
in a synchronized critical section. In this case, the usage of volatile
has little in common with the original intention of its designers and acts based on a fact that it is just a qualifier: similar to const
in a way that compiler validates type correctness, yet distinguishable.
Despite preventing from optimizing some low-level code, a proper usage of the above technique can even improve program performance when providing volatile
(synchronized and slower) and non-volatile
(unsynchronized and faster) overloads of a function and making compiler choose between them when dealing with volatile
(shared) and non-volatile
(not shared) objects.
In Java
The Java programming language also has the volatile
keyword, but it is used for a somewhat different purpose. When applied to a field, the Java qualifier volatile
provides the following guarantees:
Using volatile
may be faster than a lock, but it will not work in some situations. The range of situations in which volatile is effective was expanded in Java 5; in particular, double-checked locking now works correctly.
In C#
In C#, volatile
ensures that code accessing the field is not subject to some thread-unsafe optimizations that may be performed by the compiler, the CLR, or by hardware. Only the following types can be marked volatile: all reference types, Single, Boolean, Byte, SByte, Int16, UInt16, Int32, UInt32, Char, and all enumerated types with an underlying type of Byte, SByte, Int16, UInt16, Int32, or UInt32.
Basically volatile
is a shorthand for calling Thread.VolatileRead
and Thread.VolatileWrite
. These methods are special. In effect, these methods disable some optimizations usually performed by the C# compiler, the JIT compiler, and the CPU itself . The methods work as follows:
Thread.VolatileWrite
method forces the value in address to be written to at the point of the call. In addition, any earlier program-order loads and stores must occur before the call to VolatileWrite.Thread.VolatileRead
method forces the value in address to be read from at the point of the call. In addition, any later program-order loads and stores must occur after the call to VolatileRead.Thread.MemoryBarrier
method does not access memory but it forces any earlier program order loads and stores to be completed before the call to MemoryBarrier. It also forces any later program-order loads and stores to be completed after the call to MemoryBarrier. MemoryBarrier is much less useful than the other two methods.In Fortran
The volatile
is part of the Fortran 2003 standard, although earlier version supported it as an extension. Making all variables volatile
in a function is also useful finding aliasing related bugs.