Volatile variable

From Wikipedia, the free encyclopedia
Jump to: navigation, search

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 any optimizations on the code that assume values of variables cannot change "on their own."

The actual definition and applicability of the volatile keyword is often misconstrued in the context of C; and because C++, C#, and Java mystically "inherit" volatile from C, there is a great deal of difference between the semantics and usefulness of volatile in each of these programming languages.

Contents

 [hide

[edit] 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), and this is the matter of fact for the vast majority of current implementations. The volatile keyword is basically worthless as a portable threading construct.[2][3][4][5][6]

[edit] 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. However, it is usually overkill to mark the variable volatile as that disables the compiler from optimizing any accesses of that variable instead of the ones that could be problematic. Instead, it is a better idea to cast to volatile where it is needed:

In C:

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

In C++:

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

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 & more importantly they guarantee correct behaviour in multi-threaded scenarios; the C specifications and C++ specifications before C++11 do not specify a multi-threaded memory model, so volatile may not behave deterministically across OSes/compilers/CPUs).[7]

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

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

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

[edit] In Ada

In Ada, pragma Volatile is a directive rather than a keyword. "For a volatile object all reads and updates of the object as a whole are performed directly to memory."[10]

[edit] References

  1. ^ Publication on C++ standards committee website; http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2016.html
  2. ^ Publication on C++ standards committee website; http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2016.html
  3. ^ Volatile Keyword In Visual C++; http://msdn2.microsoft.com/en-us/library/12a04hfd.aspx
  4. ^ Linux Kernel Documentation - Why the "volatile" type class should not be used; http://kernel.org/doc/Documentation/volatile-considered-harmful.txt
  5. ^ Volatile: Almost Useless for Multi-Threaded Programming (Intel Software Network); http://softwareblogs.intel.com/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/
  6. ^ C++ and the Perils of Double-Checked Locking; http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
  7. ^ "Linux: Volatile Superstition". kerneltrap.org. http://kerneltrap.org/Linux/Volatile_Superstition. Retrieved Jan 9, 2011. 
  8. ^ Section 17.4.4: Synchronization Order "The Java Language Specification, 3rd Edition". Sun Microsystems. 2005. http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.4.4. Retrieved 2010-11-22. 
  9. ^ Neil Coffey. "Double-checked Locking (DCL) and how to fix it". Javamex. http://www.javamex.com/tutorials/double_checked_locking_fixing.shtml. Retrieved 2009-09-19. 
  10. ^ "C.6 Shared Variable Control" "Ada Reference Manual". ISO. 2005. http://www.adaic.com/standards/05rm/html/RM-C-6.html. Retrieved 2010-05-04. 

[edit] External links

View page ratings
Rate this page
Trustworthy
Objective
Complete
Well-written
We will send you a confirmation e-mail. We will not share your e-mail address with outside parties as per our feedback privacy statement.
Saved successfully
Your ratings have not been submitted yet
Your ratings have expired
Please reevaluate this page and submit new ratings.
An error has occured. Please try again later.
Thanks! Your ratings have been saved.
Please take a moment to complete a short survey.
Thanks! Your ratings have been saved.
Do you want to create an account?
An account will help you track your edits, get involved in discussions, and be a part of the community.
or
Thanks! Your ratings have been saved.
Did you know that you can edit this page?
Personal tools
Namespaces
Variants
Actions
Navigation
Interaction
Languages