学步园

Introduction

When the C programming language first came out on the market the
compilers did very little optimization when they were translating the
code into an executable binary. This led not only to larger executables
but also quite often as not the inclusion of CPU instructions in the
programs which performed no meaningful task. The extraneous code was as
often as not the fault of the programmer as it was that of the
compiler.

A simple example of the programmer being at fault can be seen with the following code fragment.

int * x;

...

void func( )
{
  * x = 1;

  /* OTHER INSTRUCTIONS */

  * x = 2;
}

...

func( );

If the comment section marked "OTHER INSTRUCTIONS" in example 1 never
used the value pointed to by "x", then the first assignment of * x = 1
is probably not required and could be removed. Yet a compiler which did
not perform optimization would not recognize this fact and the * x = 1
command would still end up being included in the executable.

In an attempt to help avoid situations like the one outlined above,
many developers expended and continue to expend a lot of effort on
supplying intelligent optimization in the compilers. Today those
optimizations handle a wide variety of situations. Not only will the
typical compiler optimize out the extraneous * x = 1 in the example but
will also automatically handle much more complex situations which may
not be immediately apparent to even a senior programmer. The expected
end result of these optimizations is more efficient executables and a
smaller required memory footprint.

Normally having the compiler perform optimization is a good thing,
but as with all things there is also a dark side. Consider what happens
if the memory pointed to by variable "x" was a control line for an
external device. Also imagine that sending a value of 1 to that memory
told our ficticious device to begin some operation and that sending a
value of 2 told it to stop. If the compiler did optimization and
removed the * x = 1 instruction then the external device would never
receive a start signal. This would definitely not be the intent of the
programmer.

The first solution to this problem of a compiler performing
optimization where it should not be done is to completely turn off
optimization. This would certainly work but then you are sacrificing
the efficiency of the entire program for one tiny section. Instead of
going to such extremes, there is an alternative supplied by the C
programming language. That alternative is to use the "volatile" type
qualifier in the definition of the variable in question.

When the keyword volatile is used in the type definition it is giving
an indication to the compiler on how it should handle the variable.
Primarily it is telling the compiler that the value of the variable may
change at any time as a result of actions external to the program or
current line of execution. Once the compiler knows this it will also
know that no operations involving the variable should be optimized out
of the code no matter how extraneous they may appear to the optimization
algorithm. The compiler also now knows that any use of the variable in
the program must use the value currently in memory and not a previously
cached value.

Declaring a volatile variable

Now that the effect of the the "volatile" keyword has been briefly
covered, we need to know exactly how to use it. It is quite simple if
you are already familiar with the "const" keyword since "volatile" may
be used anywhere that "const" is allowed. This means that all you have
to do to indicate that a variable is volatile is to include the keyword
before or after the type indicator in a variable definition.

An example of declaring a simple volatile int type variable would be:

volatile int x;
int volatile x;

If you had a pointer variable where the memory pointed to was volatile you could indicate that using:

volatile int * x;
int volatile * x;

On the other hand, if you have a pointer variable where the address
itself was volatile but the memory pointed to was not then we have:

int * volatile x;

Last but certainly not least if there was a pointer variable where
both the pointer address and the memory pointed to were both volatile
then you could do:

volatile int * volatile x;
int volatile * volatile x;

Common mistakes and pitfalls

We have already seen one example where declaring a variable to be
volatile will ensure the proper compilation and execution of a program.
You may in fact be tempted to declare all variables which are not const
as volatile. If you are thinking of doing that then realise it is much
simpler just to turn off all optimization at compile time instead of
typing the word volatile repeatedly. Doing either of these things
though would almost always be undesirable. Instead, determine which
variables are truly volatile and declare those and only those as such.

There are still other pitfalls to using volatile that haven't been mentioned yet. Looking at some more example code:

volatile int index;

thread_func_A( )
{
  ++ index;
}

thread_func_B( )
{
  ++ index;
}

