關於linux核心中多進程(線程)間同步和互斥

來源:互聯網
上載者:User
Linux裝置驅動中必須解決的一個問題是多個進程對共用資源的並發訪問,並發訪問會導致競態,linux提供了多種解決競態問題的方式,這些方式適合不同的應用情境。

Linux核心是多進程、多線程的作業系統,它提供了相當完整的核心同步方法。核心同步方法列表如下:
中斷屏蔽
原子操作
自旋鎖
讀寫自旋鎖
順序鎖
訊號量
讀寫訊號量
BKL(大核心鎖)
Seq鎖
一、並發與競態:
定義:
並發(concurrency)指的是多個執行單元同時、並行被執行,而並發的執行單元對共用資源(硬體資源和軟體上的全域變數、靜態變數等)的訪問則很容易導致競態(race conditions)。
在linux中,主要的競態發生在如下幾種情況:
1、對稱式多處理器(SMP)多個CPU
特點是多個CPU使用共同的系統匯流排,因此可訪問共同的外設和儲存空間。
2、單CPU內進程與搶佔它的進程
3、中斷(硬中斷、非強制中斷、Tasklet、底半部)與進程之間
只要並發的多個執行單元存在對共用資源的訪問,競態就有可能發生。
如果中斷處理常式訪問進程正在訪問的資源,則競態也會會發生。
多個中斷之間本身也可能引起並發而導致競態(中斷被更高優先順序的中斷打斷)。

解決競態問題的途徑是保證對共用資源的互斥訪問,所謂互斥訪問就是指一個執行單元在訪問共用資源的時候,其他的執行單元都被禁止訪問。

訪問共用資源的代碼地區被稱為臨界區,臨界區需要以某種互斥機制加以保護,中斷屏蔽,原子操作,自旋鎖,和訊號量都是linux裝置驅動中可採用的互斥途徑。

臨界區和競爭條件:
所謂臨界區(critical regions)就是訪問和操作共用資料的程式碼片段,為了避免在臨界區中並發訪問,編程者必須保證這些代碼原子地執行——也就是說,代碼在執行結束前不可被打斷,就如同整個臨界區是一個不可分割的指令一樣,如果兩個執行線程有可能處於同一個臨界區中,那麼就是程式包含一個bug,如果這種情況發生了,我們就稱之為競爭條件(race conditions),避免並發和防止競爭條件被稱為同步。

死結:
死結的產生需要一定條件:要有一個或多個執行線程和一個或多個資源,每個線程都在等待其中的一個資源,但所有的資源都已經被佔用了,所有線程都在相互等待,但它們永遠不會釋放已經佔有的資源,於是任何線程都無法繼續,這便意味著死結的發生。

二、中斷屏蔽
在單CPU範圍內避免競態的一種簡單方法是在進入臨界區之前屏蔽系統的中斷。
由於linux核心的進程調度等操作都依賴中斷來實現,核心搶佔進程之間的並發也就得以避免了。
中斷屏蔽的使用方法:
local_irq_disable()//屏蔽中斷
//臨界區
local_irq_enable()//開中斷
特點:
由於linux系統的非同步IO,進程調度等很多重要操作都依賴於中斷,在屏蔽中斷期間所有的中斷都無法得到處理,因此長時間的屏蔽是很危險的,有可能造成資料丟失甚至系統崩潰,這就要求在屏蔽中斷之後,當前的核心執行路徑應當儘快地執行完臨界區的代碼。
中斷屏蔽只能禁止本CPU內的中斷,因此,並不能解決多CPU引發的競態,所以單獨使用中斷屏蔽並不是一個值得推薦的避免競態的方法,它一般和自旋鎖配合使用。

