深入理解linux核心自旋鎖__linux

最近在核心頻繁使用了自旋鎖，自旋鎖如果使用不當，極易引起死結，在此總結一下。

自旋鎖是一個互斥裝置，它只有兩個值：“鎖定”和“解鎖”。它通常實現為某個整數值中的某個位。希望獲得某個特定鎖得代碼測試相關的位。如果鎖可用，則“鎖定”被設定，而代碼繼續進入臨界區；相反，如果鎖被其他人獲得，則代碼進入忙迴圈（而不是休眠，這也是自旋鎖和一般鎖的區別）並重複檢查這個鎖，直到該鎖可用為止，這就是自旋的過程。“測試並設定位”的操作必須是原子的，這樣，即使多個線程在給定時間自旋，也只有一個線程可獲得該鎖。

自旋鎖最初是為了在多處理器系統（SMP）使用而設計的，但是只要考慮到並發問題，單一處理器在運行可搶佔核心時其行為就類似於SMP。因此，自旋鎖對於SMP和單一處理器可搶佔核心都適用。可以想象，當一個處理器處於自旋狀態時，它做不了任何有用的工作，因此自旋鎖對於單一處理器不可搶佔核心沒有意義，實際上，非搶佔式的單一處理器系統上自旋鎖被實現為空白操作，不做任何事情。

自旋鎖有幾個重要的特性：1、被自旋鎖保護的臨界區代碼執行時不能進入休眠。2、被自旋鎖保護的臨界區代碼執行時是不能被被其他中斷中斷。3、被自旋鎖保護的臨界區代碼執行時，核心不能被搶佔。從這幾個特性可以歸納出一個共性：被自旋鎖保護的臨界區代碼執行時，它不能因為任何原因放棄處理器。

考慮上面第一種情況，想象你的核心代碼請求到一個自旋鎖並且在它的臨界區裡做它的事情，在中間某處，你的代碼失去了處理器。或許它已調用了一個函數（copy_from_user，假設）使進程進入睡眠。也或許，核心搶佔發威，一個更高優先順序的進程將你的代碼推到了一邊。此時，正好某個別的線程想擷取同一個鎖，如果這個線程運行在和你的核心代碼不同的處理器上（幸運的情況），那麼它可能要自旋等待一段時間（可能很長），當你的代碼從休眠中喚醒或者重新得到處理器並釋放鎖，它就能得到鎖。而最壞的情況是，那個想擷取鎖得線程剛好和你的代碼運行在同一個處理器上，這時它將一直持有CPU進行自旋操作，而你的代碼是永遠不可能有任何機會來獲得CPU釋放這個鎖了，這就是悲催的死結。

考慮上面第二種情況，和上面第一種情況類似。假設我們的驅動程式正在運行，並且已經擷取了一個自旋鎖，這個鎖控制著對裝置的訪問。在擁有這個鎖得時候，裝置產生了一個中斷，它導致中斷處理常式被調用，而中斷處理常式在訪問裝置之前，也要獲得這個鎖。當中斷處理常式和我們的驅動程式代碼在同一個處理器上運行時，由於中斷處理常式持有CPU不斷自旋，我們的代碼將得不到機會釋放鎖，這也將導致死結。

因此，如果我們有一個自旋鎖，它可以被運行在（硬體或軟體）中斷上下文中的代碼獲得，則必須使用某個禁用中斷的spin_lock形式的鎖來禁用本地中斷（注意，只是禁用本地CPU的中斷，不能禁用別的處理器的中斷），使用其他的鎖定函數遲早會導致系統死結（導致死結的時間可能不定，但是發生上述死結情況的機率肯定是有的，看處理器怎麼調度了）。如果我們不會在硬中斷處理常式中訪問自旋鎖，但可能在非強制中斷（例如，以tasklet的形式啟動並執行代碼）中訪問，則應該使用spin_lock_bh，以便在安全避免死結的同時還能服務硬體中斷。

補充：

鎖定一個自旋鎖的函數有四個：

void spin_lock(spinlock_t *lock);      

最基本得自旋鎖函數，它不失效本地中斷。

void spin_lock_irqsave(spinlock_t *lock, unsigned long flags);

在獲得自旋鎖之前禁用硬中斷（只在本地處理器上），而先前的中斷狀態儲存在flags中

void spin_lockirq(spinlock_t *lock);

在獲得自旋鎖之前禁用硬中斷（只在本地處理器上），不儲存中斷狀態

void spin_lock_bh(spinlock_t *lock);

在獲得鎖前禁用非強制中斷，保持硬中斷開啟狀態