volatile (computer programming)

In C, and consequently C++, the volatile keyword was intended to:[1]

• allow access to memory-mapped I/O devices
• allow uses of variables between setjmp and longjmp
• allow uses of sig_atomic_t variables in signal handlers.

Since variables marked as volatile are prone to change outside the standard flow of code, the compiler has to perform every read and write to the variable as indicated by the code. Any access to volatile variables cannot be optimised away, e.g. by use of registers for storage of intermediate values.

While intended by both C and C++, the C standards fail 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.[2]

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),[1] 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.[3][4][5]

static int foo;

void bar(void) {
    foo = 0;

    while (foo != 255)
         ;
}

void bar_optimized(void) {
    foo = 0;

    while (true)
         ;
}

static volatile int foo;

void bar (void) {
    foo = 0;

    while (foo != 255)
        ;
}

# 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;
}

 .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

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:

• In all versions of Java, there is a global ordering on reads and writes of all volatile variables (this global ordering on volatiles is a partial order over the larger synchronization order (which is a total order over all synchronization actions)). This implies that every thread accessing a volatile field will read its current value before continuing, instead of (potentially) using a cached value. (However, there is no guarantee about the relative ordering of volatile reads and writes with regular reads and writes, meaning that it's generally not a useful threading construct.)
• In Java 5 or later, volatile reads and writes establish a happens-before relationship, much like acquiring and releasing a mutex.[8][9]

Using volatile may be faster than a lock, but it will not work in some situations before Java 5.[10] The range of situations in which volatile is effective was expanded in Java 5; in particular, double-checked locking now works correctly.[11]

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, including those in other threads, 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.[12]

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.[13] (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.[12]

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.[12] These methods work as follows:[14]

• 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 to VolatileWrite 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 to VolatileRead 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.[12]

VOLATILE is part of the Fortran 2003 standard,[15] 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.[16]

Use of VOLATILE reduces and can even prevent optimization.[17]

• Ada Reference Manual C.6: Shared Variable Control
• Linux kernel: volatile-considered-harmful