三、原子操作
定義:原子操作指的是在執行過程中不會被別的代碼路徑所中斷的操作。
(原子原本指的是不可分割的微粒,所以原子操作也就是不能夠被分割的指令)
(它保證指令以“原子”的方式執行而不能被打斷)
原子操作是不可分割的,在執行完畢不會被任何其它任務或事件中斷。在單一處理器系統(UniProcessor)中,能夠在單條指令中完成的操作都可以認為是" 原子操作",因為中斷只能發生於指令之間。這也是某些CPU指令系統中引入了test_and_set、test_and_clear等指令用於臨界資源互斥的原因。但是,在對稱式多處理器(Symmetric Multi-Processor)結構中就不同了,由於系統中有多個處理器在獨立地運行,即使能在單條指令中完成的操作也有可能受到幹擾。我們以decl (遞減指令)為例,這是一個典型的"讀-改-寫"過程,涉及兩次記憶體訪問。
通俗理解:
原子操作,顧名思義,就是說像原子一樣不可再細分。一個操作是原子操作,意思就是說這個操作是以原子的方式被執行,要一口氣執行完,執行過程不能夠被OS的其他行為打斷,是一個整體的過程,在其執行過程中,OS的其它行為是插不進來的。
分類:linux核心提供了一系列函數來實現核心中的原子操作,分為整型原子操作和位原子操作,共同點是:在任何情況下操作都是原子的,核心代碼可以安全的調用它們而不被打斷。

原子整數操作:
針對整數的原子操作只能對atomic_t類型的資料進行處理,在這裡之所以引入了一個特殊的資料類型,而沒有直接使用C語言的int型,主要是出於兩個原因:
第一、讓原子函數只接受atomic_t類型的運算元,可以確保原子操作只與這種特殊類型資料一起使用,同時,這也確保了該類型的資料不會被傳遞給其它任何非原子函數;
第二、使用atomic_t類型確保編譯器不對相應的值進行訪問最佳化——這點使得原子操作最終接收到正確的記憶體位址,而不是一個別名,最後就是在不同體繫結構上實現原子操作的時候,使用atomic_t可以屏蔽其間的差異。
原子整數操作最常見的用途就是實現計數器。
另一點需要說明原子操作只能保證操作是原子的,要麼完成,要麼不完成,不會有操作一半的可能,但原子操作並不能保證操作的順序性,即它不能保證兩個操作是按某個順序完成的。如果要保證原子操作的順序性,請使用記憶體屏障指令。
atomic_t和ATOMIC_INIT(i)定義
typedef struct { volatile int counter; } atomic_t;
#define ATOMIC_INIT(i) { (i) }

在你編寫代碼的時候,能使用原子操作的時候,就盡量不要使用複雜的加鎖機制,對多數體繫結構來講,原子操作與更複雜的同步方法相比較,給系統帶來的開銷小,對快取行的影響也小,但是,對於那些有高效能要求的代碼,對多種同步方法進行測試比較,不失為一種明智的作法。

原子位操作:
針對位這一級資料進行操作的函數,是對普通的記憶體位址進行操作的。它的參數是一個指標和一個位號。

為方便其間,核心還提供了一組與上述操作對應的非原子位函數,非原子位函數與原子位函數的操作完全相同,但是,前者不保證原子性,且其名字首碼多兩個底線。例如,與test_bit()對應的非原子形式是_test_bit(),如果你不需要原子性操作(比如,如果你已經用鎖保護了自己的資料),那麼這些非原子的位函數相比原子的位函數可能會執行得更快些。

四、自旋鎖
自旋鎖的引入:
如 果每個臨界區都能像增加變數這樣簡單就好了,可惜現實不是這樣,而是臨界區可以跨越多個函數,例如:先得從一個資料結果中移出資料,對其進行格式轉換和解 析,最後再把它加入到另一個資料結構中,整個執行過程必須是原子的,在資料被更新完畢之前,不能有其他代碼讀取這些資料,顯然,簡單的原子操作是無能為力 的(在單一處理器系統(UniProcessor)中,能夠在單條指令中完成的操作都可以認為是" 原子操作",因為中斷只能發生於指令之間),這就需要使用更為複雜的同步方法——鎖來提供保護。

