Why the "volatile" type class should not be used

------------------------------------------------C programmers have often taken volatile to mean that the variable could bechanged outside of the current thread of execution; as a result, they aresometimes tempted to use it in kernel code when shared data structures arebeing used.  In other words, they have been known to treat volatile typesas a sort of easy atomic variable, which they are not.  The use of volatile inkernel code is almost never correct; this document describes why.The key point to understand with regard to volatile is that its purpose isto suppress optimization, which is almost never what one really wants todo.  In the kernel, one must protect shared data structures againstunwanted concurrent access, which is very much a different task.  Theprocess of protecting against unwanted concurrency will also avoid almostall optimization-related problems in a more efficient way.Like volatile, the kernel primitives which make concurrent access to datasafe (spinlocks, mutexes, memory barriers, etc.) are designed to preventunwanted optimization.  If they are being used properly, there will be noneed to use volatile as well.  If volatile is still necessary, there isalmost certainly a bug in the code somewhere.  In properly-written kernelcode, volatile can only serve to slow things down.Consider a typical block of kernel code:    spin_lock(&the_lock);    do_something_on(&shared_data);    do_something_else_with(&shared_data);    spin_unlock(&the_lock);If all the code follows the locking rules, the value of shared_data cannotchange unexpectedly while the_lock is held.  Any other code which mightwant to play with that data will be waiting on the lock.  The spinlockprimitives act as memory barriers - they are explicitly written to do so -meaning that data accesses will not be optimized across them.  So thecompiler might think it knows what will be in shared_data, but thespin_lock() call, since it acts as a memory barrier, will force it toforget anything it knows.  There will be no optimization problems withaccesses to that data.If shared_data were declared volatile, the locking would still benecessary.  But the compiler would also be prevented from optimizing accessto shared_data _within_ the critical section, when we know that nobody elsecan be working with it.  While the lock is held, shared_data is notvolatile.  When dealing with shared data, proper locking makes volatileunnecessary - and potentially harmful.The volatile storage class was originally meant for memory-mapped I/Oregisters.  Within the kernel, register accesses, too, should be protectedby locks, but one also does not want the compiler "optimizing" registeraccesses within a critical section.  But, within the kernel, I/O memoryaccesses are always done through accessor functions; accessing I/O memorydirectly through pointers is frowned upon and does not work on allarchitectures.  Those accessors are written to prevent unwantedoptimization, so, once again, volatile is unnecessary.Another situation where one might be tempted to use volatile iswhen the processor is busy-waiting on the value of a variable.  The rightway to perform a busy wait is:    while (my_variable != what_i_want)        cpu_relax();The cpu_relax() call can lower CPU power consumption or yield to ahyperthreaded twin processor; it also happens to serve as a compilerbarrier, so, once again, volatile is unnecessary.  Of course, busy-waiting is generally an anti-social act to begin with.There are still a few rare situations where volatile makes sense in thekernel:  - The above-mentioned accessor functions might use volatile on    architectures where direct I/O memory access does work.  Essentially,    each accessor call becomes a little critical section on its own and    ensures that the access happens as expected by the programmer.  - Inline assembly code which changes memory, but which has no other    visible side effects, risks being deleted by GCC.  Adding the volatile    keyword to asm statements will prevent this removal.  - The jiffies variable is special in that it can have a different value    every time it is referenced, but it can be read without any special    locking.  So jiffies can be volatile, but the addition of other    variables of this type is strongly frowned upon.  Jiffies is considered    to be a "stupid legacy" issue (Linus's words) in this regard; fixing it    would be more trouble than it is worth.  - Pointers to data structures in coherent memory which might be modified    by I/O devices can, sometimes, legitimately be volatile.  A ring buffer    used by a network adapter, where that adapter changes pointers to    indicate which descriptors have been processed, is an example of this    type of situation.For most code, none of the above justifications for volatile apply.  As aresult, the use of volatile is likely to be seen as a bug and will bringadditional scrutiny to the code.  Developers who are tempted to usevolatile should take a step back and think about what they are truly tryingto accomplish.Patches to remove volatile variables are generally welcome - as long asthey come with a justification which shows that the concurrency issues havebeen properly thought through.NOTES-----[1] http://lwn.net/Articles/233481/[2] http://lwn.net/Articles/233482/CREDITS-------Original impetus and research by Randy DunlapWritten by Jonathan CorbetImprovements via comments from Satyam Sharma, Johannes Stezenbach, JesperJuhl, Heikki Orsila, H. Peter Anvin, Philipp Hahn, and StefanRichter.