RCU的設(shè)計思想比較明確，通過新老指針替換的方式來實現(xiàn)免鎖方式的共享保護。但是具體到代碼的層面，理解起來多少還是會有些困難。在《深入Linux設(shè)備驅(qū)動程序內(nèi)核機制》第4章中，已經(jīng)非常明確地敘述了RCU背后所遵循的規(guī)則，這些規(guī)則是從一個比較高的視角來看，因為我覺得過多的代碼分析反而容易讓讀者在細節(jié)上迷失方向。最近拿到書后，我又重頭仔細看了RCU部分的文字，覺得還應該補充一點點內(nèi)容，因為有些東西不一定適合寫在書里。

　　RCU讀取側(cè)進入臨界區(qū)的標志是調(diào)用rcu_read_lock，這個函數(shù)的代碼是：

　　《include/linux/rcupdate.h》

　　static inline void rcu_read_lock（void）

　　{

　　__rcu_read_lock（）;

　　__acquire（RCU）;

　　rcu_read_acquire（）;

　　}

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

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

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

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

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

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

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

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

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