RCU機制詳解

 簡介

        RCU（Read-Copy Update）是數據同步的一種方式，在當前的Linux內核中發揮着重要的作用。RCU主要針對的數據對象是鏈表，目的是提高遍歷讀取數據的效率，爲了達到目的使用RCU機制讀取數據的時候不對鏈表進行耗時的加鎖操作。這樣在同一時間可以有多個線程同時讀取該鏈表，並且允許一個線程對鏈表進行修改（修改的時候，需要加鎖）。RCU適用於需要頻繁的讀取數據，而相應修改數據並不多的情景，例如在文件系統中，經常需要查找定位目錄，而對目錄的修改相對來說並不多，這就是RCU發揮作用的最佳場景。

       Linux內核源碼當中,關於RCU的文檔比較齊全，你可以在 /Documentation/RCU/ 目錄下找到這些文件。Paul E. McKenney 是內核中RCU源碼的主要實現者，他也寫了很多RCU方面的文章。他把這些文章和一些關於RCU的論文的鏈接整理到了一起。http://www2.rdrop.com/users/paulmck/RCU/

       在RCU的實現過程中，我們主要解決以下問題：

       1，在讀取過程中，另外一個線程刪除了一個節點。刪除線程可以把這個節點從鏈表中移除，但它不能直接銷燬這個節點，必須等到所有的讀取線程讀取完成以後，才進行銷燬操作。RCU中把這個過程稱爲寬限期（Grace period）。

       2，在讀取過程中，另外一個線程插入了一個新節點，而讀線程讀到了這個節點，那麼需要保證讀到的這個節點是完整的。這裏涉及到了發佈-訂閱機制（Publish-Subscribe Mechanism）。

       3， 保證讀取鏈表的完整性。新增或者刪除一個節點，不至於導致遍歷一個鏈表從中間斷開。但是RCU並不保證一定能讀到新增的節點或者不讀到要被刪除的節點。

       寬限期

        通過例子，方便理解這個內容。以下例子修改於Paul的文章。

struct foo {
           int a;
           char b;
           long c;
 };

DEFINE_SPINLOCK(foo_mutex);

struct foo *gbl_foo;

void foo_read (void)
{
     foo *fp = gbl_foo;
     if ( fp != NULL )
            dosomething(fp->a, fp->b , fp->c );
}

void foo_update( foo* new_fp )
{
     spin_lock(&foo_mutex);
     foo *old_fp = gbl_foo;
     gbl_foo = new_fp;
     spin_unlock(&foo_mutex);
     kfee(old_fp);
}

struct foo {
           int a;
           char b;
           long c;
 };

DEFINE_SPINLOCK(foo_mutex);

struct foo *gbl_foo;

void foo_read (void)
{
     foo *fp = gbl_foo;
     if ( fp != NULL )
            dosomething(fp->a, fp->b , fp->c );
}

void foo_update( foo* new_fp )
{
     spin_lock(&foo_mutex);
     foo *old_fp = gbl_foo;
     gbl_foo = new_fp;
     spin_unlock(&foo_mutex);
     kfee(old_fp);
}

      如上的程序，是針對於全局變量gbl_foo的操作。假設以下場景。有兩個線程同時運行 foo_ read和foo_update的時候，當foo_ read執行完賦值操作後，線程發生切換；此時另一個線程開始執行foo_update並執行完成。當foo_ read運行的進程切換回來後，運行dosomething 的時候，fp已經被刪除，這將對系統造成危害。爲了防止此類事件的發生，RCU裏增加了一個新的概念叫寬限期（Grace period）。如下圖所示：

 

         圖中每行代表一個線程，最下面的一行是刪除線程，當它執行完刪除操作後，線程進入了寬限期。寬限期的意義是，在一個刪除動作發生後，它必須等待所有在寬限期開始前已經開始的讀線程結束，纔可以進行銷燬操作。這樣做的原因是這些線程有可能讀到了要刪除的元素。圖中的寬限期必須等待1和2結束；而讀線程5在寬限期開始前已經結束，不需要考慮；而3,4,6也不需要考慮，因爲在寬限期結束後開始後的線程不可能讀到已刪除的元素。爲此RCU機制提供了相應的API來實現這個功能。                             

void foo_read(void)
{
    rcu_read_lock();
    foo *fp = gbl_foo;
    if ( fp != NULL )
            dosomething(fp->a,fp->b,fp->c);
    rcu_read_unlock();
}

void foo_update( foo* new_fp )
{
    spin_lock(&foo_mutex);
    foo *old_fp = gbl_foo;
    gbl_foo = new_fp;
    spin_unlock(&foo_mutex);
    synchronize_rcu();
    kfee(old_fp);
}