This is something that can be found in many examples of how to make
use of volatile keyword. There is one main belief held by those who try
to use volatile in this fashion. That belief is that the increment
operation is a "simple" single step instruction and that by using
volatile it will make increment an atomic operation. This may or may
not hold true on a single CPU system and it certainly is incorrect if
the code is executed on a multiple CPU computer.

The reason the code always fails to operate correctly on a system
with more than one CPU is due to the fact that even a simple increment
operation in actuality consists of three steps. Those steps consist of
the CPU reading the value at the memory location, then incrementing it
and finally storing the new value. This means that you can and
eventually will end up with a circumstance like:

1. index = 0
2. thread A reads index and finds 0
3. thread B reads index and finds 0
4. thread A increments its value of index by 1
5. thread B increments its value of index by 1
6. thread A stores 1 back to index
7. thread B stores 1 back to index

Its immediately apparent that we were expecting index to be
incremented once by each thread and end up with a value of two. This is
not what happened because declaring a variable as volatile does not
guarantee that the operation will be atomic. It only promises that the
increment operation will get and set the value of index directly instead
of using a cached version. If atomic operations are really needed then
a true mutual exclusion lock like that provided by a POSIX library
should be employed.

Following is another example of where things can go wrong when using
volatile improperly. In many ways it is similar to the problem with
threads except but it also shows how platform specific conditions can
alter program execution.

volatile long int * dev = PORT;

void func( )
{
  for( ; ; )
  {
    /* loop until device says data ready */

    while( 0x00000001 != * dev )
    {
      /* short delay */
    }

    action_a( );
  }
}

Since we have an example lets set some other conditions:

1. the size of a long int is 32 bits
2. memory reads / writes are done 32 bits at a time
3. the variable dev maps memory to some external device
4. the external device may set dev to any value from 0x00000001 to 0xFFFFFFFF
5. the program only wants to break from the loop when dev is exactly 0x00000001

Using the code from example three, if we can be assured that the
conditions are true then the program should work exactly as desired on
any system. The problem is that proper operation is dependent on some
conditions that may be beyond our control. To see how lets modify
condition two so that we get:

1. the size of a long int is 32 bits
2. memory reads / writes are done 16 bits at a time
3. the variable dev maps memory to some external device
4. the external device may set dev to any value from 0x00000001 to 0xFFFFFFFF
5. the program only wants to break from the loop when dev is exactly 0x00000001

It easy to see that these are NOT contrived conditions. Often code
is moved between platforms which, dependent on the processor(s) and
other hardware considerations, may read and write memory in chunk sizes
which differ from the size of the variable type you have declared as
volatile. So given the new conditions we could now have the program
execution sequence:

1. value of dev is 0xFFFF00001
2. code checks dev with two 16 bit reads, finds 0x00000001 != dev, enters short delay
3. external device generates a value of 0x0000FFFF
4. external device writes high order bytes setting dev to 0x00000001
5. code exits delay with two 16 bit reads, finds 0x00000001 == dev, exits loop!!!
6. external device writes lower order bytes setting dev to 0x0000FFFF

All that can be said it "oops". In the first case we made the
assumption that any memory read or write would occur in a single step
and were correct. The minute we switched to another platform with
slightly different conditions though, the single step condition no
longer held true and we get unexpected behavior from our program.

Now it should be pointed out that if the condition was 0x00000000 != *
dev and we cared only about that condition and not the exact value of
dev, then the code would operate correct only any platform. You could
still potentially have a bit of a collision condition. An example of
such a collision would be the case where dev was set to 0xFFFF000 then
0x0000FFFF. The difference between this collision and the one in the
previous example is that here the code would simply be delayed slightly
in the conditional loop instead of erroneously breaking out of it.

Conclusion

The point of all this is that volatile can be extremely useful in
many circumstance but you must use it judiciously. It is not meant to
be a cure-all and certainly should not be used under the assumption that
it will somehow standardize the way the underlying system(s) operates.
The only effect of using volatile is during code compilation. If you
remember those simple facts you will be fine.