This is straight out of MSDN:

volatile declarator

The volatile keyword is a type qualifier used to declare that an object can be modified in the program by something other than statements, such as the operating system, the hardware, or a concurrently executing thread.

The following example declares a volatile integer nVint whose value can be modified by external processes:

int volatile nVint;
Objects declared as volatile are not used in optimizations because their value can change at any time. The system always reads the current value of a volatile object at the point it is requested, even if the previous instruction asked for a value from the same object. Also, the value of the object is written immediately on assignment. 

One use of the volatile qualifier is to provide access to memory locations used by asynchronous processes such as interrupt handlers.
 

This sounds like a great replacement for mutexes. If it re-reads it every time it is accessed, and re-writes it every time it is changes, wouldn''t that eleminate the need for a mutex? I was reading some mutex tutorials on flipcode earlier when gamedev was down (or maybe it was just my connection), and they have a really neat implementation form mutexes. I thought I remembered something foggy about a volatile keyword, so I looked it up and here it is. Will it replace a mutex? --------------------

You are not a real programmer until you end all your sentences with semicolons; (c) 2000 ROAD Programming

You are unique. Just like everybody else.

"Mechanical engineers design weapons; civil engineers design targets."

Yanroy@usa.com

Visit the ROAD Programming Website for more programming help.

I think you misunderstand the purpose of mutexes.

Mutexes are used to prevent access to some shared state by one thread, while it is in an inconsistent state due to modification by another thread. Volatile forces a reload, it does not guarantee the data is valid.

It might reduce the window of opportunity for computing the wrong result, but it doesn''t eliminate it. Using a classic example of loading a value, adding to it and storing it back there is nothing preventing another process from changing it between the load and store. Volatile at best would force the load when the compiler would have otherwise used a value already in a register. So it is a more recent value, but nothing prevents another process from loading the value after you do, updating their copy and saving it before you save your modification at which point you wipe out their modification. A prime example of where that would happen is your timeslice ending just as you load the value, but before you can modify and store it.

volatile is usually used in embedded systems, where addresses
will be mapped to physical output lines. For example:
int* dout0 = 0x1000FECD; // memory-mapped hardware line
*dout = 1; // some device needs this line toggled..
*dout = 0;
*dout = 1;

Normally, the compiler would optimize-out this code, so you
declare it volatile and it will absolutely go through those
state changes.

You must use kernel objects for mutexes because the atomic
synchronization unit, a semaphore, needs these operations to
happen without the possibility of interruption:
if (!counter)
--counter;

Regardless of whether counter is volatile, another process
can change it between those two lines. So you have to have
either a critical section ability or a kernel synchronization
object in order to implement mutexes.