linux的臨界區
① linux內核同步問題
Linux內核設計與實現 十、內核同步方法
手把手教Linux驅動5-自旋鎖、信號量、互斥體概述
== 基礎概念： ==
並發 ：多個執行單元同時進行或多個執行單元微觀串列執行，宏觀並行執行
競態 ：並發的執行單元對共享資源（硬體資源和軟體上的全局變數）的訪問而導致的竟態狀態。
臨界資源 ：多個進程訪問的資源
臨界區 ：多個進程訪問的代碼段
== 並發場合： ==
1、單CPU之間進程間的並發 :時間片輪轉，調度進程。 A進程訪問列印機，時間片用完，OS調度B進程訪問列印機。
2、單cpu上進程和中斷之間並發 ：CPU必須停止當前進程的執行中斷;
3、多cpu之間
4、單CPU上中斷之間的並發
== 使用偏向： ==
==信號量用於進程之間的同步，進程在信號量保護的臨界區代碼裡面是可以睡眠的（需要進行進程調度），這是與自旋鎖最大的區別。==
信號量又稱為信號燈，它是用來協調不同進程間的數據對象的，而最主要的應用是共享內存方式的進程間通信。本質上，信號量是一個計數器，它用來記錄對某個資源（如共享內存）的存取狀況。它負責協調各個進程，以保證他們能夠正確、合理的使用公共資源。它和spin lock最大的不同之處就是：無法獲取信號量的進程可以睡眠，因此會導致系統調度。
1、==用於進程與進程之間的同步==
2、==允許多個進程進入臨界區代碼執行，臨界區代碼允許睡眠；==
3、信號量本質是==基於調度器的==，在UP和SMP下沒有區別；進程獲取不到信號量將陷入休眠，並讓出CPU；
4、不支持進程和中斷之間的同步
5、==進程調度也是會消耗系統資源的，如果一個int型共享變數就需要使用信號量，將極大的浪費系統資源==
6、信號量可以用於多個線程，用於資源的計數（有多種狀態）
==信號量加鎖以及解鎖過程：==
sema_init(&sp->dead_sem, 0); / 初始化 /
down(&sema);
臨界區代碼
up(&sema);
==信號量定義：==
==信號量初始化：==
==dowm函數實現：==
==up函數實現：==
信號量一般可以用來標記可用資源的個數。
舉2個生活中的例子：
==dowm函數實現原理解析：==
（1）down
判斷sem->count是否 > 0，大於0則說明系統資源夠用，分配一個給該進程，否則進入__down(sem);
（2）__down
調用__down_common(sem, TASK_UNINTERRUPTIBLE, MAX_SCHEDULE_TIMEOUT);其中TASK_UNINTERRUPTIBLE=2代表進入睡眠，且不可以打斷；MAX_SCHEDULE_TIMEOUT休眠最長LONG_MAX時間；
（3）list_add_tail(&waiter.list, &sem->wait_list);
把當前進程加入到sem->wait_list中；
（3）先解鎖後加鎖;
進入__down_common前已經加鎖了，先把解鎖，調用schele_timeout(timeout)，當waiter.up=1後跳出for循環；退出函數之前再加鎖；
Linux內核ARM構架中原子變數的底層實現研究
rk3288 原子操作和原子位操作
原子變數適用於只共享一個int型變數；
1、原子操作是指不被打斷的操作，即它是最小的執行單位。
2、最簡單的原子操作就是一條條的匯編指令(不包括一些偽指令，偽指令會被匯編器解釋成多條匯編指令)
==常見函數：==
==以atomic_inc為例介紹實現過程==
在Linux內核文件archarmincludeasmatomic.h中。 執行atomic_read、atomic_set這些操作都只需要一條匯編指令，所以它們本身就是不可打斷的。 需要特別研究的是atomic_inc、atomic_dec這類讀出、修改、寫回的函數。
所以atomic_add的原型是下面這個宏：
atomic_add等效於：
result（%0） tmp（%1） (v->counter)（%2） (&v->counter)（%3） i（%4）
注意：根據內聯匯編的語法，result、tmp、&v->counter對應的數據都放在了寄存器中操作。如果出現上下文切換，切換機制會做寄存器上下文保護。
（1）ldrex %0, [%3]
意思是將&v->counter指向的數據放入result中，並且（分別在Local monitor和Global monitor中）設置獨占標志。
（2）add %0, %0, %4
result = result + i
（3）strex %1, %0, [%3]
意思是將result保存到&v->counter指向的內存中， 此時 Exclusive monitors會發揮作用，將保存是否成功的標志放入tmp中。
（4） teq %1, #0
測試strex是否成功（tmp == 0 ？？）
（5）bne 1b
如果發現strex失敗，從（1）再次執行。
Spinlock 是內核中提供的一種比較常見的鎖機制，==自旋鎖是「原地等待」的方式解決資源沖突的==，即，一個線程獲取了一個自旋鎖後，另外一個線程期望獲取該自旋鎖，獲取不到，只能夠原地「打轉」（忙等待）。由於自旋鎖的這個忙等待的特性，註定了它使用場景上的限制 —— 自旋鎖不應該被長時間的持有（消耗 CPU 資源），一般應用在==中斷上下文==。
1、spinlock是一種死等機制
2、信號量可以允許多個執行單元進入，spinlock不行，一次只能允許一個執行單元獲取鎖，並且進入臨界區，其他執行單元都是在門口不斷的死等
3、由於不休眠，因此spinlock可以應用在中斷上下文中；
4、由於spinlock死等的特性，因此臨界區執行代碼盡可能的短；
==spinlock加鎖以及解鎖過程：==
spin_lock(&devices_lock);
臨界區代碼
spin_unlock(&devices_lock);
==spinlock初始化==
==進程和進程之間同步==
==本地軟中斷之間同步==
==本地硬中斷之間同步==
==本地硬中斷之間同步並且保存本地中斷狀態==
==嘗試獲取鎖==
== arch_spinlock_t結構體定義如下： ==
== arch_spin_lock的實現如下： ==
lockval（%0） newval（%1） tmp（%2） &lock->slock（%3） 1 << TICKET_SHIFT（%4）
（1）ldrex %0, [%3]
把lock->slock的值賦值給lockval；並且（分別在Local monitor和Global monitor中）設置獨占標志。
（2）add %1, %0, %4
newval =lockval +（1<<16）; 相當於next+1；
（3）strex %2, %1, [%3]
newval =lockval +（1<<16）; 相當於next+1；
意思是將newval保存到 &lock->slock指向的內存中， 此時 Exclusive monitors會發揮作用，將保存是否成功的標志放入tmp中。
（4） teq %2, #0
測試strex是否成功
（5）bne 1b
如果發現strex失敗，從（1）再次執行。
通過上面的分析，可知關鍵在於strex的操作是否成功的判斷上。而這個就歸功於ARM的Exclusive monitors和ldrex/strex指令的機制。
（6）while (lockval.tickets.next != lockval.tickets.owner)
如何lockval.tickets的next和owner是否相等。相同則跳出while循環，否則在循環內等待判斷；
* （7）wfe()和smp_mb() 最終調用#define barrier() asm volatile ("": : :"memory") *
阻止編譯器重排，保證編譯程序時在優化屏障之前的指令不會在優化屏障之後執行。
== arch_spin_unlock的實現如下： ==
退出鎖時：tickets.owner++
== 出現死鎖的情況： ==
1、擁有自旋鎖的進程A在內核態阻塞了，內核調度B進程，碰巧B進程也要獲得自旋鎖，此時B只能自旋轉。 而此時搶占已經關閉，（單核）不會調度A進程了，B永遠自旋，產生死鎖。
2、進程A擁有自旋鎖，中斷到來，CPU執行中斷函數，中斷處理函數，中斷處理函數需要獲得自旋鎖，訪問共享資源，此時無法獲得鎖，只能自旋，產生死鎖。
== 如何避免死鎖： ==
1、如果中斷處理函數中也要獲得自旋鎖，那麼驅動程序需要在擁有自旋鎖時禁止中斷；
2、自旋鎖必須在可能的最短時間內擁有
3、避免某個獲得鎖的函數調用其他同樣試圖獲取這個鎖的函數，否則代碼就會死鎖；不論是信號量還是自旋鎖，都不允許鎖擁有者第二次獲得這個鎖，如果試圖這么做，系統將掛起；
4、鎖的順序規則（a) 按同樣的順序獲得鎖；b) 如果必須獲得一個局部鎖和一個屬於內核更中心位置的鎖，則應該首先獲取自己的局部鎖 ;c) 如果我們擁有信號量和自旋鎖的組合，則必須首先獲得信號量；在擁有自旋鎖時調用down(可導致休眠)是個嚴重的錯誤的；）
== rw（read/write）spinlock： ==
加鎖邏輯：
1、假設臨界區內沒有任何的thread，這個時候任何的讀線程和寫線程都可以鍵入
2、假設臨界區內有一個讀線程，這時候信賴的read線程可以任意進入，但是寫線程不能進入；
3、假設臨界區有一個寫線程，這時候任何的讀、寫線程都不可以進入；
4、假設臨界區內有一個或者多個讀線程，寫線程不可以進入臨界區，但是寫線程也無法阻止後續的讀線程繼續進去，要等到臨界區所有的讀線程都結束了，才可以進入，可見：==rw（read/write）spinlock更加有利於讀線程；==
== seqlock（順序鎖）： ==
加鎖邏輯：
1、假設臨界區內沒有任何的thread，這個時候任何的讀線程和寫線程都可以鍵入
2、假設臨界區內沒有寫線程的情況下，read線程可以任意進入；
3、假設臨界區有一個寫線程，這時候任何的讀、寫線程都不可以進入；
4、假設臨界區內只有read線程的情況下，寫線程可以理解執行，不會等待，可見：==seqlock（順序鎖）更加有利於寫線程；==
讀寫速度 ： CPU > 一級緩存 > 二級緩存 > 內存 ，因此某一個CPU0的lock修改了，其他的CPU的lock就會失效；那麼其他CPU就會依次去L1 L2和主存中讀取lock值，一旦其他CPU去讀取了主存，就存在系統性能降低的風險；
mutex用於互斥操作。
互斥體只能用於一個線程，資源只有兩種狀態（佔用或者空閑）
1、mutex的語義相對於信號量要簡單輕便一些，在鎖爭用激烈的測試場景下，mutex比信號量執行速度更快，可擴展
性更好，
2、另外mutex數據結構的定義比信號量小;、
3、同一時刻只有一個線程可以持有mutex
4、不允許遞歸地加鎖和解鎖
5、當進程持有mutex時，進程不可以退出。
• mutex必須使用官方API來初始化。
• mutex可以睡眠，所以不允許在中斷處理程序或者中斷下半部中使用，例如tasklet、定時器等
==常見操作：==
struct mutex mutex_1;
mutex_init(&mutex_1);
mutex_lock(&mutex_1)
臨界區代碼；
mutex_unlock(&mutex_1)
==常見函數：==
=
② Linux進入臨界去開關中斷的幾種方式
進入中斷時候關閉全局的中斷是為了避免程序處理中斷過程中，再進入另一個中斷打亂執行的順序，也就是為了防止中斷嵌套的情況發生。比如在irq_handler函數中首先就應該關閉中斷。或者，在某些操作順序中是不允許中斷發生打斷的情況。例如在驅動中常用的方式：
unsigned int flag;
local_irq_save(&flag);
spin_loc_irqsave 禁止中斷(只在本地處理器)在獲得自旋鎖之前; 之前的中斷狀態保存在 flags 里. 如果你絕對確定在你的處理器上沒有禁止中斷的(或者, 換句話說, 你確信你應當在你釋放你的液陸塵鬧禪自旋鎖時打開中斷)，你可以使用 spin_lock_irq 代替, 並且不必保持跟蹤 flags. 最後, spin_lock_bh 在獲取鎖之前禁止軟體中斷, 但是硬體中斷留作打開的。感覺現在自己對互斥和中斷的悉鉛關系給搞糊塗了，例如出現這樣的情況，在進入臨界區後，發生了一個中斷在進入中斷處理函數中，也需要臨界區的資源，但是它獲得不了，是不是這個中斷處理函數被掛起到等待隊列中呢？還是產生了死鎖呢？
③ Linux內核中的RCU機制
Linux內核中的RCU機制
RCU的設計思想比較明確，通過新老指針替換的方式來實現免鎖方式的共享保護。但是具體到代碼的層面，理解起來多扒岩少還是會有些困難。下面我准備了關於Linux內核中的RCU機制的文章，提供給大家參考!
RCU讀取側進入臨界區的標志是調用rcu_read_lock，這個函數的代碼是：
static inline void rcu_read_lock(void)
{
__rcu_read_lock();
__acquire(RCU);
rcu_read_acquire();
}
該實現裡面貌似有三個函數調用，但實質性的工作由第一個函數__rcu_read_lock()來完成，__rcu_read_lock()通過調用 preempt_disable()關閉內核可搶占性。但是中斷是允許的，假設讀取者正處於rcu臨界區中且剛讀取了一個共享數據區的指針p(但是還沒有訪問p中的數據成員)，發生了一個中斷，而該中斷處理常式ISR恰好需要修改p所指向的數據區，按照RCU的設計原則，ISR會新分配一個同樣大小的數據區new_p，再把老數據區p中的數據拷貝到新數據區，接著是在new_p的基礎上做數據修改的工作(因為是在new_p空間中修改，所以不存在對p的並發訪問，因此說RCU是一種免鎖機制，原因就在這里)，ISR在把數據更新的工作完成後，將new_p賦值給p(p=new_p),最後它會再注冊一個回調函數用以在適當的時候釋放老指針p。因此，只要對老指針p上的所有引用都結束了，釋放p就不會有問題。當中斷處理常式做完這些工作返回後，被中斷的進程將依然訪問到p空間上的數據，蘆滑也就是老數據，這樣的結果是RCU機制所允許的。RCU規則對讀取者與寫入者之間因指針切換所造成的短暫的資源視圖不一致問題是允許的。
接下來關於RCU一個有趣的問題是：何時才能釋放老指針。我見過很多書中對此的'回答是：當系統中所有處理器上都發生了一次進程切換。這種程式化的回答常常讓剛接觸RCU機制的讀者感到一頭霧水，為什麼非要等所有處理器上都發生一次進程切換才可以調用回調函數釋放老指針呢?這其實是RCU的設計規則決定的： 所有對老指針的引用只可能發生在rcu_read_lock與rcu_read_unlock所包括的臨界區中，而在這個臨界區中不可能發生進程切換，而一旦出了該臨界區就不應該再有任何形式的對老指針p的引用。很明顯，這個規則要求讀取者在臨界區中不能發生進程切換，因為一旦有進程切換，釋放老指針的回調函數就有可能被調用，從而導致老指針被釋放掉，當被切換掉的進程被重新調度運行時它就有可能引用到一個被釋放掉的內存空間。
現在我們看到為什麼rcu_read_lock只需要關閉內核可搶占性就可以了，因為它使得即便在臨界區中發生了中斷，當前進程也不可能被切換除去。 內核開發者，確切地說，RCU的設計者所能做的只能到這個程度。接下來就是使用者的責任了，如果在rcu的臨界區中調用了一個函數，該函數可能睡眠，那麼RCU的設計規則就遭到了破壞，系統將進入一種不穩定的狀態。
這再次說明，如果想使用一個東西，一定要搞清楚其內在的機制，象上面剛提到的那個例子，即便現在程序不出現問題，但是系統中留下的隱患如同一個定時炸彈， 隨時可能被引爆，尤其是過了很長時間問題才突然爆發出來。絕大多數情形下，找到問題所花費的時間可能要遠遠大於靜下心來仔細搞懂RCU的原理要多得多。
RCU中的讀取者相對rwlock的讀取者而言，自由度更高。因為RCU的讀取者在訪問一個共享資源時，不需要考慮寫入者的陪此臘感受，這不同於rwlock的寫入者，rwlock reader在讀取共享資源時需要確保沒有寫入者在操作該資源。兩者之間的差異化源自RCU對共享資源在讀取者與寫入者之間進行了分離，而rwlock的 讀取者和寫入者則至始至終只使用共享資源的一份拷貝。這也意味著RCU中的寫入者要承擔更多的責任，而且對同一共享資源進行更新的多個寫入者之間必須引入某種互斥機制，所以RCU屬於一種"免鎖機制"的說法僅限於讀取者與寫入者之間。所以我們看到：RCU機制應該用在有大量的讀取操作，而更新操作相對較少的情形下。此時RCU可以大大提升系統系能，因為RCU的讀取操作相對其他一些有鎖機制而言，在鎖上的開銷幾乎沒有。
實際使用中，共享的資源常常以鏈表的形式存在，內核為RCU模式下的鏈表操作實現了幾個介面函數，讀取者和使用者應該使用這些內核函數，比如 list_add_tail_rcu, list_add_rcu，hlist_replace_rcu等等，具體的使用可以參考某些內核編程或者設備驅動程序方面的資料。
在釋放老指針方面，Linux內核提供兩種方法供使用者使用，一個是調用call_rcu,另一個是調用synchronize_rcu。前者是一種非同步 方式，call_rcu會將釋放老指針的回調函數放入一個結點中，然後將該結點加入到當前正在運行call_rcu的處理器的本地鏈表中，在時鍾中斷的 softirq部分(RCU_SOFTIRQ)， rcu軟中斷處理函數rcu_process_callbacks會檢查當前處理器是否經歷了一個休眠期(quiescent，此處涉及內核進程調度等方面的內容)，rcu的內核代碼實現在確定系統中所有的處理器都經歷過了一個休眠期之後(意味著所有處理器上都發生了一次進程切換，因此老指針此時可以被安全釋放掉了)，將調用call_rcu提供的回調函數。
synchronize_rcu的實現則利用了等待隊列，在它的實現過程中也會向call_rcu那樣向當前處理器的本地鏈表中加入一個結點，與 call_rcu不同之處在於該結點中的回調函數是wakeme_after_rcu，然後synchronize_rcu將在一個等待隊列中睡眠，直到系統中所有處理器都發生了一次進程切換，因而wakeme_after_rcu被rcu_process_callbacks所調用以喚醒睡眠的 synchronize_rcu，被喚醒之後，synchronize_rcu知道它現在可以釋放老指針了。
所以我們看到，call_rcu返回後其注冊的回調函數可能還沒被調用，因而也就意味著老指針還未被釋放，而synchronize_rcu返回後老指針肯定被釋放了。所以，是調用call_rcu還是synchronize_rcu，要視特定需求與當前上下文而定，比如中斷處理的上下文肯定不能使用 synchronize_rcu函數了。 ;
④ 什麼是臨界區
臨界區指的是一個訪問共用資源（例如：共用設備或是共用存儲器）的程序片段，而這些共用資源又無法同時被多個線程訪問的特性。
當有線程進入臨界區段時，其他線程或是進程必須等待（例如：bounded waiting 等待法），有一些同步的機制必須在臨界區段的進入絕帶缺點與離開點實現，以確保這些共用資源是被互斥獲得使用，例如：semaphore。只能被單一線程訪問的設備，例如：列印機。
進程進入臨界區的調度原則是：
1、如果有若干進程要求進入空閑的臨界區，一次僅允許一個進程進入。
2、任何時候，處於臨界區內的進程不可多於一個。如已有進程進入自己的臨界區，則其它所有試圖進入臨界區的進程必須等待。
3、進入臨界行渣區的進程要在有限時間內退出，以便其它進程能及時進入自己的並辯臨界區。
4、如果進程不能進入自己的臨界區，則應讓出CPU，避免進程出現「忙等」現象。
⑤ 一文搞懂 ， Linux內核—— 同步管理（下）
上面講的自旋鎖，信號量和互斥鎖的實現，都是使用了原子操作指令。由於原子操作會 lock，當線程在多個 CPU 上爭搶進入臨界區的時候，都會操作那個在多個 CPU 之間共享的數據 lock。CPU 0 操作了 lock，為了數據的一致性，CPU 0 的操作會導致其他 CPU 的 L1 中的 lock 變成 invalid，在隨後的來自其他 CPU 對 lock 的訪問會導致 L1 cache miss（更准確的說是communication cache miss），必須從下一個 level 的 cache 中獲取。
這就會使緩存一致性變得很糟，導致性能下降。所以內核提供一種新的同步方式：RCU（讀-復制-更新）。
RCU 解決了什麼
RCU 是讀寫鎖的高性能版本，它的核心理念是讀者訪問的同時，寫者可以更新訪問對象的副本，但寫者需要等待所有讀者完成訪問之後，才能刪除老對象。讀者沒有任何同步開銷，而寫者的同步開銷則取決於使用的寫者間同步機制。
RCU 適用於需要頻繁的讀取數據，而相應修改數據並不多的情景，例如在文件系統中，經常需要查找定位目錄，而對目錄的修改相對來說並不多，這就是 RCU 發揮作用的最佳場景。
RCU 例子
RCU 常用的介面如下圖所示：
為了更好的理解，在剖析 RCU 之前先看一個例子：
#include<linux/kernel.h>#include<linux/mole.h>#include<linux/init.h>#include<linux/slab.h>#include<linux/spinlock.h>#include<linux/rcupdate.h>#include<linux/kthread.h>#include<linux/delay.h>structfoo{inta;structrcu_headrcu;};staticstructfoo*g_ptr;staticintmyrcu_reader_thread1(void*data)//讀者線程1{structfoo*p1=NULL;while(1){if(kthread_should_stop())break;msleep(20);rcu_read_lock();mdelay(200);p1=rcu_dereference(g_ptr);if(p1)printk("%s: read a=%d\n",__func__,p1->a);rcu_read_unlock();}return0;}staticintmyrcu_reader_thread2(void*data)//讀者線程2{structfoo*p2=NULL;while(1){if(kthread_should_stop())break;msleep(30);rcu_read_lock();mdelay(100);p2=rcu_dereference(g_ptr);if(p2)printk("%s: read a=%d\n",__func__,p2->a);rcu_read_unlock();}return0;}staticvoidmyrcu_del(structrcu_head*rh)//回收處理操作{structfoo*p=container_of(rh,structfoo,rcu);printk("%s: a=%d\n",__func__,p->a);kfree(p);}staticintmyrcu_writer_thread(void*p)//寫者線程{structfoo*old;structfoo*new_ptr;intvalue=(unsignedlong)p;while(1){if(kthread_should_stop())break;msleep(250);new_ptr=kmalloc(sizeof(structfoo),GFP_KERNEL);old=g_ptr;*new_ptr=*old;new_ptr->a=value;rcu_assign_pointer(g_ptr,new_ptr);call_rcu(&old->rcu,myrcu_del);printk("%s: write to new %d\n",__func__,value);value++;}return0;}staticstructtask_struct*reader_thread1;staticstructtask_struct*reader_thread2;staticstructtask_struct*writer_thread;staticint__initmy_test_init(void){intvalue=5;printk("figo: my mole init\n");g_ptr=kzalloc(sizeof(structfoo),GFP_KERNEL);reader_thread1=kthread_run(myrcu_reader_thread1,NULL,"rcu_reader1");reader_thread2=kthread_run(myrcu_reader_thread2,NULL,"rcu_reader2");writer_thread=kthread_run(myrcu_writer_thread,(void*)(unsignedlong)value,"rcu_writer");return0;}staticvoid__exitmy_test_exit(void){printk("goodbye\n");kthread_stop(reader_thread1);kthread_stop(reader_thread2);kthread_stop(writer_thread);if(g_ptr)kfree(g_ptr);}MODULE_LICENSE("GPL");mole_init(my_test_init);mole_exit(my_test_exit);
執行結果是：
myrcu_reader_thread2:reada=0myrcu_reader_thread1:reada=0myrcu_reader_thread2:reada=0myrcu_writer_thread:writetonew5myrcu_reader_thread2:reada=5myrcu_reader_thread1:reada=5myrcu_del:a=0
RCU 原理
可以用下面一張圖來總結，當寫線程 myrcu_writer_thread 寫完後，會更新到另外兩個讀線程 myrcu_reader_thread1 和 myrcu_reader_thread2。讀線程像是訂閱者，一旦寫線程對臨界區有更新，寫線程就像發布者一樣通知到訂閱者那裡，如下圖所示。
寫者在拷貝副本修改後進行 update 時，首先把舊的臨界資源數據移除（Removal）；然後把舊的數據進行回收（Reclamation）。結合 API 實現就是，首先使用 rcu_assign_pointer 來移除舊的指針指向，指向更新後的臨界資源；然後使用 synchronize_rcu 或 call_rcu 來啟動 Reclaimer，對舊的臨界資源進行回收（其中 synchronize_rcu 表示同步等待回收，call_rcu 表示非同步回收）。
為了確保沒有讀者正在訪問要回收的臨界資源，Reclaimer 需要等待所有的讀者退出臨界區，這個等待的時間叫做寬限期（Grace Period）。
Grace Period
中間的黃色部分代表的就是 Grace Period，中文叫做寬限期，從 Removal 到 Reclamation，中間就隔了一個寬限期，只有當寬限期結束後，才會觸發回收的工作。寬限期的結束代表著 Reader 都已經退出了臨界區，因此回收工作也就是安全的操作了。
寬限期是否結束，與 CPU 的執行狀態檢測有關，也就是檢測靜止狀態 Quiescent Status。
Quiescent Status
Quiescent Status，用於描述 CPU 的執行狀態。當某個 CPU 正在訪問 RCU 保護的臨界區時，認為是活動的狀態，而當它離開了臨界區後，則認為它是靜止的狀態。當所有的 CPU 都至少經歷過一次 Quiescent Status 後，寬限期將結束並觸發回收工作。
因為 rcu_read_lock 和 rcu_read_unlock 分別是關閉搶占和打開搶占，如下所示：
staticinlinevoid__rcu_read_lock(void){preempt_disable();}
staticinlinevoid__rcu_read_unlock(void){preempt_enable();}
所以發生搶占，就說明不在 rcu_read_lock 和 rcu_read_unlock 之間，即已經完成訪問或者還未開始訪問。
Linux 同步方式的總結
資料免費領
學習直通車
⑥ linux下,怎樣進人臨界區
先貼示範代檔鍵碼：銷閉
//--------------------tmutex.h開始------------------------------
//實現linux的互斥量c++封裝虧蠢裂
#ifndef TMUTEX_H
#define TMUTEX_H
#include <pthread.h>
//線程互斥量
struct ThreadMutex
{
ThreadMutex()
{
pthread_mutex_init(&mtx,NULL);
}
~ThreadMutex()
{
pthread_mutex_destroy( &mtx );
}
inline void lock()
{
pthread_mutex_lock( &mtx );
}
inline void unlock()
{
pthread_mutex_unlock( &mtx );
}
pthread_mutex_t mtx;
};
//空互斥量，即調用lock時什麼事都不做。
struct NullMutex
{
inline void lock()
{
}
inline void unlock()
{
}
};
template<class T>
class CAutoGuard
{
public:
CAutoGuard(T &mtx) : m_mtx(mtx)
{
m_mtx.lock();
}
~CAutoGuard()
{
m_mtx.unlock();
}
protected:
T &m_mtx;
};
#define AUTO_GUARD( guard_tmp_var, MUTEX_TYPE, mtx ) \
CAutoGuard<MUTEX_TYPE> guard_tmp_var(mtx)
#endif
//-------------------------tmutex.h結束------------------------------------------
//-------------------------主程序文件test.cpp開始----------------------------------
#include <pthread.h>
#include "tmutex.h"
#include <iostream>
using namespace std;
typedef ThreadMutex MUTEX_TYPE; //使用線程互斥量的互斥量類型
//typedef NullMutex MUTEX_TYPE; //不使用互斥量的互斥量類型
MUTEX_TYPE g_mtx; //互斥量變數定義
void *print_msg_thread(void *parg);
void *print_msg_thread(void *parg)
{//工作線程，用循環模擬一個的工作。
char *msg = (char *)parg;
AUTO_GUARD( gd, MUTEX_TYPE, g_mtx );
for(int i=0; i<10; i++ )
{
cout << msg << endl;
sleep( 1 );
}
return NULL;
}
int main()
{
pthread_t t1,t2;
//創建兩個工作線程，第1個線程列印10個1，第2個線程列印10個2。
pthread_create( &t1, NULL, &print_msg_thread, (void *)"1" );
pthread_create( &t2, NULL, &print_msg_thread, (void *)"2" );
//等待線程結束
pthread_join( t1,NULL);
pthread_join( t2,NULL);
return 0;
}
//-----------------------------主程序文件test.cpp結束
看了上面的示例代碼及注釋，相信已經了解該代碼的功能。我們在主程序中創建兩個線程，第1個線程循環列印10個1，第2個線程循環列印10個2。由於線程的特性，兩個線程並不一定會按順序執行，它們可能會被輪流調度執行。
如果兩個線程被輪流調度執行，那麼所列印的10個1和10個2的排列順序則不固定。線程1列印了幾個字元後，可能會別打斷，CPU被分配到線程2上去執行。這樣可以盡可能讓每個線程都得到CPU資源。但是另一方面也帶來了問題。如果兩個線程共同訪問了一個變數。並且兩個線程都會修改它，在修改未完成被打斷的話，會使得最後修改的結果和預期的不一致。對於不能被打斷的操作我們叫它原子操作。為了能使線程中的某段代碼成為原子操作，我們就得使用互斥量。如本例所示的列印10個字元，如果我們不使用互斥量那麼這個列印順序就會被破壞，使用了互斥量後，線程1未離開互斥量所管的區域，線程2是不能再次進入的。這就保證了列印過程的原子操作性。
Linux中使用臨界區加鎖的方法是用pthread_mutex_t進行操作，分別調用pthread_mutex_init、pthread_mutex_destroy創建和釋放pthread_mutex變數，調用pthread_mutex_lock和pthread_mutex_unlock進行加鎖和解鎖。其中pthread_mutex_init和pthread_mutex_destroy只要在最開始的時候和不用的時候各調用一次，pthread_mutex_lock和pthread_mutex_unlock則是在每次加鎖和解鎖時調用。要注意的是它們的調用必須一一對應。
本例的互斥量使用了C++的構造和析構以及模板的特性進行封裝，保證分配和釋放、加鎖和解鎖的成對，使得互斥量的使用更加簡單。加鎖時只需一個語句：AUTO_GUARD( gd, MUTEX_TYPE, g_mtx ); 該語句是個宏，展開宏得到的代碼是：CAutoGuard<MUTEX_TYPE> gd(g_mtx); CAutoGuard對象的構造和析構自動調用g_mtx的lock和unlock函數進行加鎖解鎖。而鎖的類型就看MUTEX_TYPE的定義了。下面這兩行是互斥量鎖類型的定義：
typedef ThreadMutex MUTEX_TYPE; //使用線程互斥量的互斥量類型
//typedef NullMutex MUTEX_TYPE; //不使用互斥量的互斥量類型
其中第1行的類型是ThreadMutex，我們看該struct的定義，在lock和unlock函數中分別調用了pthread_mutex_lock和pthread_mutex_unlock，這樣就實現了資源的鎖定和解鎖。
而第2行的類型是NullMutex，在該struct的定義中，lock和unlock函數都是空函數，沒有執行任何鎖定解鎖操作。
因此，將MUTEX_TYPE的類型改為ThreadMutex或NullMutex就可以實現使用或不使用互斥量的效果。
將上述兩個文件保存並編譯：g++ tmutex.h test.cpp -lpthread -o test
編譯完輸出test可執行文件。輸入./test執行程序。下面是使用互斥量和不使用互斥量的執行結果：
使用互斥量：
[root@hjclinux sampthread]# g++ tmutex.h test.cpp -lpthread -o test
[root@hjclinux sampthread]# ./test
1
1
1
1
1
1
1
1
1
1
2
2
2
2
2
2
2
2
2
2
將test.cpp中的MUTEX_TYPE定義改成typedef NullMutex MUTEX_TYPE再編譯執行結果如下：
[root@hjclinux sampthread]# ./test
1
2
2
1
2
1
2
1
2
1
2
1
2
1
2
1
2
1
2
1
由於線程調度的關系，可能每次執行列印出1和2的順序都不一樣。
原文地址：http://hi..com/%CD%E6%B5%E7%C4%D4%B5%C4%B7%B2%C8%CB/blog/item/f78ef19967abbe0b6f068c3d.html
⑦ Linux系統中對臨界資源進行互斥訪問的手段是
自旋鎖（Spin Lock）是一種典型的對臨界資源進行互斥訪問的手段，其名稱來源於它的工作方式。為了獲得一個自旋鎖，在某CPU上運行的代碼需先執行一個原子操作，該操作測試並設置（Test-AndSet）某個內存變數。由於它是原子操作，所以在該操作完成之前其他執行單元不可能訪問這個內存變數。如果測試結果表明鎖已經空閑，則程序獲得這個自旋鎖並繼續執行；如果測試結果表明鎖仍被佔用，程序將在一個小的循環內重復這個「測試並設置」操作，即進行所謂的「自旋」，通俗地說就是「在原地打轉」。當自旋鎖的持有者通過重置該變數釋放這個自旋鎖後，某個等待的「測試並設置」操作向其調用者報告鎖已釋放。理解自旋鎖最簡單的方法是把它作為一個變數看待，該變數把一個臨界區標記為「我當前在運行，請稍等一會」或者標記為「我當前不在運行，可以被使用。如果A執行單元首先進入常式，它將持有自旋鎖；當B執行單元試圖進入同一個常式時，將獲知自旋鎖已被持有，需等到A執行單元釋放後才能進入。在ARM體系結構下，自旋鎖的實現借用了ldrex指令、strex指令、ARM處理器內存屏障指令dmb和dsb、wfe指令和sev指令，這類似於代碼清單7.1的邏輯。可以說既要保證排他性，也要處理好內存屏障。
自旋鎖主要針對SMP或單CPU但內核可搶占的情況，對於單CPU和內核不支持搶占的系統，自旋鎖退化為空操作。在單CPU和內核可搶占的系統中，自旋鎖持有期間中內核的搶占將被禁止。由於內核可搶占的單CPU系統的行為實際上很類似於SMP系統，因此，在這樣的單CPU系統中使用自旋鎖仍十分必要。另外，在多核SMP的情況下，任何一個核拿到了自旋鎖，該核上的搶占調度也暫時禁止了，但是沒有禁止另外一個核的搶占調度。盡管用了自旋鎖可以保證臨界區不受別的CPU和本CPU內的搶占進程打擾，但是得到鎖的代碼路徑在執行臨界區的時候，還可能受到中斷和底半部的影響。為了防止這種影響，就需要用到自旋鎖的衍生。