In computer programming, a variable is said to be volatile if its value can be read or modified asynchronously by something other than the current thread of execution. The value of a <code>volatile</code> variable may spontaneously change for reasons such as: sharing values with other threads; sharing values with asynchronous signal handlers; accessing hardware devices via memory-mapped I/O (where messages from peripheral devices can be received and sent by reading from and writing to memory). Support for these use cases varies considerably among the programming languages that have the <code>volatile</code> keyword. Volatility can have implications regarding function calling conventions and how variables are stored, accessed and cached.
In C and C++, <code>volatile</code> is a type qualifier, like <code>const</code>, and is a part of a type (e.g. the type of a variable or field).
The behavior of the <code>volatile</code> keyword in C and C++ is sometimes given in terms of suppressing optimizations of an optimizing compiler: 1- don't remove existing <code>volatile</code> reads and writes, 2- don't add new <code>volatile</code> reads and writes, and 3- don't reorder <code>volatile</code> reads and writes. However, this definition is only an approximation for the benefit of new learners, and this approximate definition should not be relied upon to write real production code.
In C, and consequently C++, the <code>volatile</code> keyword was intended to:
The C and C++ standards allow writing portable code that shares values across a <code>longjmp</code> in <code>volatile</code> objects, and the standards allow writing portable code that shares values between signal handlers and the rest of the code in <code>volatile</code> <code>sig_atomic_t</code> objects. Any other use of <code>volatile</code> keyword in C and C++ is inherently non-portable or incorrect. In particular, writing code with the <code>volatile</code> keyword for memory-mapped I/O devices is inherently non-portable and always requires deep knowledge of the specific target C/C++ implementation and platform.
It is a common misconception that the <code>volatile</code> keyword is useful in portable multi-threading code in C and C++. The <code>volatile</code> keyword in C and C++ has never functioned as a useful, portable tool for any multi-threading scenario. Unlike the Java and C# programming languages, operations on <code>volatile</code> variables in C and C++ are not atomic, and operations on <code>volatile</code> variables do not have sufficient memory ordering guarantees (i.e. memory barriers). Most C and C++ compilers, linkers, and runtimes simply do not provide the necessary memory ordering guarantees to make the <code>volatile</code> keyword useful for any multi-threading scenario. Before the C11 and C++11 standards, programmers were forced to rely on guarantees from the individual implementations and platforms (e.g. POSIX and WIN32) to write multi-threading code. With the modern C11 and C++11 standards, programmers can write portable multi-threading code using new portable constructs such as the <code>std::atomic<T></code> templates.
In this example, the code sets the value stored in <code>foo</code> to <code>0</code>. It then starts to poll that value repeatedly until it changes to <code>255</code>:
An optimizing compiler will notice that no other code can possibly change the value stored in <code>foo</code>, and will assume that it will remain equal to <code>0</code> at all times. The compiler will therefore replace the function body with an infinite loop similar to this:
However, the programmer may make <code>foo</code> refer to another element of the computer system such as a hardware register of a device connected to the CPU which may change the value of <code>foo</code> while this code is running. (This example does not include the details on how to make <code>foo</code> refer to a hardware register of a device connected to the CPU.) Without the <code>volatile</code> keyword, an optimizing compiler will likely convert the code from the first sample with the read in the loop to the second sample without the read in the loop as part of the common loop-invariant code-motion optimization, and thus the code will likely never notice the change that it is waiting for.
To prevent the compiler from doing this optimization, the <code>volatile</code> keyword can be used:
The <code>volatile</code> keyword prevents the compiler from moving the read out of the loop, and thus the code will notice the expected change to the variable <code>foo</code>.
The following C programs, and accompanying assembler language excerpts, demonstrate how the <code>volatile</code> 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 <code>volatile</code> objects is more verbose, making it longer so the nature of <code>volatile</code> objects can be fulfilled. The <code>volatile</code> 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 <code>volatile</code> 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.
Unlike other language features of C and C++, the <code>volatile</code> keyword is not well supported by most C/C++ implementations - even for portable uses according to the C and C++ standards. Most C/C++ implementations are buggy regarding the behavior of the <code>volatile</code> keyword. Programmers should take great care whenever using the <code>volatile</code> keyword in C and C++.
In all modern versions of the Java programming language, the <code>volatile</code> keyword gives the following guarantees:
Together, these guarantees make <code>volatile</code> into a useful multi-threading construct in Java. In particular, the typical double-checked locking algorithm with <code>volatile</code> works correctly in Java.
Before Java version 5, the Java standard did not guarantee the relative ordering of <code>volatile</code> and non-<code>volatile</code> reads and writes. In other words, <code>volatile</code> did not have "acquire" and "release" memory barrier semantics. This greatly limited its use as a multi-threading construct. In particular, the typical double-checked locking algorithm with <code>volatile</code> did not work correctly.
In C#, <code>volatile</code> 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. When a field is marked <code>volatile</code>, the compiler is instructed to generate a "memory barrier" or "fence" around it, which prevents instruction reordering or caching tied to the field. When reading a <code>volatile</code> field, the compiler generates an acquire-fence, which prevents other reads and writes to the field from being moved before the fence. When writing to a <code>volatile</code> field, the compiler generates a release-fence; this fence prevents other reads and writes to the field from being moved after the fence.
Only the following types can be marked <code>volatile</code>: all reference types, <code>Single</code>, <code>Boolean</code>, <code>Byte</code>, <code>SByte</code>, <code>Int16</code>, <code>UInt16</code>, <code>Int32</code>, <code>UInt32</code>, <code>Char</code>, and all enumerated types with an underlying type of <code>Byte</code>, <code>SByte</code>, <code>Int16</code>, <code>UInt16</code>, <code>Int32</code>, or <code>UInt32</code>. (This excludes value structs, as well as the primitive types <code>Double</code>, <code>Int64</code>, <code>UInt64</code> and <code>Decimal</code>.)
Using the <code>volatile</code> keyword does not support fields that are passed by reference or captured local variables; in these cases, <code>Thread.VolatileRead</code> and <code>Thread.VolatileWrite</code> must be used instead.
In effect, these methods disable some optimizations usually performed by the C# compiler, the JIT compiler, or the CPU itself. The guarantees provided by <code>Thread.VolatileRead</code> and <code>Thread.VolatileWrite</code> are a superset of the guarantees provided by the <code>volatile</code> keyword: instead of generating a "half fence" (ie an acquire-fence only prevents instruction reordering and caching that comes before it), <code>VolatileRead</code> and <code>VolatileWrite</code> generate a "full fence" which prevent instruction reordering and caching of that field in both directions. These methods work as follows:
The <code>Thread.VolatileRead</code> and <code>Thread.VolatileWrite</code> methods generate a full fence by calling the <code>Thread.MemoryBarrier</code> method, which constructs a memory barrier that works in both directions. In addition to the motivations for using a full fence given above, one potential problem with the <code>volatile</code> keyword that is solved by using a full fence generated by <code>Thread.MemoryBarrier</code> is as follows: due to the asymmetric nature of half fences, a <code>volatile</code> field with a write instruction followed by a read instruction may still have the execution order swapped by the compiler. Because full fences are symmetric, this is not a problem when using <code>Thread.MemoryBarrier</code>.
<code>VOLATILE</code> is part of the Fortran 2003 standard, although earlier version supported it as an extension. Making all variables <code>volatile</code> in a function is also useful finding aliasing related bugs.
By always "drilling down" to memory of a VOLATILE, the Fortran compiler is precluded from reordering reads or writes to volatiles. This makes visible to other threads actions done in this thread, and vice versa.
Use of VOLATILE reduces and can even prevent optimization.