126 lines · plain
1 2.. _volatile_considered_harmful:3 4Why the "volatile" type class should not be used5------------------------------------------------6 7C programmers have often taken volatile to mean that the variable could be8changed outside of the current thread of execution; as a result, they are9sometimes tempted to use it in kernel code when shared data structures are10being used. In other words, they have been known to treat volatile types11as a sort of easy atomic variable, which they are not. The use of volatile in12kernel code is almost never correct; this document describes why.13 14The key point to understand with regard to volatile is that its purpose is15to suppress optimization, which is almost never what one really wants to16do. In the kernel, one must protect shared data structures against17unwanted concurrent access, which is very much a different task. The18process of protecting against unwanted concurrency will also avoid almost19all optimization-related problems in a more efficient way.20 21Like volatile, the kernel primitives which make concurrent access to data22safe (spinlocks, mutexes, memory barriers, etc.) are designed to prevent23unwanted optimization. If they are being used properly, there will be no24need to use volatile as well. If volatile is still necessary, there is25almost certainly a bug in the code somewhere. In properly-written kernel26code, volatile can only serve to slow things down.27 28Consider a typical block of kernel code::29 30 spin_lock(&the_lock);31 do_something_on(&shared_data);32 do_something_else_with(&shared_data);33 spin_unlock(&the_lock);34 35If all the code follows the locking rules, the value of shared_data cannot36change unexpectedly while the_lock is held. Any other code which might37want to play with that data will be waiting on the lock. The spinlock38primitives act as memory barriers - they are explicitly written to do so -39meaning that data accesses will not be optimized across them. So the40compiler might think it knows what will be in shared_data, but the41spin_lock() call, since it acts as a memory barrier, will force it to42forget anything it knows. There will be no optimization problems with43accesses to that data.44 45If shared_data were declared volatile, the locking would still be46necessary. But the compiler would also be prevented from optimizing access47to shared_data _within_ the critical section, when we know that nobody else48can be working with it. While the lock is held, shared_data is not49volatile. When dealing with shared data, proper locking makes volatile50unnecessary - and potentially harmful.51 52The volatile storage class was originally meant for memory-mapped I/O53registers. Within the kernel, register accesses, too, should be protected54by locks, but one also does not want the compiler "optimizing" register55accesses within a critical section. But, within the kernel, I/O memory56accesses are always done through accessor functions; accessing I/O memory57directly through pointers is frowned upon and does not work on all58architectures. Those accessors are written to prevent unwanted59optimization, so, once again, volatile is unnecessary.60 61Another situation where one might be tempted to use volatile is62when the processor is busy-waiting on the value of a variable. The right63way to perform a busy wait is::64 65 while (my_variable != what_i_want)66 cpu_relax();67 68The cpu_relax() call can lower CPU power consumption or yield to a69hyperthreaded twin processor; it also happens to serve as a compiler70barrier, so, once again, volatile is unnecessary. Of course, busy-71waiting is generally an anti-social act to begin with.72 73There are still a few rare situations where volatile makes sense in the74kernel:75 76 - The above-mentioned accessor functions might use volatile on77 architectures where direct I/O memory access does work. Essentially,78 each accessor call becomes a little critical section on its own and79 ensures that the access happens as expected by the programmer.80 81 - Inline assembly code which changes memory, but which has no other82 visible side effects, risks being deleted by GCC. Adding the volatile83 keyword to asm statements will prevent this removal.84 85 - The jiffies variable is special in that it can have a different value86 every time it is referenced, but it can be read without any special87 locking. So jiffies can be volatile, but the addition of other88 variables of this type is strongly frowned upon. Jiffies is considered89 to be a "stupid legacy" issue (Linus's words) in this regard; fixing it90 would be more trouble than it is worth.91 92 - Pointers to data structures in coherent memory which might be modified93 by I/O devices can, sometimes, legitimately be volatile. A ring buffer94 used by a network adapter, where that adapter changes pointers to95 indicate which descriptors have been processed, is an example of this96 type of situation.97 98For most code, none of the above justifications for volatile apply. As a99result, the use of volatile is likely to be seen as a bug and will bring100additional scrutiny to the code. Developers who are tempted to use101volatile should take a step back and think about what they are truly trying102to accomplish.103 104Patches to remove volatile variables are generally welcome - as long as105they come with a justification which shows that the concurrency issues have106been properly thought through.107 108 109References110==========111 112[1] https://lwn.net/Articles/233481/113 114[2] https://lwn.net/Articles/233482/115 116Credits117=======118 119Original impetus and research by Randy Dunlap120 121Written by Jonathan Corbet122 123Improvements via comments from Satyam Sharma, Johannes Stezenbach, Jesper124Juhl, Heikki Orsila, H. Peter Anvin, Philipp Hahn, and Stefan125Richter.126