volatile (computer programming)
In computer programming, a value is said to be volatile if it can be read or modified asynchronously by something other than the current thread of execution.
The value of a volatile
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 you can send and receive messages from peripheral devices by reading from and writing to memory).
Support for these use cases varies considerably among the several programming language that have the volatile
keyword.
Volatility can have implications regarding function calling conventions and how variables are stored, accessed and cached.
In C and C++
[edit]In C and C++, volatile
is a type qualifier, like const
, and is a part of a type (e.g. the type of a variable or field).
The behavior of the volatile
keyword in C and C++ is sometimes given in terms of suppressing optimizations of an optimizing compiler: 1- don't remove existing volatile
reads and writes, 2- don't add new volatile
reads and writes, and 3- don't reorder volatile
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 volatile
keyword was intended to:[1]
- Allow access to memory-mapped I/O devices.
- Allow preserving values across a
longjmp
. - Allow sharing values between signal handlers and the rest of the program in
volatile
sig_atomic_t
objects.
The C and C++ standards allow writing portable code that shares values across a longjmp
in volatile
objects, and the standards allow writing portable code that shares values between signal handlers and the rest of the code in volatile
sig_atomic_t
objects. Any other use of volatile
keyword in C and C++ is inherently non-portable or incorrect. In particular, writing code with the volatile
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.
Multi-Threading
[edit]It is a common misconception that the volatile
keyword is useful in portable multi-threading code in C and C++. The volatile
keyword in C and C++ has never functioned as a useful, portable tool for any multi-threading scenario.[2][3][4][5] Unlike the Java and C# programming languages, operations on volatile
variables in C and C++ are not atomic, and operations on volatile
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 volatile
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 std::atomic<T>
templates.[6]
Example of memory-mapped I/O in C
[edit]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
:
static int foo;
void bar(void) {
foo = 0;
while (foo != 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:
void bar_optimized(void) {
foo = 0;
while (true)
;
}
However, the programmer may make foo
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 foo
while this code is running. (This example does not include the details on how to make foo
refer to a hardware register of a device connected to the CPU.) Without the volatile
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 volatile
keyword can be used:
static volatile int foo;
void bar (void) {
foo = 0;
while (foo != 255)
;
}
The volatile
keyword prevents the compiler from moving the read out of the loop, and thus the code will notice the expected change to the variable foo
.
Optimization comparison in C
[edit]The following C programs, and accompanying assembler language excerpts, 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.
Assembly comparison | |
---|---|
Without volatile keyword |
With volatile keyword
|
# include <stdio.h>
int main() {
/* These variables will never be created on stack*/
int a = 10, b = 100, c = 0, d = 0;
/* "printf" will be called with arguments "%d" and
110 (the compiler computes the sum of a+b),
hence no overhead of performing addition at
run-time */
printf("%d", a + b);
/* This code will be removed via optimization, but
the impact of 'c' and 'd' becoming 100 can be
seen while calling "printf" */
a = b;
c = b;
d = b;
/* Compiler will generate code where printf is
called with arguments "%d" and 200 */
printf("%d", c + d);
return 0;
}
|
# include <stdio.h>
int main() {
volatile int a = 10, b = 100, c = 0, d = 0;
printf("%d", a + b);
a = b;
c = b;
d = b;
printf("%d", c + d);
return 0;
}
|
gcc -S -O3 -masm=intel noVolatileVar.c -o without.s | gcc -S -O3 -masm=intel VolatileVar.c -o with.s |
.file "noVolatileVar.c"
.intel_syntax noprefix
.section .rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "%d"
.section .text.startup,"ax",@progbits
.p2align 4,,15
.globl main
.type main, @function
main:
.LFB11:
.cfi_startproc
sub rsp, 8
.cfi_def_cfa_offset 16
mov esi, 110
mov edi, OFFSET FLAT:.LC0
xor eax, eax
call printf
mov esi, 200
mov edi, OFFSET FLAT:.LC0
xor eax, eax
call printf
xor eax, eax
add rsp, 8
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE11:
.size main, .-main
.ident "GCC: (GNU) 4.8.2"
.section .note.GNU-stack,"",@progbits
|
.file "VolatileVar.c"
.intel_syntax noprefix
.section .rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "%d"
.section .text.startup,"ax",@progbits
.p2align 4,,15
.globl main
.type main, @function
main:
.LFB11:
.cfi_startproc
sub rsp, 24
.cfi_def_cfa_offset 32
mov edi, OFFSET FLAT:.LC0
mov DWORD PTR [rsp], 10
mov DWORD PTR [rsp+4], 100
mov DWORD PTR [rsp+8], 0
mov DWORD PTR [rsp+12], 0
mov esi, DWORD PTR [rsp]
mov eax, DWORD PTR [rsp+4]
add esi, eax
xor eax, eax
call printf
mov eax, DWORD PTR [rsp+4]
mov edi, OFFSET FLAT:.LC0
mov DWORD PTR [rsp], eax
mov eax, DWORD PTR [rsp+4]
mov DWORD PTR [rsp+8], eax
mov eax, DWORD PTR [rsp+4]
mov DWORD PTR [rsp+12], eax
mov esi, DWORD PTR [rsp+8]
mov eax, DWORD PTR [rsp+12]
add esi, eax
xor eax, eax
call printf
xor eax, eax
add rsp, 24
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE11:
.size main, .-main
.ident "GCC: (GNU) 4.8.2"
.section .note.GNU-stack,"",@progbits
|
Standards Defects
[edit]While intended by both C and C++, the current C standard fails to express that the volatile
semantics refer to the lvalue, not the referenced object. The respective defect report DR 476 (to C11) is still under review with C17.[7]
Compiler Defects
[edit]Unlike other language features of C and C++, the volatile
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 volatile
keyword.[8][9] Programmers should take great care whenever using the volatile
keyword in C and C++.
In Java
[edit]In all modern versions of the Java programming language, the volatile
keyword gives the following guarantees:
volatile
reads and writes are atomic. In particular, reads and writes tolong
anddouble
fields will not tear. (The atomic guarantee applies only to thevolatile
primitive value or thevolatile
reference value, and not to any Object value.)- There is a single global ordering of all
volatile
reads and writes. In other words, avolatile
read will read the current value (and not a past or future value), and allvolatile
reads will agree on a single global order ofvolatile
writes. volatile
reads and writes have "acquire" and "release" memory barrier semantics (known in the Java standard as happens-before).[10][11] In other words,volatile
provides guarantees about the relative order ofvolatile
and non-volatile
reads and writes. In other words,volatile
basically provides the same memory visibility guarantees as a Java synchronized block (but without the mutual exclusion guarantees of a synchronized block).
Together, these guarantees make volatile
into a useful multi-threading construct in Java. In particular, the typical double-checked locking algorithm with volatile
works correctly in Java.[12]
Very Old Versions Of Java
[edit]Before Java version 5, the Java standard did not guarantee the relative ordering of volatile
and non-volatile
reads and writes. In other words, volatile
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 volatile
did not work correctly.
In C#
[edit]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. When a field is marked volatile
, 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 volatile
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 volatile
field, the compiler generates a release-fence; this fence prevents other reads and writes to the field from being moved after the fence.[13]
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
.[14] (This excludes value structs, as well as the primitive types Double
, Int64
, UInt64
and Decimal
.)
Using the volatile
keyword does not support fields that are passed by reference or captured local variables; in these cases, Thread.VolatileRead
and Thread.VolatileWrite
must be used instead.[13]
In effect, these methods disable some optimizations usually performed by the C# compiler, the JIT compiler, or the CPU itself. The guarantees provided by Thread.VolatileRead
and Thread.VolatileWrite
are a superset of the guarantees provided by the volatile
keyword: instead of generating a "half fence" (ie an acquire-fence only prevents instruction reordering and caching that comes before it), VolatileRead
and VolatileWrite
generate a "full fence" which prevent instruction reordering and caching of that field in both directions.[13] These methods work as follows:[15]
- The
Thread.VolatileWrite
method forces the value in the field to be written to at the point of the call. In addition, any earlier program-order loads and stores must occur before the call toVolatileWrite
and any later program-order loads and stores must occur after the call. - The
Thread.VolatileRead
method forces the value in the field to be read from at the point of the call. In addition, any earlier program-order loads and stores must occur before the call toVolatileRead
and any later program-order loads and stores must occur after the call.
The Thread.VolatileRead
and Thread.VolatileWrite
methods generate a full fence by calling the Thread.MemoryBarrier
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 volatile
keyword that is solved by using a full fence generated by Thread.MemoryBarrier
is as follows: due to the asymmetric nature of half fences, a volatile
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 Thread.MemoryBarrier
.[13]
In Fortran
[edit]VOLATILE
is part of the Fortran 2003 standard,[16] although earlier version supported it as an extension. Making all variables volatile
in a function is also useful finding aliasing related bugs.
integer, volatile :: i ! When not defined volatile the following two lines of code are identical
write(*,*) i**2 ! Loads the variable i once from memory and multiplies that value times itself
write(*,*) i*i ! Loads the variable i twice from memory and multiplies those values
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.[17]
Use of VOLATILE reduces and can even prevent optimization.[18]
References
[edit]- ^ "Publication on C++ standards committee".
- ^ "Volatile Keyword In Visual C++". Microsoft MSDN. 21 September 2021.
- ^ "Linux Kernel Documentation – Why the "volatile" type class should not be used". kernel.org.
- ^ Scott Meyers; Andrei Alexandrescu (2004). "C++ and the Perils of Double-Checked Locking" (PDF). DDJ.
- ^ Jeremy Andrews (2007). "Linux: Volatile Superstition". kerneltrap.org. Archived from the original on 2010-06-20. Retrieved Jan 9, 2011.
- ^ "volatile (C++)". Microsoft MSDN. 21 September 2021.
- ^ Clarification Request Summary for C11. Version 1.13, October 2017.
- ^ Eide, Eric; Regehr, John (October 2008). "Volatiles Are Miscompiled, and What to Do about It" (PDF). Proceedings of the Eighth ACM and IEEE International Conference on Embedded Software (EMSOFT), Atlanta, Georgia, USA – via cs.utah.edu.
- ^ "Volatile Bugs, Three Years Later – Embedded in Academia". blog.regehr.org. Retrieved 2024-08-28.
- ^ Section 17.4.4: Synchronization Order "The Java® Language Specification, Java SE 7 Edition". Oracle Corporation. 2013. Retrieved 2013-05-12.
- ^ "Java Concurrency: Understanding the 'Volatile' Keyword". dzone.com. 2021-03-08. Archived from the original on 2021-05-09. Retrieved 2021-05-09.
- ^ Neil Coffey. "Double-checked Locking (DCL) and how to fix it". Javamex. Retrieved 2009-09-19.
- ^ a b c d Albahari, Joseph. "Part 4: Advanced Threading". Threading in C#. O'Reilly Media. Archived from the original on 12 December 2019. Retrieved 9 December 2019.
{{cite web}}
: CS1 maint: bot: original URL status unknown (link) - ^ Richter, Jeffrey (February 11, 2010). "Chapter 7: Constants and Fields". CLR Via C#. Microsoft Press. pp. 183. ISBN 978-0-7356-2704-8.
- ^ Richter, Jeffrey (February 11, 2010). "Chapter 28: Primitive Thread Synchronization Constructs". CLR Via C#. Microsoft Press. pp. 797–803. ISBN 978-0-7356-2704-8.
- ^ "VOLATILE Attribute and Statement". Cray. Archived from the original on 2018-01-23. Retrieved 2016-04-22.
- ^ "Volatile and shared array in Fortran". Intel.com.
- ^ "VOLATILE". Oracle.com.