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?

Answer 1

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.