volatile

From Wikipedia :

In C, and consequently C++, the  keyword was intended to


 * allow access to memory mapped devices
 * allow uses of variables between  and
 * allow uses of  variables in signal handlers.

= volatile and multithreaded programming =

Wikipedia
Operations on  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  keyword is basically worthless as a portable threading construct.

Arch Robison (Intel)
There is a widespread notion that the keyword  is good for multi-threaded programming. I've seen interfaces with volatile qualifiers justified as "it might be used for multi-threaded programming". I thought was useful until the last few weeks, when it finally dawned on me (or if you prefer, got through my thick head) that volatile is almost useless for multi-threaded programming. I'll explain here why you should scrub most of it from your multi-threaded code.

Bryan O' Sullivan
Declaring your variables  will have no useful effect, and will simply cause your code to run a lot slower when you turn on optimisation in your compiler.

David Butenhof
...the use of  accomplishes nothing but to prevent the compiler from making useful and desirable optimizations, providing no help whatsoever in making code "thread safe".

FAQ: Why don't I need to declare shared variables VOLATILE?
 I'm concerned, however, about cases where both the compiler and the threads library fulfill their respective specifications. A conforming C compiler can globally allocate some shared (non ) variable to a register that gets saved and restored as the CPU gets passed from thread to thread. Each thread will have it's own private value for this shared variable, which is not what we want from a shared variable.

In some sense this is true, if the compiler knows enough about the respective scopes of the variable and the  (or  ) functions. In practice, most compilers will not try to keep register copies of global data across a call to an external function, because it's too hard to know whether the routine might somehow have access to the address of the data.

So yes, it's true that a compiler that conforms strictly (but very aggressively) to ANSI C might not work with multiple threads without. But someone had better fix it. Because any system (that is, pragmatically, a combination of kernel, libraries, and C compiler) that does not provide the POSIX memory coherency guarantees does not conform to the POSIX standard. Period. The system cannot require you to use  on shared variables for correct behavior, because POSIX requires only that the POSIX synchronization functions are necessary.

So if your program breaks because you didn't use, that's a BUG. It may not be a bug in C, or a bug in the threads library, or a bug in the kernel. But it's a SYSTEM bug, and one or more of those components will have to work to fix it.

You don't want to use, because, on any system where it makes any difference, it will be vastly more expensive than a proper non  variable. (ANSI C requires "sequence points" for  variables at each expression, whereas POSIX requires them only at synchronization operations -- a compute-intensive threaded application will see substantially more memory activity using , and, after all, it's the memory activity that really slows you down.)