Linux內核中的RCU機制

　　RCU的設計思想比較明確，通過(guò)新老指針替換的方式來(lái)實(shí)現免鎖方式的共享保護。但是具體到代碼的層面，理解起來(lái)多少還是會(huì )有些困難。下面小編準備了關(guān)于Linux內核中的RCU機制的文章，提供給大家參考!

　　RCU讀取側進(jìn)入臨界區的標志是調用rcu_read_lock，這個(gè)函數的代碼是：

　　static inline void rcu_read_lock(void)

　　{

　　__rcu_read_lock();

　　__acquire(RCU);

　　rcu_read_acquire();

　　}

　　該實(shí)現里面貌似有三個(gè)函數調用，但實(shí)質(zhì)性的工作由第一個(gè)函數__rcu_read_lock()來(lái)完成，__rcu_read_lock()通過(guò)調用 preempt_disable()關(guān)閉內核可搶占性。但是中斷是允許的，假設讀取者正處于rcu臨界區中且剛讀取了一個(gè)共享數據區的指針p(但是還沒(méi)有訪(fǎng)問(wèn)p中的數據成員)，發(fā)生了一個(gè)中斷，而該中斷處理例程ISR恰好需要修改p所指向的數據區，按照RCU的設計原則，ISR會(huì )新分配一個(gè)同樣大小的數據區new_p，再把老數據區p中的數據拷貝到新數據區，接著(zhù)是在new_p的基礎上做數據修改的工作(因為是在new_p空間中修改，所以不存在對p的并發(fā)訪(fǎng)問(wèn)，因此說(shuō)RCU是一種免鎖機制，原因就在這里)，ISR在把數據更新的工作完成后，將new_p賦值給p(p=new_p),最后它會(huì )再注冊一個(gè)回調函數用以在適當的時(shí)候釋放老指針p。因此，只要對老指針p上的所有引用都結束了，釋放p就不會(huì )有問(wèn)題。當中斷處理例程做完這些工作返回后，被中斷的進(jìn)程將依然訪(fǎng)問(wèn)到p空間上的數據，也就是老數據，這樣的結果是RCU機制所允許的。RCU規則對讀取者與寫(xiě)入者之間因指針切換所造成的短暫的資源視圖不一致問(wèn)題是允許的。

　　接下來(lái)關(guān)于RCU一個(gè)有趣的問(wèn)題是：何時(shí)才能釋放老指針。我見(jiàn)過(guò)很多書(shū)中對此的回答是：當系統中所有處理器上都發(fā)生了一次進(jìn)程切換。這種程式化的回答常常讓剛接觸RCU機制的讀者感到一頭霧水，為什么非要等所有處理器上都發(fā)生一次進(jìn)程切換才可以調用回調函數釋放老指針呢?這其實(shí)是RCU的設計規則決定的： 所有對老指針的引用只可能發(fā)生在rcu_read_lock與rcu_read_unlock所包括的臨界區中，而在這個(gè)臨界區中不可能發(fā)生進(jìn)程切換，而一旦出了該臨界區就不應該再有任何形式的對老指針p的引用。很明顯，這個(gè)規則要求讀取者在臨界區中不能發(fā)生進(jìn)程切換，因為一旦有進(jìn)程切換，釋放老指針的回調函數就有可能被調用，從而導致老指針被釋放掉，當被切換掉的進(jìn)程被重新調度運行時(shí)它就有可能引用到一個(gè)被釋放掉的內存空間。

　　現在我們看到為什么rcu_read_lock只需要關(guān)閉內核可搶占性就可以了，因為它使得即便在臨界區中發(fā)生了中斷，當前進(jìn)程也不可能被切換除去。 內核開(kāi)發(fā)者，確切地說(shuō)，RCU的設計者所能做的只能到這個(gè)程度。接下來(lái)就是使用者的責任了，如果在rcu的臨界區中調用了一個(gè)函數，該函數可能睡眠，那么RCU的設計規則就遭到了破壞，系統將進(jìn)入一種不穩定的狀態(tài)。

　　這再次說(shuō)明，如果想使用一個(gè)東西，一定要搞清楚其內在的機制，象上面剛提到的那個(gè)例子，即便現在程序不出現問(wèn)題，但是系統中留下的隱患如同一個(gè)定時(shí)炸彈， 隨時(shí)可能被引爆，尤其是過(guò)了很長(cháng)時(shí)間問(wèn)題才突然爆發(fā)出來(lái)。絕大多數情形下，找到問(wèn)題所花費的時(shí)間可能要遠遠大于靜下心來(lái)仔細搞懂RCU的原理要多得多。