void foo_read(void)
{
    rcu_read_lock();
    foo *fp = gbl_foo;
    if ( fp != NULL )
            dosomething(fp->a,fp->b,fp->c);
    rcu_read_unlock();
}

void foo_update( foo* new_fp )
{
    spin_lock(&foo_mutex);
    foo *old_fp = gbl_foo;
    gbl_foo = new_fp;
    spin_unlock(&foo_mutex);
    synchronize_rcu();
    kfee(old_fp);
}

      其中foo_read中增加了rcu_read_lock和rcu_read_unlock，這兩個函數用來標記一個RCU讀過程的開始和結束。其實作用就是幫助檢測寬限期是否結束。foo_update增加了一個函數synchronize_rcu()，調用該函數意味着一個寬限期的開始，而直到寬限期結束，該函數纔會返回。我們再對比着圖看一看，線程1和2，在synchronize_rcu之前可能得到了舊的gbl_foo，也就是foo_update中的old_fp，如果不等它們運行結束，就調用kfee(old_fp)，極有可能造成系統崩潰。而3,4,6在synchronize_rcu之後運行，此時它們已經不可能得到old_fp，此次的kfee將不對它們產生影響。

     寬限期是RCU實現中最複雜的部分,原因是在提高讀數據性能的同時，刪除數據的性能也不能太差。

     訂閱——發佈機制 

      當前使用的編譯器大多會對代碼做一定程度的優化，CPU也會對執行指令做一些優化調整,目的是提高代碼的執行效率，但這樣的優化，有時候會帶來不期望的結果。如例：

void foo_update( foo* new_fp )
{
    spin_lock(&foo_mutex);
    foo *old_fp = gbl_foo;

    new_fp->a = 1;
    new_fp->b = ‘b’;
    new_fp->c = 100;

    gbl_foo = new_fp;
    spin_unlock(&foo_mutex);
    synchronize_rcu();
    kfee(old_fp);
}

void foo_update( foo* new_fp )
{
    spin_lock(&foo_mutex);
    foo *old_fp = gbl_foo;

    new_fp->a = 1;
    new_fp->b = ‘b’;
    new_fp->c = 100;

    gbl_foo = new_fp;
    spin_unlock(&foo_mutex);
    synchronize_rcu();
    kfee(old_fp);
}

       這段代碼中，我們期望的是6，7，8行的代碼在第10行代碼之前執行。但優化後的代碼並不對執行順序做出保證。在這種情形下，一個讀線程很可能讀到 new_fp，但new_fp的成員賦值還沒執行完成。當讀線程執行dosomething(fp->a, fp->b , fp->c ) 的 時候，就有不確定的參數傳入到dosomething，極有可能造成不期望的結果，甚至程序崩潰。可以通過優化屏障來解決該問題，RCU機制對優化屏障做了包裝，提供了專用的API來解決該問題。這時候，第十行不再是直接的指針賦值，而應該改爲 :

       rcu_assign_pointer(gbl_foo,new_fp);

       rcu_assign_pointer的實現比較簡單，如下：

      <include/linux/rcupdate.h>

#define rcu_assign_pointer(p, v) \
         __rcu_assign_pointer((p), (v), __rcu)

#define __rcu_assign_pointer(p, v, space) \
         do { \
                 smp_wmb(); \
                 (p) = (typeof(*v) __force space *)(v); \
         } while (0)

#define rcu_assign_pointer(p, v) \
         __rcu_assign_pointer((p), (v), __rcu)

#define __rcu_assign_pointer(p, v, space) \
         do { \
                 smp_wmb(); \
                 (p) = (typeof(*v) __force space *)(v); \
         } while (0)

      我們可以看到它的實現只是在賦值之前加了優化屏障 smp_wmb來確保代碼的執行順序。另外就是宏中用到的__rcu，只是作爲編譯過程的檢測條件來使用的。

      在DEC Alpha CPU機器上還有一種更強悍的優化，如下所示：

void foo_read(void)
{
    rcu_read_lock();
    foo *fp = gbl_foo;
    if ( fp != NULL )
        dosomething(fp->a, fp->b ,fp->c);
    rcu_read_unlock();
}

void foo_read(void)
{
    rcu_read_lock();
    foo *fp = gbl_foo;
    if ( fp != NULL )
        dosomething(fp->a, fp->b ,fp->c);
    rcu_read_unlock();
}

      第六行的 fp->a,fp->b,fp->c會在第3行還沒執行的時候就預先判斷運行，當他和foo_update同時運行的時候，可能導致傳入dosomething的一部分屬於舊的gbl_foo，而另外的屬於新的。這樣導致運行結果的錯誤。爲了避免該類問題，RCU還是提供了宏來解決該問題：

