Volatile variable

In computer programming, particularly in the C, C++, C#, and Java programming languages, a variable or object declared with the volatile keyword usually has special properties related to optimization and/or threading. Generally speaking, the volatile keyword is intended to prevent the compiler from applying certain optimizations which it might have otherwise applied because ordinarily it is assumed variables cannot change value "on their own."

The actual definition and applicability of the volatile keyword is often misconstrued in the context of the C language. Although C++, C#, and Java share the same keyword volatile from C, there is a great deal of difference between the semantics and usefulness of volatile in each of these programming languages.

In C and C++

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

• allow access to memory mapped devices
• allow uses of variables between setjmp and longjmp
• allow uses of 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 according to the relevant standards (C, C++, POSIX, WIN32),^[2] and this is the matter of fact for 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]

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:

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, 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:

static volatile int foo;
 
void bar (void) {
    foo = 0;
 
    while (foo != 255)
        ;
}

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).^[6]

Optimization comparison in C

The following C programs, and accompanying disassemblies, demonstrate how the volatile keyword affects the compiler's output. The compiler in this case was GCC. If we observe the assembly code, we can see that the code generated with volatile objects is bigger than the other, because the volatile keyword stops the compiler from performing optimization on code involving volatile objects.

#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

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. ^[7]

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.^[8]

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 volatile guarantees that:

1. (In all versions of Java) There is a global ordering on the reads and writes to a volatile variable. 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.)
2. (In Java 5 or later) Volatile reads and writes establish a happens-before relationship, much like acquiring and releasing a mutex.^[9]

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

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.^[11]

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 . Here’s how the methods work:^[12]

• The 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.
• The 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.

• The Thread.MemoryBarrier method doesn’t 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.^{[citation needed]}

References

External links

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