自旋锁使用场景和实现分析（转载）
自旋鎖
最近看到的一篇文章，覺得寫的很清晰，通過場景應用解答了我對自旋鎖使用的一些疑問，推薦給大家。
引入問題：
（1）如果cpu0持有鎖，cpu1一直不釋放鎖怎么辦？
（2）什么場景下必須要用自旋鎖，而不能用互斥量？
（3）互斥量或者自旋鎖，他們會被多個進程使用，那么它屬于進程的一部分？
內核當發生訪問資源沖突的時候，可以有兩種鎖的解決方案選擇：
- 一個是原地等待
- 一個是掛起當前進程，調度其他進程執行（睡眠）
Spinlock 是內核中提供的一種比較常見的鎖機制，自旋鎖是“原地等待”的方式解決資源沖突的，即，一個線程獲取了一個自旋鎖后，另外一個線程期望獲取該自旋鎖，獲取不到，只能夠原地“打轉”（忙等待）。由于自旋鎖的這個忙等待的特性，注定了它使用場景上的限制 ——?自旋鎖不應該被長時間的持有（消耗 CPU 資源）。
自旋鎖的使用
在linux kernel的實現中，經常會遇到這樣的場景：共享數據被中斷上下文和進程上下文訪問，該如何保護呢？如果只有進程上下文的訪問，那么可以考慮使用semaphore或者mutex的鎖機制，但是現在中斷上下文也參和進來，那些可以導致睡眠的lock就不能使用了，這時候，可以考慮使用spin lock。
這里為什么把中斷上下文標紅加粗呢？因為在中斷上下文，是不允許睡眠的（原因詳見文章《Linux 中斷之中斷處理淺析》中的第四章），所以，這里需要的是一個不會導致睡眠的鎖——spinlock。
換言之，中斷上下文要用鎖，首選 spinlock。
使用自旋鎖，有兩種方式定義一個鎖：
動態的：
spinlock_t lock;
spin_lock_init (&lock);
靜態的：
DEFINE_SPINLOCK(lock);自旋鎖的死鎖和解決
自旋鎖不可遞歸，自己等待自己已經獲取的鎖，會導致死鎖。
自旋鎖可以在中斷上下文中使用，但是試想一個場景：一個線程獲取了一個鎖，但是被中斷處理程序打斷，中斷處理程序也獲取了這個鎖（但是之前已經被鎖住了，無法獲取到，只能自旋），中斷無法退出，導致線程中后面釋放鎖的代碼無法被執行，導致死鎖。（如果確認中斷中不會訪問和線程中同一個鎖，其實無所謂）
一、考慮下面的場景（內核搶占場景）：
（1）進程A在某個系統調用過程中訪問了共享資源 R
（2）進程B在某個系統調用過程中也訪問了共享資源 R
會不會造成沖突呢？假設在A訪問共享資源R的過程中發生了中斷，中斷喚醒了沉睡中的，優先級更高的B，在中斷返回現場的時候，發生進程切換，B啟動執行，并通過系統調用訪問了R，如果沒有鎖保護，則會出現兩個thread進入臨界區，導致程序執行不正確。OK，我們加上spin lock看看如何：A在進入臨界區之前獲取了spin lock，同樣的，在A訪問共享資源R的過程中發生了中斷，中斷喚醒了沉睡中的，優先級更高的B，B在訪問臨界區之前仍然會試圖獲取spin lock，這時候由于A進程持有spin lock而導致B進程進入了永久的spin……怎么破？linux的kernel很簡單，在A進程獲取spin lock的時候，禁止本CPU上的搶占（上面的永久spin的場合僅僅在本CPU的進程搶占本CPU的當前進程這樣的場景中發生）。如果A和B運行在不同的CPU上，那么情況會簡單一些：A進程雖然持有spin lock而導致B進程進入spin狀態，不過由于運行在不同的CPU上，A進程會持續執行并會很快釋放spin lock，解除B進程的spin狀態
二、再考慮下面的場景（中斷上下文場景）：
（1）運行在CPU0上的進程A在某個系統調用過程中訪問了共享資源 R
（2）運行在CPU1上的進程B在某個系統調用過程中也訪問了共享資源 R
（3）外設P的中斷handler中也會訪問共享資源 R
在這樣的場景下，使用spin lock可以保護訪問共享資源R的臨界區嗎？我們假設CPU0上的進程A持有spin lock進入臨界區，這時候，外設P發生了中斷事件，并且調度到了CPU1上執行，看起來沒有什么問題，執行在CPU1上的handler會稍微等待一會CPU0上的進程A，等它立刻臨界區就會釋放spin lock的，但是，如果外設P的中斷事件被調度到了CPU0上執行會怎么樣？CPU0上的進程A在持有spin lock的狀態下被中斷上下文搶占，而搶占它的CPU0上的handler在進入臨界區之前仍然會試圖獲取spin lock，悲劇發生了，CPU0上的P外設的中斷handler永遠的進入spin狀態，這時候，CPU1上的進程B也不可避免在試圖持有spin lock的時候失敗而導致進入spin狀態。為了解決這樣的問題，linux kernel采用了這樣的辦法：如果涉及到中斷上下文的訪問，spin lock需要和禁止本 CPU 上的中斷聯合使用。
三、再考慮下面的場景（底半部場景）
linux kernel中提供了豐富的bottom half的機制，雖然同屬中斷上下文，不過還是稍有不同。我們可以把上面的場景簡單修改一下：外設P不是中斷handler中訪問共享資源R，而是在的bottom half中訪問。使用spin lock+禁止本地中斷當然是可以達到保護共享資源的效果，但是使用牛刀來殺雞似乎有點小題大做，這時候disable bottom half就OK了
四、中斷上下文之間的競爭
同一種中斷handler之間在uni core和multi core上都不會并行執行，這是linux kernel的特性。
如果不同中斷handler需要使用spin lock保護共享資源，對于新的內核（不區分fast handler和slow handler），所有handler都是關閉中斷的，因此使用spin lock不需要關閉中斷的配合。
bottom half又分成softirq和tasklet，同一種softirq會在不同的CPU上并發執行，因此如果某個驅動中的softirq的handler中會訪問某個全局變量，對該全局變量是需要使用spin lock保護的，不用配合disable CPU中斷或者bottom half。
tasklet更簡單，因為同一種tasklet不會多個CPU上并發。
自旋鎖的實現
1、文件整理
和體系結構無關的代碼如下：
（1）?include/linux/spinlock_types.h
這個頭文件定義了通用spin lock的基本的數據結構（例如spinlock_t）和如何初始化的接口（DEFINE_SPINLOCK）。這里的“通用”是指不論SMP還是UP都通用的那些定義。
（2）include/linux/spinlock_types_up.h
這個頭文件不應該直接include，在include/linux/spinlock_types.h文件會根據系統的配置（是否SMP）include相關的頭文件，如果UP則會include該頭文件。這個頭文定義UP系統中和spin lock的基本的數據結構和如何初始化的接口。當然，對于non-debug版本而言，大部分struct都是empty的。
（3）include/linux/spinlock.h
這個頭文件定義了通用spin lock的接口函數聲明，例如spin_lock、spin_unlock等，使用spin lock模塊接口API的驅動模塊或者其他內核模塊都需要include這個頭文件。
（4）include/linux/spinlock_up.h
這個頭文件不應該直接include，在include/linux/spinlock.h文件會根據系統的配置（是否SMP）include相關的頭文件。這個頭文件是debug版本的spin lock需要的。
（5）include/linux/spinlock_api_up.h
同上，只不過這個頭文件是non-debug版本的spin lock需要的
（6）linux/spinlock_api_smp.h
SMP上的spin lock模塊的接口聲明
（7）kernel/locking/spinlock.c
SMP上的spin lock實現。
對UP和SMP上spin lock頭文件進行整理：
| UP需要的頭文件 | SMP需要的頭文件 |
| linux/spinlock_type_up.h:? | asm/spinlock_types.h? |
2、數據結構
首先定義一個 spinlock_t 的數據類型，其本質上是一個整數值（對該數值的操作需要保證原子性），該數值表示spin lock是否可用。初始化的時候被設定為1。當thread想要持有鎖的時候調用spin_lock函數，該函數將spin lock那個整數值減去1，然后進行判斷，如果等于0，表示可以獲取spin lock，如果是負數，則說明其他thread的持有該鎖，本thread需要spin。
內核中的spinlock_t的數據類型定義如下：
typedef struct spinlock {
struct raw_spinlock rlock;
} spinlock_t;
typedef struct raw_spinlock {
arch_spinlock_t raw_lock;
} raw_spinlock_t;
通用（適用于各種arch）的spin lock使用spinlock_t這樣的type name，各種arch定義自己的struct raw_spinlock。聽起來不錯的主意和命名方式，直到linux realtime tree（PREEMPT_RT）提出對spinlock的挑戰。real time linux是一個試圖將linux kernel增加硬實時性能的一個分支（你知道的，linux kernel mainline只是支持soft realtime），多年來，很多來自realtime branch的特性被merge到了mainline上，例如：高精度timer、中斷線程化等等。realtime tree希望可以對現存的spinlock進行分類：一種是在realtime kernel中可以睡眠的spinlock，另外一種就是在任何情況下都不可以睡眠的spinlock。分類很清楚但是如何起名字？起名字絕對是個技術活，起得好了事半功倍，可維護性好，什么文檔啊、注釋啊都素那浮云，閱讀代碼就是享受，如沐春風。起得不好，注定被后人唾棄，或者拖出來吊打（這讓我想起給我兒子起名字的那段不堪回首的歲月……）。最終，spin lock的命名規范定義如下：
（1）spinlock，在rt linux（配置了PREEMPT_RT）的時候可能會被搶占（實際底層可能是使用支持PI（優先級翻轉）的mutext）。
（2）raw_spinlock，即便是配置了PREEMPT_RT也要頑強的spin
（3）arch_spinlock，spin lock是和architecture相關的，arch_spinlock是architecture相關的實現
對于UP平臺，所有的arch_spinlock_t都是一樣的，定義如下：
typedef struct { } arch_spinlock_t;什么都沒有，一切都是空啊。當然，這也符合前面的分析，對于UP，即便是打開的preempt選項，所謂的spin lock也不過就是disable preempt而已，不需定義什么spin lock的變量。
對于SMP平臺，這和arch相關，我們在下面描述。
在具體的實現面，我們不可能把每一個接口函數的代碼都呈現出來，我們選擇最基礎的spin_lock為例子，其他的讀者可以自己閱讀代碼來理解。
spin_lock的代碼如下：
static inline void spin_lock(spinlock_t *lock)
{
raw_spin_lock(&lock->rlock);
}
當然，在linux mainline代碼中，spin_lock和raw_spin_lock是一樣的，在這里重點看看raw_spin_lock，代碼如下：
#define raw_spin_lock(lock) _raw_spin_lock(lock)UP中的實現：
#define _raw_spin_lock(lock) __LOCK(lock)
#define __LOCK(lock) \
do { preempt_disable(); ___LOCK(lock); } while (0)
SMP的實現：
void __lockfunc _raw_spin_lock(raw_spinlock_t *lock)
{
__raw_spin_lock(lock);
}
static inline void __raw_spin_lock(raw_spinlock_t *lock)
{
preempt_disable();
spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
LOCK_CONTENDED(lock, do_raw_spin_trylock, do_raw_spin_lock);
}
UP中很簡單，本質上就是一個preempt_disable而已，SMP中稍顯復雜，preempt_disable當然也是必須的，spin_acquire可以略過，這是和運行時檢查鎖的有效性有關的，如果沒有定義CONFIG_LOCKDEP其實就是空函數。如果沒有定義CONFIG_LOCK_STAT（和鎖的統計信息相關），LOCK_CONTENDED就是調用 do_raw_spin_lock 而已，如果沒有定義CONFIG_DEBUG_SPINLOCK，它的代碼如下：
static inline void do_raw_spin_lock(raw_spinlock_t *lock) __acquires(lock)
{
__acquire(lock);
arch_spin_lock(&lock->raw_lock);
}
__acquire和靜態代碼檢查相關，忽略之，最終實際的獲取spin lock還是要靠arch相關的代碼實現。
針對 ARM 平臺的?arch_spin_lock
代碼位于arch/arm/include/asm/spinlock.h和spinlock_type.h，和通用代碼類似，spinlock_type.h定義ARM相關的spin lock定義以及初始化相關的宏；spinlock.h中包括了各種具體的實現。
1. 回到2.6.23版本的內核中
和arm平臺相關spin lock數據結構的定義如下（那時候還是使用raw_spinlock_t而不是arch_spinlock_t）：
typedef struct {
volatile unsigned int lock;
} raw_spinlock_t;
一個整數就OK了，0表示unlocked，1表示locked。配套的API包括__raw_spin_lock和__raw_spin_unlock。__raw_spin_lock會持續判斷lock的值是否等于0，如果不等于0（locked）那么其他thread已經持有該鎖，本thread就不斷的spin，判斷lock的數值，一直等到該值等于0為止，一旦探測到lock等于0，那么就設定該值為1，表示本thread持有該鎖了，當然，這些操作要保證原子性，細節和exclusive版本的ldr和str（即ldrex和strexeq）相關，這里略過。立刻臨界區后，持鎖thread會調用__raw_spin_unlock函數是否spin lock，其實就是把0這個數值賦給lock。
這個版本的spin lock的實現當然可以實現功能，而且在沒有沖突的時候表現出不錯的性能，不過存在一個問題：不公平。也就是所有的thread都是在無序的爭搶spin lock，誰先搶到誰先得，不管thread等了很久還是剛剛開始spin。在沖突比較少的情況下，不公平不會體現的特別明顯，然而，隨著硬件的發展，多核處理器的數目越來越多，多核之間的沖突越來越劇烈，無序競爭的spinlock帶來的performance issue終于浮現出來，根據Nick Piggin的描述：
On an 8 core (2 socket) Opteron, spinlock unfairness is extremely noticable, with a
userspace test having a difference of up to 2x runtime per thread, and some threads are
starved or "unfairly" granted the lock up to 1 000 000 (!) times.
多么的不公平，有些可憐的thread需要饑餓的等待1000000次。本質上無序競爭從概率論的角度看應該是均勻分布的，不過由于硬件特性導致這么嚴重的不公平，我們來看一看硬件block：
lock本質上是保存在main memory中的，由于cache的存在，當然不需要每次都有訪問main memory。在多核架構下，每個CPU都有自己的L1 cache，保存了lock的數據。假設CPU0獲取了spin lock，那么執行完臨界區，在釋放鎖的時候會調用smp_mb invalide其他忙等待的CPU的L1 cache，這樣后果就是釋放spin lock的那個cpu可以更快的訪問L1cache，操作lock數據，從而大大增加的下一次獲取該spin lock的機會。
2、回到現在：arch_spinlock_t
ARM平臺中的arch_spinlock_t定義如下（little endian）：
typedef struct {
union {
u32 slock;
struct __raw_tickets {
u16 owner;
u16 next;
} tickets;
};
} arch_spinlock_t;
本來以為一個簡單的整數類型的變量就搞定的spin lock看起來沒有那么簡單，要理解這個數據結構，需要了解一些ticket-based spin lock的概念。如果你有機會去九毛九去排隊吃飯（聲明：不是九毛九的飯托，僅僅是喜歡面食而常去吃而已）就會理解ticket-based spin lock。大概是因為便宜，每次去九毛九總是無法長驅直入，門口的笑容可掬的靚女會給一個ticket，上面寫著15號，同時會告訴你，當前狀態是10號已經入席，11號在等待。
回到arch_spinlock_t，這里的owner就是當前已經入席的那個號碼，next記錄的是下一個要分發的號碼。下面的描述使用普通的計算機語言和在九毛九就餐（假設九毛九只有一張餐桌）的例子來進行描述，估計可以讓吃貨更有興趣閱讀下去。最開始的時候，slock被賦值為0，也就是說owner和next都是0，owner和next相等，表示unlocked。當第一個個thread調用spin_lock來申請lock（第一個人就餐）的時候，owner和next相等，表示unlocked，這時候該thread持有該spin lock（可以擁有九毛九的唯一的那個餐桌），并且執行next++，也就是將next設定為1（再來人就分配1這個號碼讓他等待就餐）。也許該thread執行很快（吃飯吃的快），沒有其他thread來競爭就調用spin_unlock了（無人等待就餐，生意慘淡啊），這時候執行owner++，也就是將owner設定為1（表示當前持有1這個號碼牌的人可以就餐）。姍姍來遲的1號獲得了直接就餐的機會，next++之后等于2。1號這個家伙吃飯巨慢，這是不文明現象（thread不能持有spin lock太久），但是存在。又來一個人就餐，分配當前next值的號碼2，當然也會執行next++，以便下一個人或者3的號碼牌。持續來人就會分配3、4、5、6這些號碼牌，next值不斷的增加，但是owner巋然不動，直到欠扁的1號吃飯完畢（調用spin_unlock），釋放飯桌這個唯一資源，owner++之后等于2，表示持有2那個號碼牌的人可以進入就餐了。?
3、ARM 結構體系?arch_spin_lock?接口實現
3.1 加鎖
同樣的，這里也只是選擇一個典型的API來分析，其他的大家可以自行學習。我們選擇的是 arch_spin_lock，其ARM32的代碼如下：
static inline void arch_spin_lock(arch_spinlock_t *lock)
{
unsigned long tmp;
u32 newval;
arch_spinlock_t lockval;
prefetchw(&lock->slock);－－－－－－－－－－－－－－－－－－－－－－－－（0）
__asm__ __volatile__(
"1: ldrex %0, [%3]\n"－－－－－－－－－－－－－－－－－－－－－－－－－（1）
" add %1, %0, %4\n" －－－－－－－－－－－－－－－－－－－－－－－－－－（2）
" strex %2, %1, [%3]\n"－－－－－－－－－－－－－－－－－－－－－－－－（3）
" teq %2, #0\n"－－－－－－－－－－－－－－－－－－－－－－－－－－－－（4）
" bne 1b"
: "=&r" (lockval), "=&r" (newval), "=&r" (tmp)
: "r" (&lock->slock), "I" (1 << TICKET_SHIFT)
: "cc");
while (lockval.tickets.next != lockval.tickets.owner) {－－－－－－－（5）
wfe();－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－（6）
lockval.tickets.owner = ACCESS_ONCE(lock->tickets.owner);－－－－（7）
}
smp_mb();－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－（8）
}
（0）和preloading cache相關的操作，主要是為了性能考慮
（1）lockval =?lock->slock (如果lock->slock沒有被其他處理器獨占，則標記當前執行處理器對lock->slock地址的獨占訪問；否則不影響)
（2）newval =?lockval + (1 << TICKET_SHIFT)
（3）strex tmp, newval, [&lock->slock] (如果當前執行處理器沒有獨占lock->slock地址的訪問，不進行存儲，返回1給temp；如果當前處理器已經獨占lock->slock內存訪問，則對內存進行寫，返回0給temp，清除獨占標記) lock->tickets.next = lock->tickets.next + 1
（4）檢查是否寫入成功 lockval.tickets.next
（5）初始化時lock->tickets.owner、lock->tickets.next都為0，假設第一次執行arch_spin_lock，lockval = *lock，lock->tickets.next++，lockval.tickets.next 等于 lockval.tickets.owner，獲取到自旋鎖；自旋鎖未釋放，第二次執行的時候，lock->tickets.owner = 0, lock->tickets.next = 1，拷貝到lockval后，lockval.tickets.next != lockval.tickets.owner，會執行wfe等待被自旋鎖釋放被喚醒，自旋鎖釋放時會執行 lock->tickets.owner++，lockval.tickets.owner重新賦值
（6）暫時中斷掛起執行。如果當前spin lock的狀態是locked，那么調用wfe進入等待狀態。更具體的細節請參考ARM WFI和WFE指令中的描述。
（7）其他的CPU喚醒了本cpu的執行，說明owner發生了變化，該新的own賦給lockval，然后繼續判斷spin lock的狀態，也就是回到step 5。
（8）memory barrier的操作，具體可以參考memory barrier中的描述。
3.1 釋放鎖
static inline void arch_spin_unlock(arch_spinlock_t *lock)
{
smp_mb();
lock->tickets.owner++; ---------------------- (0)
dsb_sev(); ---------------------------------- (1)
}
（0）lock->tickets.owner增加1，下一個被喚醒的處理器會檢查該值是否與自己的lockval.tickets.next相等，lock->tickets.owner代表可以獲取的自旋鎖的處理器，lock->tickets.next你一個可以獲取的自旋鎖的owner；處理器獲取自旋鎖時，會先讀取lock->tickets.next用于與lock->tickets.owner比較并且對lock->tickets.next加1，下一個處理器獲取到的lock->tickets.next就與當前處理器不一致了，兩個處理器都與lock->tickets.owner比較，肯定只有一個處理器會相等，自旋鎖釋放時時對lock->tickets.owner加1計算，因此，先申請自旋鎖多處理器lock->tickets.next值更新，自然先獲取到自旋鎖
（1）執行sev指令，喚醒wfe等待的處理器
自旋鎖的變體
| 接口API的類型 | spinlock中的定義 | raw_spinlock的定義 |
| 定義spin lock并初始化 | DEFINE_SPINLOCK | DEFINE_RAW_SPINLOCK |
| 動態初始化spin lock | spin_lock_init | raw_spin_lock_init |
| 獲取指定的spin lock | spin_lock | raw_spin_lock |
| 獲取指定的spin lock同時disable本CPU中斷 | spin_lock_irq | raw_spin_lock_irq |
| 保存本CPU當前的irq狀態，disable本CPU中斷并獲取指定的spin lock | spin_lock_irqsave | raw_spin_lock_irqsave |
| 獲取指定的spin lock同時disable本CPU的bottom half | spin_lock_bh | raw_spin_lock_bh |
| 釋放指定的spin lock | spin_unlock | raw_spin_unlock |
| 釋放指定的spin lock同時enable本CPU中斷 | spin_unlock_irq | raw_spin_unock_irq |
| 釋放指定的spin lock同時恢復本CPU的中斷狀態 | spin_unlock_irqstore | raw_spin_unlock_irqstore |
| 獲取指定的spin lock同時enable本CPU的bottom half | spin_unlock_bh | raw_spin_unlock_bh |
| 嘗試去獲取spin lock，如果失敗，不會spin，而是返回非零值 | spin_trylock | raw_spin_trylock |
| 判斷spin lock是否是locked，如果其他的thread已經獲取了該lock，那么返回非零值，否則返回0 | spin_is_locked | raw_spin_is_locked |
static inline unsigned long __raw_spin_lock_irqsave(raw_spinlock_t *lock)
{
unsigned long flags;
local_irq_save(flags);
preempt_disable();
spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
/*
* On lockdep we dont want the hand-coded irq-enable of
* do_raw_spin_lock_flags() code, because lockdep assumes
* that interrupts are not re-enabled during lock-acquire:
*/
#ifdef CONFIG_LOCKDEP
LOCK_CONTENDED(lock, do_raw_spin_trylock, do_raw_spin_lock);
#else
do_raw_spin_lock_flags(lock, &flags);
#endif
return flags;
}
static inline void __raw_spin_lock_irq(raw_spinlock_t *lock)
{
local_irq_disable();
preempt_disable();
spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
LOCK_CONTENDED(lock, do_raw_spin_trylock, do_raw_spin_lock);
}
static inline void __raw_spin_lock_bh(raw_spinlock_t *lock)
{
local_bh_disable();
preempt_disable();
spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
LOCK_CONTENDED(lock, do_raw_spin_trylock, do_raw_spin_lock);
}
static inline void __raw_spin_lock(raw_spinlock_t *lock)
{
preempt_disable();
spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
LOCK_CONTENDED(lock, do_raw_spin_trylock, do_raw_spin_lock);
}
#endif /* CONFIG_PREEMPT */
static inline void __raw_spin_unlock(raw_spinlock_t *lock)
{
spin_release(&lock->dep_map, 1, _RET_IP_);
do_raw_spin_unlock(lock);
preempt_enable();
}
static inline void __raw_spin_unlock_irqrestore(raw_spinlock_t *lock,
unsigned long flags)
{
spin_release(&lock->dep_map, 1, _RET_IP_);
do_raw_spin_unlock(lock);
local_irq_restore(flags);
preempt_enable();
}
static inline void __raw_spin_unlock_irq(raw_spinlock_t *lock)
{
spin_release(&lock->dep_map, 1, _RET_IP_);
do_raw_spin_unlock(lock);
local_irq_enable();
preempt_enable();
}
static inline void __raw_spin_unlock_bh(raw_spinlock_t *lock)
{
spin_release(&lock->dep_map, 1, _RET_IP_);
do_raw_spin_unlock(lock);
preempt_enable_no_resched();
local_bh_enable_ip((unsigned long)__builtin_return_address(0));
}
static inline int __raw_spin_trylock_bh(raw_spinlock_t *lock)
{
local_bh_disable();
preempt_disable();
if (do_raw_spin_trylock(lock)) {
spin_acquire(&lock->dep_map, 0, 1, _RET_IP_);
return 1;
}
preempt_enable_no_resched();
local_bh_enable_ip((unsigned long)__builtin_return_address(0));
return 0;
}
?
小結
spin_lock 的時候，禁止內核搶占
如果涉及到中斷上下文的訪問，spin lock需要和禁止本 CPU 上的中斷聯合使用（spin_lock_irqsave?/?spin_unlock_irqstore）
涉及 half bottom 使用：spin_lock_bh /?spin_unlock_bh
總結
以上是生活随笔為你收集整理的自旋锁使用场景和实现分析（转载）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 微信实现Java
- 下一篇： 静态路由，缺省路由和默认网关的区别