自旋鎖的介紹:
Linux核心中最常見的鎖是自旋鎖(spin lock),自旋鎖最多隻能被一個可執行線程持有,如果一個執行線程試圖獲得一個被爭用(已經被持有)的自旋鎖,那麼該線程就會一直進行忙迴圈—旋轉—等待鎖重新可用,要是鎖未被爭用,請求鎖的執行線程便能立刻得到它,繼續執行,在任意時間,自旋鎖都可以防止多於一個的執行線程同時進入理解區,注意同一個鎖可以用在多個位置—例如,對於給定資料的所有訪問都可以得到保護和同步。
一個被爭用的自旋鎖使得請求它的線程在等待鎖重新可用時自旋(特別浪費處理器時間),所以自旋鎖不應該被長時間持有,事實上,這點正是使用自旋鎖的初衷,在短期間內進行輕量級加鎖,還可以採取另外的方式來處理對鎖的爭用:讓請求線程睡眠,直到鎖重新可用時再喚醒它,這樣處理器就不必迴圈等待,可以去執行其他代碼,這也會帶來一定的開銷——這裡有兩次明顯的環境切換, 被阻塞的線程要換出和換入。因此,持有自旋鎖的時間最好小於完成兩次環境切換的耗時,當然我們大多數人不會無聊到去測量環境切換的耗時,所以我們讓持 有自旋鎖的時間應儘可能的短就可以了,訊號量可以提供上述第二種機制,它使得在發生爭用時,等待的線程能投入睡眠,而不是旋轉。
自旋鎖可以使用在中斷處理常式中(此處不能使用訊號量,因為它們會導致睡眠),在中斷處理常式中使用自旋鎖時,一定要在擷取鎖之前,首先禁止本地中斷(在 當前處理器上的插斷要求),否則,中斷處理常式就會打斷正持有鎖的核心代碼,有可能會試圖去爭用這個已經持有的自旋鎖,這樣以來,中斷處理常式就會自旋, 等待該鎖重新可用,但是鎖的持有人在這個中斷處理常式執行完畢前不可能運行,這正是我們在前一章節中提到的雙重請求死結,注意,需要關閉的只是當前處理器上的中斷,如果中斷髮生在不同的處理器上,即使中斷處理常式在同一鎖上自旋,也不會妨礙鎖的持有人(在不同處理器上)最終釋放鎖。

自旋鎖的簡單理解:
理解自旋鎖最簡單的方法是把它作為一個變數看待,該變數把一個臨界區或者標記為“我當前正在運行,請稍等一會”或者標記為“我當前不在運行,可以被使用”。如果A執行單元首先進入常式,它將持有自旋鎖,當B執行單元試圖進入同一個常式時,將獲知自旋鎖已被持有,需等到A執行單元釋放後才能進入。

自旋鎖的API函數:

其實介紹的幾種訊號量和互斥機制,其底層源碼都是使用自旋鎖,可以理解為自旋鎖的再封裝。所以從這裡就可以理解為什麼自旋鎖通常可以提供比訊號量更高的效能。
自旋鎖是一個互斥裝置,他只能會兩個值:“鎖定”和“解鎖”。它通常實現為某個整數之中的單個位。
“測試並設定”的操作必須以原子方式完成。
任何時候,只要核心代碼擁有自旋鎖,在相關CPU上的搶佔就會被禁止。
適用於自旋鎖的核心規則:
(1)任何擁有自旋鎖的代碼都必須使原子的,除服務中斷外(某些情況下也不能放棄CPU,如中斷服務也要獲得自旋鎖。為了避免這種鎖陷阱,需要在擁有自旋鎖時禁止中斷),不能放棄CPU(如休眠,休眠可發生在許多無法預期的地方)。否則CPU將有可能永遠自旋下去(死機)。
(2)擁有自旋鎖的時間越短越好。

需 要強調的是,自旋鎖別設計用於多處理器的同步機制,對於單一處理器(對於單一處理器並且不可搶佔的核心來說,自旋鎖什麼也不作),核心在編譯時間不會引入自旋鎖 機制,對於可搶佔的核心,它僅僅被用於設定核心的搶佔機制是否開啟的一個開關,也就是說加鎖和解鎖實際變成了禁止或開啟核心搶佔功能。如果核心不支援搶 占,那麼自旋鎖根本就不會編譯到核心中。
核心中使用spinlock_t類型來表示自旋鎖,它定義在<linux/spinlock_types.h>:
typedef struct {
raw_spinlock_t raw_lock;
#if defined(CONFIG_PREEMPT) && defined(CONFIG_SMP)
unsigned int break_lock;
#endif
} spinlock_t;

對於不支援SMP的核心來說,struct raw_spinlock_t什麼也沒有,是一個空結構。對於支援多處理器的核心來說,struct raw_spinlock_t定義為
typedef struct {
unsigned int slock;
} raw_spinlock_t;

