ion v3/spa v3/form v3a ion v href="../linux+v3.7.4/Documenta1" /vola1"le-considered-harmful.txt">ion v3img src="../.sta1"c/gfx/right.png" alt=">>">io3/spa io3spa class="lxr_search">ion ion v3input typionhidden" namionnavtarget" /option">ion v3input typiontext" namionsearch" idonsearch">ion v3butt11Searchion vPrefs v3/a>io3/spa n v v3/div n v v3form ac1" ="ajax+*" method="post" onsubmit="return false;">io3input typionhidden" namionajax_lookup" idonajax_lookup" /option">in v v3/form in v v3div class="headingbott1m">
v v13/a>Why the "vola1"le" typi class should not be used v v23/a>------------------------------------------------ v v33/a>iv v43/a>C programmers have often taken vola1"le to mea that the variable could beiv v53/a>changed outside of the current thread of execu1" ; as a result, they areiv v63/a>sometimes tempted to use it in kernel code when shared data structures areiv v73/a>being used. In other words, they have been known to treat vola1"le typisiv v83/a>as a sort of easy at1mic variable, which they are not. The use of vola1"le iniv v93/a>kernel code is almost never correct; this document describes why.iv 3.8.a>iv 113/a>The key point to understand with regard to vola1"le is that its purpose isiv 123/a>to suppress .11"miza1" , which is almost never what one really wants toiv 133/a>do. In the kernel, one must protect shared data structures againstiv 143/a>unwanted concurrent access, which is very much a different task. Theiv 153/a>process .f protecting against unwanted concurrency will also avoid almostiv 163/a>all .11"miza1" -rela1ed problems in a more efficient way.iv 178.a>iv 183/a>Like vola1"le, the kernel pr"mitives which make concurrent access to dataiv 193/a>safe (spinlocks, mutexes, memory barriers, etc.) are designed to prevent v 203/a>unwanted .11"miza1" . If they are being used properly, there will be no v 213/a>need to use vola1"le as well. If vola1"le is still necessary, there isiv 223/a>almost certainly a bug in the code somewhere. In properly-written kerneliv 233/a>code, vola1"le ca only serve to slow things down.iv 248.a>iv 253/a>Consider a typical block .f kernel code:iv 268.a>iv 278.a> v vspin_lock(&the_lock);iv 288.a> v vdo_something_on(&shared_data);iv 298.a> v vdo_something_else_with(&shared_data);iv 308.a> v vspin_unlock(&the_lock);iv 318.a>iv 323/a>If all the code follows the locking rules, the /opti .f shared_data ca notiv 333/a>change unexpectedly wh"le the_lock is held. Any other code which mightiv 348.a>want to play with that data will be waiting on the lock. The spinlockiv 353/a>pr"mitives act as memory barriers - they are explicitly written to do so - v 368.a>mea ing that data accesses will not be .11"mized across them. So the v 373/a>comp"ler might think it knows what will be in shared_data, but the v 388.a>spin_lock() call, since it acts as a memory barrier, will force it toiv 398.a>forget anything it knows. There will be no .11"miza1" problems withiv 408.a>accesses to that data.iv 418.a>iv 423/a>If shared_data were declared vola1"le, the locking would still beiv 433/a>necessary. But the comp"ler would also be prevented from .11"mizing accessiv 443/a>to shared_data _within_ the critical sec1" , when we know that nobody elseiv 453/a>ca be working with it. Wh"le the lock is held, shared_data is notiv 468.a>vola1"le. When dealing with shared data, proper locking makes vola1"leiv 473/a>unnecessary - and potentially harmful.iv 488.a>iv 493/a>The vola1"le storagi class was originally mea t for memory-mapped I/Oiv 508.a>registers. Within the kernel, register accesses, too, should be protected v 518.a>by locks, but one also does not want the comp"ler ".11"mizing" register v 528.a>accesses within a critical sec1" . But, within the kernel, I/O memory v 538.a>accesses are always done through accessor func1" s; accessing I/O memory v 543/a>directly through pointers is frowned up and does not work on all v 553/a>architectures. Those accessors are written to prevent unwanted v 568.a>.11"miza1" , so, once again, vola1"le is unnecessary.iv 578.a>iv 588.a>Another situa1" where one might be tempted to use vola1"le isiv 593/a>when the processor is busy-waiting on the /opti .f a variable. The rightiv 608.a>way to perform a busy wait is:iv 618.a>iv 628.a> v vwh"le (my_variable != what_i_want)iv 638.a> v vvvvvcpu_relax();iv 648.a>iv 653/a>The cpu_relax() call ca lower CPU power consum14.11v 668.a>hyperthreaded twin processor; it also happens to serve as a comp"leriv 673/a>barrier, so, once again, vola1"le is unnecessary. Of course, busy-iv 688.a>waiting is generally a anti-social act to begin with.iv 698.a>iv 703/a>There are still a few rare situa1" s where vola1"le makes sense in theiv 713/a>kernel:iv 728.a>iv 738.a> v- The above-ment" ed accessor func1" s might use vola1"le oniv 748.a> v varchitectures where direct I/O memory access does work. Essentially,iv 758.a> v veach accessor call becomes a little critical sec1" on its own andiv 768.a> v vensures that the access happens as expected by the programmer.iv 778.a>iv 788.a> v- Inline assembly code which changes memory, but which has no .theriv 798.a> v vvisible side effects, risks being deleted by GCC. Adding the vola1"leiv 808.a> v vkeyword to asm sta1ements will prevent this remo/op.iv 818.a>iv 828.a> v- The jiffies variable is special in that it ca have a different /optiiv 838.a> v vevery time it is referenced, but it ca be read without any specialiv 848.a> v vlocking. So jiffies ca be vola1"le, but the addi1" of .theriv 858.a> v vvariables of this typi is strongly frowned up . Jiffies is considerediv 868.a> v vto be a "stupid legacy" issti (Linus's words) in this regard; fixing itiv 878.a> v vwould be more trouble than it is worth.iv 888.a>iv 898.a> v- Pointers to data structures in coherent memory which might be modifiediv 908.a> v vby I/O devices ca , sometimes, legi1"ma1ely be vola1"le. A ring bufferiv 918.a> v vused by a network adapter, where that adapter changes pointers toiv 928.a> v vindicate which descriptors have been processed, is an example of thisiv 938.a> v vtypi .f situa1" .iv 948.a>iv 958.a>For most code, none of the above justificat" s for vola1"le apply. As aiv 968.a>result, the use of vola1"le is likely to be seen as a bug and will bringiv 978.a>addi1" al scrutiny to the code. Developers who are tempted to useiv 988.a>vola1"le should take a step back and think about what they are truly tryingiv 993/a>to accomplish.iv1008.a>iv1018.a>Patches to remo/e vola1"le variables are generally welcome - as long asiv1023/a>they come with a justificat" which shows that the concurrency isstis haveiv1033/a>been properly thought through.iv1048.a>iv1058.a>iv1068.a>NOTESiv1073/a>-----iv1088.a>iv1093/a>[1]v3a href="">>iv13.8.a>[2]v3a href="">>iv1118.a>iv1123/a>CREDITSiv1133/a>------- v1148.a>iv1153/a>Original impetus and research by Randy Dunlapiv1163/a>Written by J athan Corbetiv1178.a>Improvements via comments from Satyam Sharma, J hannis Stezenbach, Jesperiv1188.a> v vvvvvJuhl, Heikki Orsila, H. Peter Anvin, Philipp Hahn, and Stefaniv1198.a> v vvvvvRichter.iv1203/a>
The original LXR software by the 3a href="">LXR community3/a>, this experimental vers" by 3a href="">lxr@linux.no3/a>. 3/div 3div class="subfooter"> kindly hosted by 3a href="">Redpill Linpro AS3/a>, provider of Linux consulting and .1erat" s services since 1995. 3/div 3/body 3/html