1 1
2 .. _volatile_considered_harmful: 2 .. _volatile_considered_harmful:
3 3
4 Why the "volatile" type class should not be us 4 Why the "volatile" type class should not be used
5 ---------------------------------------------- 5 ------------------------------------------------
6 6
7 C programmers have often taken volatile to mea 7 C programmers have often taken volatile to mean that the variable could be
8 changed outside of the current thread of execu 8 changed outside of the current thread of execution; as a result, they are
9 sometimes tempted to use it in kernel code whe 9 sometimes tempted to use it in kernel code when shared data structures are
10 being used. In other words, they have been kn 10 being used. In other words, they have been known to treat volatile types
11 as a sort of easy atomic variable, which they 11 as a sort of easy atomic variable, which they are not. The use of volatile in
12 kernel code is almost never correct; this docu 12 kernel code is almost never correct; this document describes why.
13 13
14 The key point to understand with regard to vol 14 The key point to understand with regard to volatile is that its purpose is
15 to suppress optimization, which is almost neve 15 to suppress optimization, which is almost never what one really wants to
16 do. In the kernel, one must protect shared da 16 do. In the kernel, one must protect shared data structures against
17 unwanted concurrent access, which is very much 17 unwanted concurrent access, which is very much a different task. The
18 process of protecting against unwanted concurr 18 process of protecting against unwanted concurrency will also avoid almost
19 all optimization-related problems in a more ef 19 all optimization-related problems in a more efficient way.
20 20
21 Like volatile, the kernel primitives which mak 21 Like volatile, the kernel primitives which make concurrent access to data
22 safe (spinlocks, mutexes, memory barriers, etc 22 safe (spinlocks, mutexes, memory barriers, etc.) are designed to prevent
23 unwanted optimization. If they are being used 23 unwanted optimization. If they are being used properly, there will be no
24 need to use volatile as well. If volatile is 24 need to use volatile as well. If volatile is still necessary, there is
25 almost certainly a bug in the code somewhere. 25 almost certainly a bug in the code somewhere. In properly-written kernel
26 code, volatile can only serve to slow things d 26 code, volatile can only serve to slow things down.
27 27
28 Consider a typical block of kernel code:: 28 Consider a typical block of kernel code::
29 29
30 spin_lock(&the_lock); 30 spin_lock(&the_lock);
31 do_something_on(&shared_data); 31 do_something_on(&shared_data);
32 do_something_else_with(&shared_data); 32 do_something_else_with(&shared_data);
33 spin_unlock(&the_lock); 33 spin_unlock(&the_lock);
34 34
35 If all the code follows the locking rules, the 35 If all the code follows the locking rules, the value of shared_data cannot
36 change unexpectedly while the_lock is held. A 36 change unexpectedly while the_lock is held. Any other code which might
37 want to play with that data will be waiting on 37 want to play with that data will be waiting on the lock. The spinlock
38 primitives act as memory barriers - they are e 38 primitives act as memory barriers - they are explicitly written to do so -
39 meaning that data accesses will not be optimiz 39 meaning that data accesses will not be optimized across them. So the
40 compiler might think it knows what will be in 40 compiler might think it knows what will be in shared_data, but the
41 spin_lock() call, since it acts as a memory ba 41 spin_lock() call, since it acts as a memory barrier, will force it to
42 forget anything it knows. There will be no op 42 forget anything it knows. There will be no optimization problems with
43 accesses to that data. 43 accesses to that data.
44 44
45 If shared_data were declared volatile, the loc 45 If shared_data were declared volatile, the locking would still be
46 necessary. But the compiler would also be pre 46 necessary. But the compiler would also be prevented from optimizing access
47 to shared_data _within_ the critical section, 47 to shared_data _within_ the critical section, when we know that nobody else
48 can be working with it. While the lock is hel 48 can be working with it. While the lock is held, shared_data is not
49 volatile. When dealing with shared data, prop 49 volatile. When dealing with shared data, proper locking makes volatile
50 unnecessary - and potentially harmful. 50 unnecessary - and potentially harmful.
51 51
52 The volatile storage class was originally mean 52 The volatile storage class was originally meant for memory-mapped I/O
53 registers. Within the kernel, register access 53 registers. Within the kernel, register accesses, too, should be protected
54 by locks, but one also does not want the compi 54 by locks, but one also does not want the compiler "optimizing" register
55 accesses within a critical section. But, with 55 accesses within a critical section. But, within the kernel, I/O memory
56 accesses are always done through accessor func 56 accesses are always done through accessor functions; accessing I/O memory
57 directly through pointers is frowned upon and 57 directly through pointers is frowned upon and does not work on all
58 architectures. Those accessors are written to 58 architectures. Those accessors are written to prevent unwanted
59 optimization, so, once again, volatile is unne 59 optimization, so, once again, volatile is unnecessary.
60 60
61 Another situation where one might be tempted t 61 Another situation where one might be tempted to use volatile is
62 when the processor is busy-waiting on the valu 62 when the processor is busy-waiting on the value of a variable. The right
63 way to perform a busy wait is:: 63 way to perform a busy wait is::
64 64
65 while (my_variable != what_i_want) 65 while (my_variable != what_i_want)
66 cpu_relax(); 66 cpu_relax();
67 67
68 The cpu_relax() call can lower CPU power consu 68 The cpu_relax() call can lower CPU power consumption or yield to a
69 hyperthreaded twin processor; it also happens 69 hyperthreaded twin processor; it also happens to serve as a compiler
70 barrier, so, once again, volatile is unnecessa 70 barrier, so, once again, volatile is unnecessary. Of course, busy-
71 waiting is generally an anti-social act to beg 71 waiting is generally an anti-social act to begin with.
72 72
73 There are still a few rare situations where vo 73 There are still a few rare situations where volatile makes sense in the
74 kernel: 74 kernel:
75 75
76 - The above-mentioned accessor functions mig 76 - The above-mentioned accessor functions might use volatile on
77 architectures where direct I/O memory acce 77 architectures where direct I/O memory access does work. Essentially,
78 each accessor call becomes a little critic 78 each accessor call becomes a little critical section on its own and
79 ensures that the access happens as expecte 79 ensures that the access happens as expected by the programmer.
80 80
81 - Inline assembly code which changes memory, 81 - Inline assembly code which changes memory, but which has no other
82 visible side effects, risks being deleted 82 visible side effects, risks being deleted by GCC. Adding the volatile
83 keyword to asm statements will prevent thi 83 keyword to asm statements will prevent this removal.
84 84
85 - The jiffies variable is special in that it 85 - The jiffies variable is special in that it can have a different value
86 every time it is referenced, but it can be 86 every time it is referenced, but it can be read without any special
87 locking. So jiffies can be volatile, but 87 locking. So jiffies can be volatile, but the addition of other
88 variables of this type is strongly frowned 88 variables of this type is strongly frowned upon. Jiffies is considered
89 to be a "stupid legacy" issue (Linus's wor 89 to be a "stupid legacy" issue (Linus's words) in this regard; fixing it
90 would be more trouble than it is worth. 90 would be more trouble than it is worth.
91 91
92 - Pointers to data structures in coherent me 92 - Pointers to data structures in coherent memory which might be modified
93 by I/O devices can, sometimes, legitimatel 93 by I/O devices can, sometimes, legitimately be volatile. A ring buffer
94 used by a network adapter, where that adap 94 used by a network adapter, where that adapter changes pointers to
95 indicate which descriptors have been proce 95 indicate which descriptors have been processed, is an example of this
96 type of situation. 96 type of situation.
97 97
98 For most code, none of the above justification 98 For most code, none of the above justifications for volatile apply. As a
99 result, the use of volatile is likely to be se 99 result, the use of volatile is likely to be seen as a bug and will bring
100 additional scrutiny to the code. Developers w 100 additional scrutiny to the code. Developers who are tempted to use
101 volatile should take a step back and think abo 101 volatile should take a step back and think about what they are truly trying
102 to accomplish. 102 to accomplish.
103 103
104 Patches to remove volatile variables are gener 104 Patches to remove volatile variables are generally welcome - as long as
105 they come with a justification which shows tha 105 they come with a justification which shows that the concurrency issues have
106 been properly thought through. 106 been properly thought through.
107 107
108 108
109 References 109 References
110 ========== 110 ==========
111 111
112 [1] https://lwn.net/Articles/233481/ !! 112 [1] http://lwn.net/Articles/233481/
113 113
114 [2] https://lwn.net/Articles/233482/ !! 114 [2] http://lwn.net/Articles/233482/
115 115
116 Credits 116 Credits
117 ======= 117 =======
118 118
119 Original impetus and research by Randy Dunlap 119 Original impetus and research by Randy Dunlap
120 120
121 Written by Jonathan Corbet 121 Written by Jonathan Corbet
122 122
123 Improvements via comments from Satyam Sharma, 123 Improvements via comments from Satyam Sharma, Johannes Stezenbach, Jesper
124 Juhl, Heikki Orsila, H. Peter Anvin, Philipp H 124 Juhl, Heikki Orsila, H. Peter Anvin, Philipp Hahn, and Stefan
125 Richter. 125 Richter.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.