โปรแกรมเมอร์ C มักถูกลบเลือนเพื่อแปลว่าตัวแปรสามารถเปลี่ยนแปลงได้นอกเธรดการทำงานปัจจุบัน เป็นผลให้บางครั้งพวกเขาถูกล่อลวงให้ใช้มันในรหัสเคอร์เนลเมื่อมีการใช้โครงสร้างข้อมูลที่ใช้ร่วมกัน กล่าวอีกอย่างหนึ่งก็คือพวกมันเป็นที่รู้จักกันดีว่ารักษาชนิดระเหยได้เป็นตัวแปรอะตอมแบบง่ายซึ่งไม่ใช่ การใช้ตัวระเหยในโค้ดเคอร์เนลแทบจะไม่ถูกต้องเลย เอกสารนี้อธิบายถึงสาเหตุ
ประเด็นสำคัญที่จะเข้าใจเกี่ยวกับความผันผวนคือจุดประสงค์ของมันคือการระงับการปรับให้เหมาะสมซึ่งแทบจะไม่เคยมีในสิ่งที่เราต้องการทำ ในเคอร์เนลเราจะต้องปกป้องโครงสร้างข้อมูลที่ใช้ร่วมกันจากการเข้าถึงพร้อมกันที่ไม่พึงประสงค์ซึ่งเป็นงานที่แตกต่างกันมาก กระบวนการป้องกันการเกิดพร้อมกันที่ไม่ต้องการจะหลีกเลี่ยงปัญหาที่เกี่ยวข้องกับการปรับให้เหมาะสมเกือบทั้งหมดในวิธีที่มีประสิทธิภาพมากขึ้น
เคอร์เนลแบบดั้งเดิมซึ่งทำให้การเข้าถึงข้อมูลปลอดภัยพร้อมกัน (spinlocks, mutexes, อุปสรรคของหน่วยความจำและอื่น ๆ ) ได้รับการออกแบบมาเพื่อป้องกันการเพิ่มประสิทธิภาพที่ไม่พึงประสงค์ หากมีการใช้อย่างเหมาะสมก็ไม่จำเป็นต้องใช้สารระเหยเช่นกัน หากความผันผวนยังคงเป็นสิ่งที่จำเป็นมีข้อผิดพลาดในรหัสเกือบแน่นอน ในโค้ดเคอร์เนลที่ถูกเขียนอย่างเหมาะสมสารระเหยสามารถทำหน้าที่ชะลอสิ่งต่างๆได้เท่านั้น
พิจารณาบล็อกทั่วไปของรหัสเคอร์เนล:
spin_lock(&the_lock);
do_something_on(&shared_data);
do_something_else_with(&shared_data);
spin_unlock(&the_lock);
หากรหัสทั้งหมดเป็นไปตามกฎการล็อคค่าของ shared_data จะไม่สามารถเปลี่ยนแปลงได้โดยไม่คาดคิดในขณะที่ล็อกอยู่ รหัสอื่นใดที่อาจต้องการเล่นกับข้อมูลนั้นจะต้องรอการล็อค ลำดับต้นของ spinlock ทำหน้าที่เป็นตัวกั้นหน่วยความจำ - ซึ่งถูกเขียนอย่างชัดเจนให้ทำซึ่งหมายความว่าการเข้าถึงข้อมูลจะไม่ถูกปรับให้เหมาะสม ดังนั้นคอมไพเลอร์อาจคิดว่ารู้ว่าอะไรจะอยู่ใน shared_data แต่การเรียก spin_lock () เนื่องจากมันทำหน้าที่เป็นกำแพงกั้นหน่วยความจำจะบังคับให้ลืมสิ่งที่รู้ จะไม่มีปัญหาการปรับให้เหมาะสมกับการเข้าถึงข้อมูลนั้น
หาก shared_data ถูกประกาศว่ามีความผันผวนการล็อคจะยังคงมีความจำเป็น แต่คอมไพเลอร์ก็จะถูกป้องกันไม่ให้มีการเพิ่มประสิทธิภาพการเข้าถึง shared_data ภายในส่วนที่สำคัญเมื่อเรารู้ว่าไม่มีใครสามารถทำงานร่วมกับมันได้ ในขณะที่ล็อคจะถูกเก็บไว้ shared_data จะไม่เปลี่ยนแปลง เมื่อจัดการกับข้อมูลที่ใช้ร่วมกันการล็อคที่เหมาะสมทำให้เกิดความไม่จำเป็นในการระเหยและอาจเป็นอันตราย
คลาสหน่วยเก็บข้อมูลแบบระเหยนั้นมีไว้สำหรับการลงทะเบียน I / O ที่แม็พหน่วยความจำ ภายในเคอร์เนลการเข้าถึงการลงทะเบียนก็ควรได้รับการปกป้องด้วยการล็อก แต่ก็ไม่ต้องการให้การเข้าถึงรีจิสเตอร์ "การเพิ่มประสิทธิภาพ" ของคอมไพเลอร์ภายในส่วนที่สำคัญ แต่ภายในเคอร์เนลการเข้าถึงหน่วยความจำ I / O จะกระทำผ่านฟังก์ชั่นการเข้าถึง การเข้าถึงหน่วยความจำ I / O โดยตรงผ่านตัวชี้จะถูกดึงออกมาและไม่สามารถใช้ได้กับสถาปัตยกรรมทั้งหมด อุปกรณ์เสริมเหล่านั้นถูกเขียนขึ้นเพื่อป้องกันการเพิ่มประสิทธิภาพที่ไม่พึงประสงค์ดังนั้นความผันผวนจึงไม่จำเป็นอีกครั้ง
อีกสถานการณ์หนึ่งที่อาจถูกล่อลวงให้ใช้ความผันผวนคือเมื่อตัวประมวลผลกำลังยุ่งอยู่กับค่าของตัวแปร วิธีที่ถูกต้องในการรอคอยที่ยุ่งคือ:
while (my_variable != what_i_want)
cpu_relax();
การเรียก cpu_relax () สามารถลดการใช้พลังงานของ CPU หรือลดการใช้โพรเซสเซอร์คู่ที่มีเธรดมากเกินไป มันยังเกิดขึ้นเพื่อทำหน้าที่เป็นกำแพงหน่วยความจำดังนั้นอีกครั้งไม่จำเป็นระเหย แน่นอนว่าการรอไม่ว่างนั้นเป็นการกระทำเพื่อต่อต้านสังคมที่เริ่มต้นด้วย
ยังมีสถานการณ์ที่หายากอยู่เล็กน้อยที่ความผันผวนทำให้เกิดความรู้สึกในเคอร์เนล:
ฟังก์ชั่นการเข้าถึงดังกล่าวอาจใช้ความผันผวนในสถาปัตยกรรมที่การเข้าถึงหน่วยความจำโดยตรง I / O ทำงาน โดยพื้นฐานแล้วการเรียกใช้การเข้าถึงแต่ละครั้งจะกลายเป็นส่วนสำคัญเล็กน้อยในตัวเองและทำให้มั่นใจได้ว่าการเข้าถึงเกิดขึ้นตามที่โปรแกรมเมอร์คาดไว้
รหัสการประกอบแบบอินไลน์ซึ่งเปลี่ยนหน่วยความจำ แต่ไม่มีผลข้างเคียงอื่นใดที่มองเห็นได้ความเสี่ยงถูกลบโดย GCC การเพิ่มคำสำคัญระเหยลงในคำสั่ง asm จะป้องกันการลบนี้
ตัวแปร jiffies มีความพิเศษที่สามารถมีค่าที่แตกต่างกันทุกครั้งที่มีการอ้างอิง แต่สามารถอ่านได้โดยไม่มีการล็อกพิเศษ ดังนั้น jiffies สามารถเปลี่ยนแปลงได้ แต่การเพิ่มตัวแปรอื่น ๆ ของประเภทนี้จะขมวดคิ้วอย่างมาก จิฟฟี่ถือว่าเป็นปัญหา "โง่เขลา" (คำพูดของไลนัส) ในเรื่องนี้; แก้ไขมันจะเป็นปัญหามากกว่าที่มันคุ้มค่า
ตัวชี้ไปยังโครงสร้างข้อมูลในหน่วยความจำที่เชื่อมโยงกันซึ่งอาจมีการแก้ไขโดยอุปกรณ์ I / O สามารถระเหยได้อย่างถูกกฎหมายในบางครั้ง วงแหวนบัฟเฟอร์ที่ใช้โดยอะแดปเตอร์เครือข่ายโดยที่อะแดปเตอร์นั้นเปลี่ยนพอยน์เตอร์เพื่อระบุว่าตัวให้คำอธิบายใดที่ได้รับการประมวลผลเป็นตัวอย่างของสถานการณ์ประเภทนี้
สำหรับรหัสส่วนใหญ่ไม่มีการอ้างเหตุผลใด ๆ ข้างต้นสำหรับการระเหย เป็นผลให้การใช้สารระเหยมีแนวโน้มที่จะถูกมองว่าเป็นจุดบกพร่องและจะนำการตรวจสอบเพิ่มเติมไปยังรหัส นักพัฒนาที่ถูกล่อลวงให้ใช้สารระเหยควรถอยกลับมาและคิดว่าพวกเขาพยายามทำอะไรให้สำเร็จ