在這裡，我主要把自己對核心中spinlock的一些理解寫出來，並不是要告訴大傢什麼（因為我對我所說的也不能確定），而是希望大家對我的這些理解對的地方給我肯定，錯誤的地方給我指出。

和spinlock 相關的檔案主要有兩個，一個是include/linux/spinlock.h，主要是提供關於和硬體無關的spinlock的幾個對外主函式，一個是 include/asm-XXX/spinlock.h，用來提供和硬體相關的功能函式。另外，在2.6的核心中，又多了一個檔案， include/linux/preempt.h，為新增加的搶佔式多工功能提供一些服務。

spinlock的作用：spinlock系列函式主要用於保護臨界資料（非常重要的資料）不被同時訪問（給臨界資料加鎖），用以達到多工的同步。如果一個數據當前不可訪問，那麼就一直等，直到可以訪問為止。

spinlock 函式的使用前提：首先，spinklock函式只能使用在核心中，或者說只能使用在核心狀態下，在2.6以前的核心是不可搶佔的，也就是說，當運行於核心狀態下時，是不容許切換到其他程序的

。而在2.6以後的核心中，編譯核心的時候多了一個選項，可以配置核心是否可以被搶佔，這也就是為什麼在2.6的核心中多了一個preempt.h的原因。

spinlock主要包含以下幾個函式：
spin_lock
spin_unlock
spin_lock_irqsave
spin_lock_irq
spin_unlock_irqrestore
spin_unlock_irq
另外還有其他很多，如關於讀者寫者的一套函式，關於bottom half一套函式（關於bottom half的程式碼我還沒有讀到），還有還提供了一套用bit實現加鎖的函式，由於大概意思都相同，所以我這裡就不說了（只想簡單說說，沒想到東西還挺多，我的手都快凍僵了，江南的冬天真的受不了：）
spinlock函式根據機器的配置分為兩套，單CPU和多CPU，先來看看單CPU的情況。
在單CPU的情況下，spin_lock和spin_unlock函式都被定義成空操作（do { } while(0)），這是因為我們上面說的，核心不可以被搶佔的原因。所以，在單CPU的情況下，只要你能夠保證你要保護的臨界資料不會在中斷中用到的話，那麼你的資料已經是受保護的了，不需要做任何操作。在2.6核心中，這兩個函式就不再這麼簡單了，因為核心也有可能被其他程式中斷，所以要保護資料，還要讓排程程式暫時不排程此段程式，也就是說，暫時禁止搶佔式任務排程功能，所以在上面兩個函式中分別多了一個

需要澄清的是，互斥手段的選擇，不是根據臨界區的大小，而是根據臨界區的性質，以及
有哪些部分的程式碼，即哪些核心執行路徑來爭奪。

從嚴格意義上說，semaphore和spinlock_XXX屬於不同層次的互斥手段，前者的
實現有賴於後者，這有點象HTTP和TCP的關係，都是協議，但層次是不同的。

先說semaphore，它是程序級的，用於多個程序之間對資源的互斥，雖然也是在
核心中，但是該核心執行路徑是以程序的身份，代表程序來爭奪資源的。如果
競爭不上，會有context switch，程序可以去sleep，但CPU不會停，會接著執行
其他的執行路徑。從概念上說，這和單CPU或多CPU沒有直接的關係，只是在
semaphore本身的實現上，為了保證semaphore結構存取的原子性，在多CPU中需要
spinlock來互斥。

在核心中，更多的是要保持核心各個執行路徑之間的資料訪問互斥，這是最基本的
互斥問題，即保持資料修改的原子性。semaphore的實現，也要依賴這個。在單CPU
中，主要是中斷和bottom_half的問題，因此，開關中斷就可以了。在多CPU中，
又加上了其他CPU的干擾，因此需要spinlock來幫助。這兩個部分結合起來，
就形成了spinlock_XXX。它的特點是，一旦CPU進入了spinlock_XXX，它就不會
幹別的，而是一直空轉，直到鎖定成功為止。因此，這就決定了被
spinlock_XXX鎖住的臨界區不能停，更不能context switch，要存取完資料後趕快
出來，以便其他的在空轉的執行路徑能夠獲得spinlock。這也是spinlock的原則
所在。如果當前執行路徑一定要進行context switch，那就要在schedule()之前
釋放spinlock，否則，容易死鎖。因為在中斷和bh中，沒有context，無法進行
context switch，只能空轉等待spinlock，你context switch走了，誰知道猴年
馬月才能回來。

因為spinlock的原意和目的就是保證資料修改的原子性，因此也沒有理由在spinlock
鎖住的臨界區中停留。

spinlock_XXX有很多形式，有


那麼，在什麼情況下具體用哪個呢？這要看是在什麼核心執行路徑中，以及要與哪些核心
執行路徑相互斥。我們知道，核心中的執行路徑主要有：

這樣，考慮這四個方面的因素，通過判斷我們要互斥的資料會被這四個因素中
的哪幾個來存取，就可以決定具體使用哪種形式的spinlock。如果只要和其他CPU
互斥，就要用spin_lock/spin_unlock，如果要和irq及其他CPU互斥，就要用
spin_lock_irq/spin_unlock_irq，如果既要和irq及其他CPU互斥，又要儲存
EFLAG的狀態，就要用spin_lock_irqsave/spin_unlock_irqrestore，如果
要和bh及其他CPU互斥，就要用spin_lock_bh/spin_unlock_bh，如果不需要和
其他CPU互斥，只要和irq互斥，則用local_irq_disable/local_irq_enable，
如果不需要和其他CPU互斥，只要和bh互斥，則用local_bh_disable/local_bh_enable，
等等。值得指出的是，對同一個資料的互斥，在不同的核心執行路徑中，
所用的形式有可能不同(見下面的例子)。

舉一個例子。在中斷部分中有一個irq_desc_t型別的結構陣列變數irq_desc[]，
該陣列每個成員對應一個irq的描述結構，裡面有該irq的響應函式等。
在irq_desc_t結構中有一個spinlock，用來保證存取(修改)的互斥。

對於具體一個irq成員，irq_desc[irq]，對其存取的核心執行路徑有兩個，一是
在設定該irq的響應函式時(setup_irq)，這通常發生在module的初始化階段，或
系統的初始化階段；二是在中斷響應函式中(do_IRQ)。程式碼如下：



在setup_irq()中，因為其他CPU可能同時在執行setup_irq()，或者在執行setup_irq()時，
本地irq中斷來了，要執行do_IRQ()以修改desc->status。為了同時防止來自其他CPU和
本地irq中斷的干擾，如[1][2][3]處所示，使用了spin_lock_irqsave/spin_unlock_irqrestore()

而在do_IRQ()中，因為do_IRQ()本身是在中斷中，而且此時還沒有開中斷，本CPU中沒有
什麼可以中斷其執行，其他CPU則有可能在執行setup_irq()，或者也在中斷中，但這二者
對本地do_IRQ()的影響沒有區別，都是來自其他CPU的干擾，因此只需要用spin_lock/spin_unlock，
如[4][5][6][7]處所示。值得注意的是[5]處，先釋放該spinlock，再呼叫具體的響應函式。

再舉個例子：



這裡，對tasklet_hi_vec[cpu]的修改，不存在CPU之間的競爭，因為每個CPU有各自獨立的資料，
所以只要防止irq的干擾，用local_irq_disable/local_irq_enable即可，如[8][9][10][11]處
所示。