slock表示了自旋鎖的狀態,“1”表示自旋鎖處於解鎖狀態(UNLOCK),“0”表示自旋鎖處於上鎖狀態(LOCKED)。
break_lock表示當前是否由進程在等待自旋鎖,顯然,它只有在支援搶佔的SMP核心上才起作用。
自旋鎖的實現是一個複雜的過程,說它複雜不是因為需要多少代碼或邏輯來實現它,其實它的實現代碼很少。自旋鎖的實現跟體繫結構關係密切,核心代碼基本也是由組合語言寫成,與體協結構相關的核心代碼都放在相關的<asm/>目錄下,比如<asm/spinlock.h>。對於我們驅動程式開發人員來說,我們沒有必要瞭解這麼spinlock的內部細節,如果你對它感興趣,請參考閱讀Linux核心原始碼。對於我們驅動的spinlock介面,我們只需包括<linux/spinlock.h>標頭檔。在我們詳細的介紹spinlock的API之前,我們先來看看自旋鎖的一個基本使用格式:
#include <linux/spinlock.h>
spinlock_t lock = SPIN_LOCK_UNLOCKED;

spin_lock(&lock);
....
spin_unlock(&lock);

從使用上來說,spinlock的API還很簡單的,一般我們會用的的API如下表,其實它們都是定義在<linux/spinlock.h>中的宏介面,真正的實現在<asm/spinlock.h>中
#include <linux/spinlock.h>
SPIN_LOCK_UNLOCKED
DEFINE_SPINLOCK
spin_lock_init( spinlock_t *)
spin_lock(spinlock_t *)
spin_unlock(spinlock_t *)
spin_lock_irq(spinlock_t *)
spin_unlock_irq(spinlock_t *)
spin_lock_irqsace(spinlock_t *,unsigned long flags)
spin_unlock_irqsace(spinlock_t *, unsigned long flags)
spin_trylock(spinlock_t *)
spin_is_locked(spinlock_t *)

•         初始化
spinlock有兩種初始化形式,一種是靜態初始化,一種是動態初始化。對於靜態spinlock對象,我們用 SPIN_LOCK_UNLOCKED來初始化,它是一個宏。當然,我們也可以把聲明spinlock和初始化它放在一起做,這就是 DEFINE_SPINLOCK宏的工作,因此,下面的兩行代碼是等價的。
DEFINE_SPINLOCK (lock);
spinlock_t lock = SPIN_LOCK_UNLOCKED;

spin_lock_init 函數一般用來初始化動態建立的spinlock_t對象,它的參數是一個指向spinlock_t對象的指標。當然,它也可以初始化一個靜態沒有初始化的spinlock_t對象。
spinlock_t *lock
......
spin_lock_init(lock);

•         擷取鎖
核心提供了三個函數用於擷取一個自旋鎖。
spin_lock:擷取指定的自旋鎖。
spin_lock_irq:禁止本地中斷並擷取自旋鎖。
spin_lock_irqsace:儲存本地中斷狀態,禁止本地中斷並擷取自旋鎖,返回本地中斷狀態。

自旋鎖是可以使用在中斷處理常式中的,這時需要使用具有關閉本地中斷功能的函數,我們推薦使用 spin_lock_irqsave,因為它會儲存加鎖前的中斷標誌,這樣就會正確恢複解鎖時的中斷標誌。如果spin_lock_irq在加鎖時中斷是關閉的,那麼在解鎖時就會錯誤的開啟中斷。

另外兩個同自旋鎖擷取相關的函數是:
spin_trylock():嘗試擷取自旋鎖,如果擷取失敗則立即返回非0值,否則返回0。
spin_is_locked():判斷指定的自旋鎖是否已經被擷取了。如果是則返回非0,否則,返回0。
•         釋放鎖
同擷取鎖相對應,核心提供了三個相對的函數來釋放自旋鎖。
spin_unlock:釋放指定的自旋鎖。
spin_unlock_irq:釋放自旋鎖並啟用本地中斷。
spin_unlock_irqsave:釋放自旋鎖,並恢複儲存的本地中斷狀態。