<include/linux/rcupdate.h>

#define rcu_dereference(p) rcu_dereference_check(p, 0)


#define rcu_dereference_check(p, c) \
         __rcu_dereference_check((p), rcu_read_lock_held() || (c), __rcu)

#define __rcu_dereference_check(p, c, space) \
         ({ \
                 typeof(*p) *_________p1 = (typeof(*p)*__force )ACCESS_ONCE(p); \
                 rcu_lockdep_assert(c, "suspicious rcu_dereference_check()" \
                                       " usage"); \
                 rcu_dereference_sparse(p, space); \
                 smp_read_barrier_depends(); \
                 ((typeof(*p) __force __kernel *)(_________p1)); \
         })

static inline int rcu_read_lock_held(void)
{
         if (!debug_lockdep_rcu_enabled())
                 return 1;
         if (rcu_is_cpu_idle())
                 return 0;
         if (!rcu_lockdep_current_cpu_online())
                 return 0;
         return lock_is_held(&rcu_lock_map);
}

#define rcu_dereference(p) rcu_dereference_check(p, 0)


#define rcu_dereference_check(p, c) \
         __rcu_dereference_check((p), rcu_read_lock_held() || (c), __rcu)

#define __rcu_dereference_check(p, c, space) \
         ({ \
                 typeof(*p) *_________p1 = (typeof(*p)*__force )ACCESS_ONCE(p); \
                 rcu_lockdep_assert(c, "suspicious rcu_dereference_check()" \
                                       " usage"); \
                 rcu_dereference_sparse(p, space); \
                 smp_read_barrier_depends(); \
                 ((typeof(*p) __force __kernel *)(_________p1)); \
         })

static inline int rcu_read_lock_held(void)
{
         if (!debug_lockdep_rcu_enabled())
                 return 1;
         if (rcu_is_cpu_idle())
                 return 0;
         if (!rcu_lockdep_current_cpu_online())
                 return 0;
         return lock_is_held(&rcu_lock_map);
}

       這段代碼中加入了調試信息，去除調試信息，可以是以下的形式（其實這也是舊版本中的代碼）：

#define rcu_dereference(p)     ({ \
                    typeof(p) _________p1 = p; \
                    smp_read_barrier_depends(); \
                    (_________p1); \
                    })

#define rcu_dereference(p)     ({ \
                    typeof(p) _________p1 = p; \
                    smp_read_barrier_depends(); \
                    (_________p1); \
                    })

       在賦值後加入優化屏障smp_read_barrier_depends()。

        我們之前的第四行代碼改爲 foo *fp = rcu_dereference(gbl_foo);，就可以防止上述問題。

       數據讀取的完整性

        還是通過例子來說明這個問題：

       

 

       如圖我們在原list中加入一個節點new到A之前，所要做的第一步是將new的指針指向A節點，第二步纔是將Head的指針指向new。這樣做的目的是當插入操作完成第一步的時候，對於鏈表的讀取並不產生影響，而執行完第二步的時候，讀線程如果讀到new節點，也可以繼續遍歷鏈表。如果把這個過程反過來，第一步head指向new，而這時一個線程讀到new，由於new的指針指向的是Null，這樣將導致讀線程無法讀取到A，B等後續節點。從以上過程中，可以看出RCU並不保證讀線程讀取到new節點。如果該節點對程序產生影響，那麼就需要外部調用做相應的調整。如在文件系統中，通過RCU定位後，如果查找不到相應節點，就會進行其它形式的查找，相關內容等分析到文件系統的時候再進行敘述。

      我們再看一下刪除一個節點的例子：

     如圖我們希望刪除B，這時候要做的就是將A的指針指向C，保持B的指針，然後刪除程序將進入寬限期檢測。由於B的內容並沒有變更，讀到B的線程仍然可以繼續讀取B的後續節點。B不能立即銷燬，它必須等待寬限期結束後，才能進行相應銷燬操作。由於A的節點已經指向了C，當寬限期開始之後所有的後續讀操作通過A找到的是C，而B已經隱藏了，後續的讀線程都不會讀到它。這樣就確保寬限期過後，刪除B並不對系統造成影響。

     小結

       RCU的原理並不複雜，應用也很簡單。但代碼的實現確並不是那麼容易，難點都集中在了寬限期的檢測上，後續分析源代碼的時候，我們可以看到一些極富技巧的實現方式。