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

　　RCU讀取側進入臨界區的標志是調用rcu_read_lock，這個函數的代碼是：

　　《include/linux/rcupdate.h》

　　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函數了。