五、讀寫自旋鎖
如 果臨界區保護的資料是可讀可寫的,那麼只要沒有寫操作,對於讀是可以支援並行作業的。對於這種只要求寫操作是互斥的需求,如果還是使用自旋鎖顯然是無法滿 足這個要求(對於讀操作實在是太浪費了)。為此核心提供了另一種鎖-讀寫自旋鎖,讀自旋鎖也叫共用自旋鎖,寫自旋鎖也叫排他自旋鎖。
讀寫自旋鎖是一種比自旋鎖粒度更小的鎖機制,它保留了“自旋”的概念,但是在寫操作方面,只能最多有一個寫進程,在讀操作方面,同時可以有多個讀執行單元,當然,讀和寫也不能同時進行。
讀寫自旋鎖的使用也普通自旋鎖的使用很類似,首先要初始化讀寫自旋鎖對象:
// 靜態初始化
rwlock_t rwlock = RW_LOCK_UNLOCKED;
//動態初始化
rwlock_t *rwlock;
...
rw_lock_init(rwlock);

在讀作業碼裡對共用資料擷取讀自旋鎖:
read_lock(&rwlock);
...
read_unlock(&rwlock);

在寫作業碼裡為共用資料擷取寫自旋鎖:
write_lock(&rwlock);
...
write_unlock(&rwlock);

需要注意的是,如果有大量的寫操作,會使寫操作自旋在寫自旋鎖上而處於寫饑餓狀態(等待讀自旋鎖的全部釋放),因為讀自旋鎖會自由的擷取讀自旋鎖。

讀寫自旋鎖的函數類似於普通自旋鎖,這裡就不一一介紹了,我們把它列在下面的表中。
RW_LOCK_UNLOCKED
rw_lock_init(rwlock_t *)
read_lock(rwlock_t *)
read_unlock(rwlock_t *)
read_lock_irq(rwlock_t *)
read_unlock_irq(rwlock_t *)
read_lock_irqsave(rwlock_t *, unsigned long)
read_unlock_irqsave(rwlock_t *, unsigned long)
write_lock(rwlock_t *)
write_unlock(rwlock_t *)
write_lock_irq(rwlock_t *)
write_unlock_irq(rwlock_t *)
write_lock_irqsave(rwlock_t *, unsigned long)
write_unlock_irqsave(rwlock_t *, unsigned long)
rw_is_locked(rwlock_t *)
六、順序瑣
順序瑣(seqlock)是對讀寫鎖的一種最佳化,若使用順序瑣,讀執行單元絕不會被寫執行單元阻塞,也就是說,讀執行單元可以在寫執行單元對被順序瑣保護的共用資源進行寫操作時仍然可以繼續讀,而不必等待寫執行單元完成寫操作,寫執行單元也不需要等待所有讀執行單元完成讀操作才去進行寫操作。
但是,寫執行單元與寫執行單元之間仍然是互斥的,即如果有寫執行單元在進行寫操作,其它寫執行單元必須自旋在哪裡,直到寫執行單元釋放了順序瑣。
如果讀執行單元在讀操作期間,寫執行單元已經發生了寫操作,那麼,讀執行單元必須重新讀取資料,以便確保得到的資料是完整的,這種鎖在讀寫同時進行的機率比較小時,效能是非常好的,而且它允許讀寫同時進行,因而更大的提高了並發性,
注意,順序瑣由一個限制,就是它必須被保護的共用資源不含有指標,因為寫執行單元可能使得指標失效,但讀執行單元如果正要訪問該指標,將導致Oops。
七、訊號量
Linux中的訊號量是一種睡眠鎖,如果有一個任務試圖獲得一個已經被佔用的訊號量時,訊號量會將其推進一個等待隊列,然後讓其睡眠,這時處理器能重獲自由,從而去執行其它代碼,當持有訊號量的進程將訊號量釋放後,處於等待隊列中的哪個任務被喚醒,並獲得該訊號量。
訊號量,或旗標,就是我們在作業系統裡學習的經典的P/V原語操作。
P:如果訊號量值大於0,則遞減訊號量的值,程式繼續執行,否則,睡眠等待訊號量大於0。
V:遞增訊號量的值,如果遞增的訊號量的值大於0,則喚醒等待的進程。

