1
2 .. _volatile_considered_harmful:
3
4 Why the "volatile" type class should not be us
5 ----------------------------------------------
6
7 C programmers have often taken volatile to mea
8 changed outside of the current thread of execu
9 sometimes tempted to use it in kernel code whe
10 being used. In other words, they have been kn
11 as a sort of easy atomic variable, which they
12 kernel code is almost never correct; this docu
13
14 The key point to understand with regard to vol
15 to suppress optimization, which is almost neve
16 do. In the kernel, one must protect shared da
17 unwanted concurrent access, which is very much
18 process of protecting against unwanted concurr
19 all optimization-related problems in a more ef
20
21 Like volatile, the kernel primitives which mak
22 safe (spinlocks, mutexes, memory barriers, etc
23 unwanted optimization. If they are being used
24 need to use volatile as well. If volatile is
25 almost certainly a bug in the code somewhere.
26 code, volatile can only serve to slow things d
27
28 Consider 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
35 If all the code follows the locking rules, the
36 change unexpectedly while the_lock is held. A
37 want to play with that data will be waiting on
38 primitives act as memory barriers - they are e
39 meaning that data accesses will not be optimiz
40 compiler might think it knows what will be in
41 spin_lock() call, since it acts as a memory ba
42 forget anything it knows. There will be no op
43 accesses to that data.
44
45 If shared_data were declared volatile, the loc
46 necessary. But the compiler would also be pre
47 to shared_data _within_ the critical section,
48 can be working with it. While the lock is hel
49 volatile. When dealing with shared data, prop
50 unnecessary - and potentially harmful.
51
52 The volatile storage class was originally mean
53 registers. Within the kernel, register access
54 by locks, but one also does not want the compi
55 accesses within a critical section. But, with
56 accesses are always done through accessor func
57 directly through pointers is frowned upon and
58 architectures. Those accessors are written to
59 optimization, so, once again, volatile is unne
60
61 Another situation where one might be tempted t
62 when the processor is busy-waiting on the valu
63 way to perform a busy wait is::
64
65 while (my_variable != what_i_want)
66 cpu_relax();
67
68 The cpu_relax() call can lower CPU power consu
69 hyperthreaded twin processor; it also happens
70 barrier, so, once again, volatile is unnecessa
71 waiting is generally an anti-social act to beg
72
73 There are still a few rare situations where vo
74 kernel:
75
76 - The above-mentioned accessor functions mig
77 architectures where direct I/O memory acce
78 each accessor call becomes a little critic
79 ensures that the access happens as expecte
80
81 - Inline assembly code which changes memory,
82 visible side effects, risks being deleted
83 keyword to asm statements will prevent thi
84
85 - The jiffies variable is special in that it
86 every time it is referenced, but it can be
87 locking. So jiffies can be volatile, but
88 variables of this type is strongly frowned
89 to be a "stupid legacy" issue (Linus's wor
90 would be more trouble than it is worth.
91
92 - Pointers to data structures in coherent me
93 by I/O devices can, sometimes, legitimatel
94 used by a network adapter, where that adap
95 indicate which descriptors have been proce
96 type of situation.
97
98 For most code, none of the above justification
99 result, the use of volatile is likely to be se
100 additional scrutiny to the code. Developers w
101 volatile should take a step back and think abo
102 to accomplish.
103
104 Patches to remove volatile variables are gener
105 they come with a justification which shows tha
106 been properly thought through.
107
108
109 References
110 ==========
111
112 [1] https://lwn.net/Articles/233481/
113
114 [2] https://lwn.net/Articles/233482/
115
116 Credits
117 =======
118
119 Original impetus and research by Randy Dunlap
120
121 Written by Jonathan Corbet
122
123 Improvements via comments from Satyam Sharma,
124 Juhl, Heikki Orsila, H. Peter Anvin, Philipp H
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.