　　RCU中的讀取者相對rwlock的讀取者而言，自由度更高。因為RCU的讀取者在訪(fǎng)問(wèn)一個(gè)共享資源時(shí)，不需要考慮寫(xiě)入者的感受，這不同于rwlock的寫(xiě)入者，rwlock reader在讀取共享資源時(shí)需要確保沒(méi)有寫(xiě)入者在操作該資源。兩者之間的差異化源自RCU對共享資源在讀取者與寫(xiě)入者之間進(jìn)行了分離，而rwlock的 讀取者和寫(xiě)入者則至始至終只使用共享資源的一份拷貝。這也意味著(zhù)RCU中的寫(xiě)入者要承擔更多的責任，而且對同一共享資源進(jìn)行更新的多個(gè)寫(xiě)入者之間必須引入某種互斥機制，所以RCU屬于一種"免鎖機制"的說(shuō)法僅限于讀取者與寫(xiě)入者之間。所以我們看到：RCU機制應該用在有大量的讀取操作，而更新操作相對較少的情形下。此時(shí)RCU可以大大提升系統系能，因為RCU的讀取操作相對其他一些有鎖機制而言，在鎖上的開(kāi)銷(xiāo)幾乎沒(méi)有。

　　實(shí)際使用中，共享的資源常常以鏈表的形式存在，內核為RCU模式下的鏈表操作實(shí)現了幾個(gè)接口函數，讀取者和使用者應該使用這些內核函數，比如 list_add_tail_rcu, list_add_rcu，hlist_replace_rcu等等，具體的使用可以參考某些內核編程或者設備驅動(dòng)程序方面的資料。

　　在釋放老指針?lè )矫�，Linux內核提供兩種方法供使用者使用，一個(gè)是調用call_rcu,另一個(gè)是調用synchronize_rcu。前者是一種異步 方式，call_rcu會(huì )將釋放老指針的回調函數放入一個(gè)結點(diǎn)中，然后將該結點(diǎn)加入到當前正在運行call_rcu的處理器的本地鏈表中，在時(shí)鐘中斷的 softirq部分(RCU_SOFTIRQ)， rcu軟中斷處理函數rcu_process_callbacks會(huì )檢查當前處理器是否經(jīng)歷了一個(gè)休眠期(quiescent，此處涉及內核進(jìn)程調度等方面的內容)，rcu的內核代碼實(shí)現在確定系統中所有的處理器都經(jīng)歷過(guò)了一個(gè)休眠期之后(意味著(zhù)所有處理器上都發(fā)生了一次進(jìn)程切換，因此老指針此時(shí)可以被安全釋放掉了)，將調用call_rcu提供的回調函數。

　　synchronize_rcu的實(shí)現則利用了等待隊列，在它的實(shí)現過(guò)程中也會(huì )向call_rcu那樣向當前處理器的本地鏈表中加入一個(gè)結點(diǎn)，與 call_rcu不同之處在于該結點(diǎn)中的回調函數是wakeme_after_rcu，然后synchronize_rcu將在一個(gè)等待隊列中睡眠，直到系統中所有處理器都發(fā)生了一次進(jìn)程切換，因而wakeme_after_rcu被rcu_process_callbacks所調用以喚醒睡眠的 synchronize_rcu，被喚醒之后，synchronize_rcu知道它現在可以釋放老指針了。

　　所以我們看到，call_rcu返回后其注冊的回調函數可能還沒(méi)被調用，因而也就意味著(zhù)老指針還未被釋放，而synchronize_rcu返回后老指針肯定被釋放了。所以，是調用call_rcu還是synchronize_rcu，要視特定需求與當前上下文而定，比如中斷處理的上下文肯定不能使用 synchronize_rcu函數了。

【Linux內核中的RCU機制】相關(guān)文章：

Linux內核和驅動(dòng)考試題06-13

Linux中du命令參數的用法11-01

Linux中的more命令解讀202405-06

linux中php如何安裝CURL06-10

linux命令中su和sudo區別08-10

java程序中如何調用linux命令08-27

績(jì)效管理中的溝通機制建設12-13

perl- javascript中class的機制05-03

Linux系統中的SSH如何添加雙重認證09-01

php內核知識解讀09-06