Usage of volatile specifier in C/C++/Java

Question

While going through many resources on multithreaded programming, reference to volatile specifier usually comes up. It is clear that usage of this keyword is not a reliable way to achieve synchronization between multiple threads atleast in C/C++ and Java (versions 1.4 and earlier). Here is what wikipedia lists (without explaining how) as typical usages this specifier:-

1. allow access to memory mapped devices
2. allow uses of variables between setjmp and longjmp
3. allow uses of variables in signal handlers
4. busy waiting

I can begin to see the role of this specifier in the above listed usages but since I don't yet have a complete understanding of each of these areas, I can't figure out how exactly this specifier behaves in each of these usages.

Could someone explain.
Thanks.

Answer 1

There is a good explanation here: http://en.wikipedia.org/wiki/Volatile_variable but slightly simplified it tells the compiler that it should not assume that the variable isn't accessed by someone else and that it is fatal to optimize it into a registrer and update only the register and not the actual storage.

Answer 2

Volatile variable should be used when that variable can be accessed by many threads and you want at every instruction your code should get the updated value of that variable.

Compilers generally optimize the code and store variables in register rather than getting from memory each and every time if they see no one has updated it.

But by using volatile you can force the compiler to get the updated value every time.

Answer 3

Your question is technically known as 'a can of worms'! For c/c++ ( I can't comment on java )
You can very roughly summarise volatile as being a directive to the compiler to say 'please don't optimise this out' but there is a lot of argument amongst professionals, as to whether it's
a) At all useful for kernel level code <-Edit clarified based on feedback
b) Even implemented correctly by most compilers.

Also, do not ever use it for multi-threaded programming and here's a very good explanation as to why

=Edit= Interestingly, for what it's worth. Dennis Ritchie was against it's inclusion ( as well as const ) details here

Answer 4

I found this DDJ article by Herb Sutter very interesting, especially how volatile is treated in C++, Java and C# .NET.

Dr.Dobbs volatile vs. volatile

Best Regards, Ovanes

Answer 5

It's been a while since I've done C++ and I really don't recall the definition of volatine in that language. But the Java language specification specifically says that the purpose of volatile is to facilitate multi-threaded access to a variable. Quote: "A field may be declared volatile, in which case the Java memory model (§17) ensures that all threads see a consistent value for the variable." They go on to say that references to volatile values are guaranteed to be satisfied in the order in which they are specified in the code, i.e. if you declare i and j volatile and then write "++i; ++j", then i will, in fact, always be incremented before j.

The only time I recall using a volatile in Java was when I had one thread possibly setting a cancel flag and another thread looping through some big operation and each time through the loop checking the cancel flag. This did indeed work as I expected.

I'd agree that "volatile" has very limited usefulness. Most multi-threading requires "synchronized" at some point. But "limited" and "none" are not the same thing. The cosine function has very limited usefulness in most business applications, too. But when you need it, wow, that saves a lot of trouble.

Answer 6

Since you're interested in those usage cases, I'll explain the first one. Note that this applies from a c/c++ perspective, not sure how it plays into java, although I suspect in general volatile in c/c++ and java are used for completely different cases.

Memory mapped devices are peripherals which the processor communicates with in the same manner as the memory rather than through a special bus.

Suppose you have a little light with a timer that is memory mapped. You turn on the light by writing 1 to its memory address & its internal timer counts down for 5 seconds & turns the light off and resets the memory location to 0. Now you are developing a c program that needs to turn that light on after certain events, and sometimes turn it off before the counter expires. If you use a regular variable (tends to be a pointer or a reference for this type of application) to write to its memory location, there are a number of things that might go wrong due to compiler optimizations.

If you aren't working with that many variables and you are turning the light on and shortly there after turning it off without any other variables using that value - sometimes the compiler will altogether get rid of the first assignment, or in other cases it will simply maintain the value in the processor registers & never write to memory. In both these cases, the light woudl never turn on since it's memory was never changed.

Now think of another situation where you check the state of the light & it is on. Here, the value is extracted from the device's memory & kept in a processor register. Now, after a few seconds, the light turns off by itself. Shortly thereafter you try to turn the light on again, however since you read that memory address & haven't changed it since, the compiler assumes the value is still one & therefore never changes it, although it is actually 0 now.

By using the volatile key word, you prevent the compiler from making any of those assumptions when converting your code into machine code & ensures all those specific operations are performed strictly as written by the programmer. This is essential for memory mapped devices mostly because the memory location is not changed strictly by the processor. For these same reasons, multiprocessor systems with shared memory often require similar practices when operating on a common memory space.

Answer 7

The volatile keyword appeared long ago in C, and what it does basically is to "turn off" some compiler optimizations that assume if a variable wasn't changed explicitly, it wasn't changed at all. Its main utility those days was to declare variables that would be changed by interrupt handlers. I, for instance, used it once (late 80's) for a global variable containing the mouse cursor position. The position was changed by an interrupt, and without volatile the main program sometimes wouldn't detect its changes because the compiler optimized away the variable access, thinking it wasn't necessary.

Today these uses are, in general, obsolete (unless you write low-level OS code) but still there are some rare situations in which volatile is useful (very rare indeed - I, for instance, probably didn't use it for the last 7 years).

But for multithread programming it's completely unrecommended. The problem is that it won't protect for concurrent access between threads, it will only remove optimizations that would prevent its 'refresh' in the same thread. It wasn't intended for use in multithreaded environments. If you're in Java, use synchronized. If you're in C++, use some sync library, like pthreads or Boost.Threads (or, better yet, use the new C++ 0X thread libraries, if you can).

Answer 8

Volatile variables are useful in Java (at least since Java 5.0 where their behaviour changed), as Brian Goetz says in his book "Java Concurrency in Practice" (JCIP) - the essential book on the subject (pg 37):

to ensure that updates to a variable are propagated predictably to other threads

Explicit synchronization can also achieve this, but often we do not always want to lock a value. Double Checked locking is the classic example of this (copied from Wikipedia):

// Works with acquire/release semantics for volatile
// Broken under Java 1.4 and earlier semantics for volatile
class Foo {
    private volatile Helper helper = null;
    public Helper getHelper() {
        if (helper == null) {
            synchronized(this) {
                if (null == helper)
                    helper = new Helper();
            }
        }
        return helper;
    }

    // other functions and members...
}

This would not work if the helper was not volatile.

Volatile variables can also be used to implement non-locking concurrent datastructures, such as java.util.concurrent.ConcurrentHashMap (which supports concurrent updates and access without locking - see the JDK source code for its use of volatiles).

JCIP has a nice discussion of double-checked locking, volatile variables, and Java concurrency in general. "Effective Java", 2nd Edition, by Joshua Bloch is also worth reading.

Also note that atomic variables are supported in Java in the java.util.concurrent.atomic package. These allow changes to values to be made visible across threads/processors in a similar way to volatile variables, but also allow "Compare And Set" operations to be performed, which means that some additional types of concurrent operations can safely be performed without locking.