自旋鎖

---

內核當發生訪問資源沖突的時候，可以有兩種鎖的解決方案選擇：

• 一個是原地等待
• 一個是掛起當前進程，調度其他進程執行（睡眠）

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:? linux/spinlock_types.h:? linux/spinlock_up.h:? linux/spinlock_api_up.h:? linux/spinlock.h	asm/spinlock_types.h? linux/spinlock_types.h:? asm/spinlock.h? linux/spinlock_api_smp.h:? linux/spinlock.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

?

參考文檔：

---

http://www.wowotech.net/kernel_synchronization/spinlock.html

https://blog.csdn.net/arm7star/article/details/77092650

總結

以上是生活随笔為你收集整理的Linux 内核同步（二）：自旋锁（Spinlock）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。