訊號量的值確定了同時可以有多少個進程可以同時進入臨界區,如果訊號量的初始值始1,這訊號量就是互斥訊號量(MUTEX)。對於大於1的非0值訊號量,也可稱為計數訊號量(counting semaphore)。對於一般的驅動程式使用的訊號量都是互斥訊號量。
類似於自旋鎖,訊號量的實現也與體繫結構密切相關,具體的實現定義在<asm/semaphore.h>標頭檔中,對於x86_32系統來說,它的定義如下:
struct semaphore {
atomic_t count;
int sleepers;
wait_queue_head_t wait;
};

訊號量的初始值count是atomic_t類型的,這是一個原子操作類型,它也是一個核心同步技術,可見訊號量是基於原子操作的。我們會在後面原子操作部分對原子操作做詳細介紹。

訊號量的使用類似於自旋鎖,包括建立、擷取和釋放。我們還是來先展示訊號量的基本使用形式:
static DECLARE_MUTEX(my_sem);
......
if (down_interruptible(&my_sem))

{
return -ERESTARTSYS;
}
......
up(&my_sem)

Linux核心中的訊號量函數介面如下:
static DECLARE_SEMAPHORE_GENERIC(name, count);
static DECLARE_MUTEX(name);
seam_init(struct semaphore *, int);
init_MUTEX(struct semaphore *);
init_MUTEX_LOCKED(struct semaphore *)
down_interruptible(struct semaphore *);
down(struct semaphore *)
down_trylock(struct semaphore *)
up(struct semaphore *)
•         初始化訊號量
訊號量的初始化包括靜態初始化和動態初始化。靜態初始化用於靜態聲明並初始化訊號量。
static DECLARE_SEMAPHORE_GENERIC(name, count);
static DECLARE_MUTEX(name);

對於動態聲明或建立的訊號量,可以使用如下函數進行初始化:
seam_init(sem, count);
init_MUTEX(sem);
init_MUTEX_LOCKED(struct semaphore *)

顯然,帶有MUTEX的函數始初始化互斥訊號量。LOCKED則初始化訊號量為鎖狀態。
•         使用訊號量
訊號量初始化完成後我們就可以使用它了
down_interruptible(struct semaphore *);
down(struct semaphore *)
down_trylock(struct semaphore *)
up(struct semaphore *)

down函數會嘗試擷取指定的訊號量,如果訊號量已經被使用了,則進程進入不可中斷的睡眠狀態。down_interruptible則會使進程進入可中斷的睡眠狀態。關於進程狀態的詳細細節,我們在核心的進程管理裡在做詳細介紹。

down_trylock嘗試擷取訊號量, 如果擷取成功則返回0,失敗則會立即返回非0。

當退出臨界區時使用up函數釋放訊號量,如果訊號量上的睡眠隊列不為空白,則喚醒其中一個等待進程。

八、讀寫訊號量
類似於自旋鎖,訊號量也有讀寫訊號量。讀寫訊號量API定義在<linux/rwsem.h>標頭檔中,它的定義其實也是體繫結構相關的,因此具體實現定義在<asm/rwsem.h>標頭檔中,以下是x86的例子:
struct rw_semaphore {
signed long        count;
spinlock_t        wait_lock;
struct list_head    wait_list;
};

首先要說明的是所有的讀寫訊號量都是互斥訊號量。讀鎖是共用鎖定,就是同時允許多個讀進程持有該訊號量,但寫鎖是獨佔鎖,同時只能有一個寫鎖持有該互斥訊號量。顯然,寫鎖是排他的,包括排斥讀鎖。由於寫鎖是共用鎖定,它允許多個讀進程持有該鎖,只要沒有進程持有寫鎖,它就始終會成功持有該鎖,因此這會造成寫進程寫饑餓狀態。

在使用讀寫訊號量前先要初始化,就像你所想到的,它在使用上幾乎與讀寫自旋鎖一致。先來看看讀寫訊號量的建立和初始化:
// 靜態初始化
static DECLARE_RWSEM(rwsem_name);

// 動態初始化
static struct rw_semaphore rw_sem;
init_rwsem(&rw_sem);

讀進程擷取訊號量保護臨界區資料:
down_read(&rw_sem);
...
up_read(&rw_sem);

寫進程擷取訊號量保護臨界區資料:
down_write(&rw_sem);
...
up_write(&rw_sem);

更多的讀寫訊號量API請參考下表:
#include <linux/rwsem.h>

DECLARE_RWSET(name);
init_rwsem(struct rw_semaphore *);
void down_read(struct rw_semaphore *sem);
void down_write(struct rw_semaphore *sem);
void up_read(struct rw_semaphore *sem);
int down_read_trylock(struct rw_semaphore *sem);
int down_write_trylock(struct rw_semaphore *sem);
void downgrade_write(struct rw_semaphore *sem);
void up_write(struct rw_semaphore *sem);

同自旋鎖一樣,down_read_trylock和down_write_trylock會嘗試著擷取訊號量,如果擷取成功則返回1,否則返回0。奇怪為什麼傳回值與訊號量的對應函數相反,使用是一定要小心這點。

九、自旋鎖和訊號量區別
在驅動程式中,當多個線程同時訪問相同的資源時(驅動程式中的全域變數是一種典型的共用資源),可能會引發"競態",因此我們必須對共用資源進行並發控制。Linux核心中解決並發控制的最常用方法是自旋鎖與訊號量(絕大多數時候作為互斥鎖使用)。

自旋鎖與訊號量"類似而不類",類似說的是它們功能上的相似性,"不類"指代它們在本質和實現機理上完全不一樣,不屬於一類。

自旋鎖不會引起調用者睡眠,如果自旋鎖已經被別的執行單元保持,調用者就一直迴圈查看是否該自旋鎖的保持者已經釋放了鎖,"自旋"就是"在原地打轉"。而訊號量則引起調用者睡眠,它把進程從運行隊列上拖出去,除非獲得鎖。這就是它們的"不類"。

但是,無論是訊號量,還是自旋鎖,在任何時刻,最多隻能有一個保持者,即在任何時刻最多隻能有一個執行單元獲得鎖。這就是它們的"類似"。

鑒於自旋鎖與訊號量的上述特點,一般而言,自旋鎖適合於保持時間非常短的情況,它可以在任何上下文使用;訊號量適合於保持時間較長的情況,會只能在進程 上下文使用。如果被保護的共用資源只在進程上下文訪問,則可以以訊號量來保護該共用資源,如果對共用資源的訪問時間非常短,自旋鎖也是好的選擇。但是,如 果被保護的共用資源需要在中斷上下文訪問(包括底半部即中斷處理控制代碼和頂半部即非強制中斷),就必須使用自旋鎖。
區別總結如下:
1、由於爭用訊號量的進程在等待鎖重新變為可用時會睡眠,所以訊號量適用於鎖會被長時間持有的情況。
2、相反,鎖被短時間持有時,使用訊號量就不太適宜了,因為睡眠引起的耗時可能比鎖被佔用的全部時間還要長。
3、由於執行線程在鎖被爭用時會睡眠,所以只能在進程上下文中才能擷取訊號量鎖,因為在中斷上下文中(使用自旋鎖)是不能進行調度的。
4、你可以在持有訊號量時去睡眠(當然你也可能並不需要睡眠),因為當其它進程試圖獲得同一訊號量時不會因此而死結,(因為該進程也只是去睡眠而已,而你最終會繼續執行的)。
5、在你佔用訊號量的同時不能佔用自旋鎖,因為在你等待訊號量時可能會睡眠,而在持有自旋鎖時是不允許睡眠的。
6、訊號量鎖保護的臨界區可包含可能引起阻塞的代碼,而自旋鎖則絕對要避免用來保護包含這樣代碼的臨界區,因為阻塞意味著要進行進程的切換,如果進程被切換出去後,另一進程企圖擷取本自旋鎖,死結就會發生。
7、訊號量不同於自旋鎖,它不會禁止核心搶佔(自旋鎖被持有時,核心不能被搶佔),所以持有訊號量的代碼可以被搶佔,這意味著訊號量不會對調度的等待時間帶來負面影響。
除了以上介紹的同步機制方法以外,還有BKL(大核心鎖),Seq鎖等。
BKL是一個全域自旋鎖,使用它主要是為了方便實現從Linux最初的SMP過度到細粒度加鎖機制。
Seq鎖用於讀寫共用資料,實現這樣鎖只要依靠一個序列計數器。

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.