Linux核心中的記憶體屏障)

轉自：http://www.linuxidc.com/Linux/2011-10/44623.htm

前言
之前讀了關於順序一致性和緩衝一致性討論的文章，感覺豁然開朗。對linux核心中出現的種種同步和屏障，想做一點總結。

緩衝一致性
之前一直認為linux中很多東西是用來保證緩衝一致性的，其實不是。緩衝一致性絕大部分是靠硬體機制實現的，只有在帶lock首碼的指令執行時才與cache有一點關係。（這話說得絕對，但我目前看來就是這樣）我們更多的時候是為了保證順序一致性。
-
 

所謂緩衝一致性，就是在多處理器系統中，每個cpu都有自己的L1 cache。很可能兩個不同cpu的L1 cache中緩衝的是同一片記憶體的內容，如果一個cpu更改了自己被緩衝的內容，它要保證另一個cpu讀這塊資料時也要讀到這個最新的。不過你不要擔心，這個複雜的工作完全是由硬體來完成的，通過實現一種MESI協議，硬體可以輕鬆的完成緩衝一致性的工作。不要說一個讀一個寫，就是多個同時寫都沒問題。一個cpu讀時總能讀入最新的資料，不管它是在自己的cache中，還是在其它cpu的cache中，還是在記憶體中，這就是緩衝一致性。

順序一致性
所謂順序一致性，說的則是與緩衝一致性完全不同的概念，雖然它們都是處理器發展的產物。因為編譯器的技術不斷髮展，它可能為了最佳化你的代碼，而將某些操作的順序更改執行。處理器中也早就有了多發射、亂序執行的概念。這樣的結果，就是實際執行的指令順序會與編程時代碼的執行順序略有不同。這在單一處理器下當然沒什麼，畢竟只要自己的代碼不過問，就沒人過問，編譯器和處理器就是在保證自己的代碼發現不了的情況下打亂執行順序的。但多處理器不是這樣，可能一個處理器上指令的完成順序，會對其它處理器上執行的代碼造成很大影響。所以就有了順序一致性的概念，即保證一個處理器上線程的執行順序，在其它的處理器上的線程看來，都是一樣的。這個問題的解決不是光靠處理器或者編譯器就能解決的，需要軟體的幹預。

記憶體屏障
軟體幹預的方式也非常簡單，那就是插入記憶體屏障(memory barrier)。其實記憶體屏障這個詞，是由搞處理器的人造的，弄得我們很不好理解。記憶體屏障，很容易讓我們串到緩衝一致性去，乃至懷疑是否這樣做才能讓其它cpu看到被修改過的cache，這樣想就錯了。所謂記憶體屏障，從處理器角度來說，是用來序列化讀寫操作的，從軟體角度來講，就是用來解決順序一致性問題的。編譯器不是要打亂代碼執行順序嗎，處理器不是要亂序執行嗎，你插入一個記憶體屏障，就相當於告訴編譯器，屏障前後的指令順序不能顛倒，告訴處理器，只有等屏障前的指令執行完了，屏障後的指令才能開始執行。當然，記憶體屏障能阻擋編譯器亂來，但處理器還是有辦法。處理器中不是有多發射、亂序執行、順序完成的概念嗎，它在記憶體屏障時只要保證前面指令的讀寫操作，一定在後面指令的讀寫操作完成之前完成，就可以了。所以記憶體屏障才會對應有讀屏障、寫屏障和讀寫屏障三類。如x86之前保證寫操作都是順序完成的，所以不需要寫屏障，但現在也有部分ia32處理器的寫操作變成亂序完成，所以也需要寫屏障。
    其實，除了專門的讀寫屏障指令，還有很多指令的執行是帶有讀寫屏障功能的，比如帶lock首碼的指令。在專門的讀寫屏障指令出現之前，linux就是靠lock熬過來的。
    至於在那裡插入讀寫屏障，要視軟體的需求而定。讀寫屏障無法完全實現順序一致性，但多處理器上的線程也不會一直盯著你的執行順序看，只要保證在它看過來的時候，認為你符合順序一致性，執行不會出現你代碼中沒有預料到的情況。所謂預料外的情況，舉例而言，你的線程是先給變數a賦值，再給變數b賦值，結果別的處理器上啟動並執行線程看過來，發現b賦值了，a卻沒有賦值，（注意這種不一致不是由緩衝不一致造成的，而是處理器寫操作完成的順序不一致造成的），這時就要在a賦值與b賦值之間，加一個寫屏障。

多處理器間同步
      有了SMP之後，線程就開始同時在多個處理器上運行。只要是線程就有通訊和同步的要求。幸好SMP系統是共用記憶體的，也就是所有處理器看到的記憶體內容都一樣，雖然有獨立的L1 cache，但還是由硬體完成了緩衝一致性處理的問題。那不同處理器上的線程要訪問同一資料，需要臨界區，需要同步。靠什麼同步？之前在UP系統中，我們上靠訊號量，下靠關中斷和讀修改寫指令。現在在SMP系統中，關中斷已經廢了，雖然為了同步同一處理器上的線程還是需要的，但只靠它已經不行了。讀修改寫指令？也不行了。在你指令中讀操作完成寫操作還沒進行時，就可能有另外的處理器進行了讀操作或者寫操作。緩衝一致性協議是先進，但還沒有先進到預測這條讀操作是哪種指令發出來的。所以x86又發明了帶lock首碼的指令。在此指令執行時，會將所有包含指令中讀寫地址的cache line失效，並鎖定記憶體匯流排。這樣別的處理器要想對同樣的地址或者同一個cache line上的地址讀寫，既無法從cache中進行（cache中相關line已經失效了），也無法從記憶體匯流排上進行（整個記憶體匯流排都鎖了），終於達到了原子性執行的目的。當然，從P6處理器開始，如果帶lock首碼指令 要訪問的地址本來就在cache中，就無需鎖記憶體匯流排，也能完成原子性操作了（雖然我懷疑這是因為加了多處理器內部公用的L2 cache的緣故）。

因為會鎖記憶體匯流排，所以帶lock首碼指令執行前，也會先將未完成的讀寫操作完成，也起到記憶體屏障的功能。
     現在多處理器間線程的同步，上用自旋鎖，下用這種帶了lock首碼的讀修改寫指令。當然，實際的同步還有加上禁止本處理器任務調度的，有加上任務關中斷的，還會在外面加上訊號量的外衣。linux中對這種自旋鎖的實現，已曆經四代發展，變得愈發高效強大。

 

記憶體屏障的實現
#ifdef CONFIG_SMP   
#define smp_mb()    mb()   
#define smp_rmb()   rmb()   
#define smp_wmb()   wmb()   
#else   
#define smp_mb()    barrier()   
#define smp_rmb()   barrier()   
#define smp_wmb()   barrier()   
#endif 

CONFIG_SMP就是用來支援多處理器的。如果是UP(uniprocessor)系統，就會翻譯成barrier()。

#define barrier() __asm__ __volatile__("": : :"memory") 
barrier()的作用，就是告訴編譯器，記憶體的變數值都改變了，之前存在寄存器裡的變數副本無效，要訪問變數還需再訪問記憶體。這樣做足以滿足UP中所有的記憶體屏障。
#ifdef CONFIG_X86_32   
/* 
 * Some non-Intel clones support out of order store. wmb() ceases to be a 
 * nop for these. 
 */  
#define mb() alternative("lock; addl $0,0(%%esp)", "mfence", X86_FEATURE_XMM2)   
#define rmb() alternative("lock; addl $0,0(%%esp)", "lfence", X86_FEATURE_XMM2)   
#define wmb() alternative("lock; addl $0,0(%%esp)", "sfence", X86_FEATURE_XMM)   
#else   
#define mb()    asm volatile("mfence":::"memory")   
#define rmb()   asm volatile("lfence":::"memory")   
#define wmb()   asm volatile("sfence" ::: "memory")   
#endif 
如果是SMP系統，記憶體屏障就會翻譯成對應的mb()、rmb()和wmb()。這裡CONFIG_X86_32的意思是說這是一個32位x86系統，否則就是64位的x86系統。現在的linux核心將32位x86和64位x86融合在同一個x86目錄，所以需要增加這個配置選項。

可以看到，如果是64位x86，肯定有mfence、lfence和sfence三條指令，而32位的x86系統則不一定，所以需要進一步查看cpu是否支援這三條新的指令，不行則用加鎖的方式來增加記憶體屏障。

SFENCE,LFENCE,MFENCE指令提供了高效的方式來保證讀寫記憶體的排序,這種操作發生在產生弱排序資料的程式和讀取這個資料的程式之間。
   SFENCE——序列化發生在SFENCE指令之前的寫操作但是不影響讀操作。
   LFENCE——序列化發生在SFENCE指令之前的讀操作但是不影響寫操作。
   MFENCE——序列化發生在MFENCE指令之前的讀寫操作。
sfence:在sfence指令前的寫操作當必須在sfence指令後的寫操作前完成。
lfence：在lfence指令前的讀操作當必須在lfence指令後的讀操作前完成。
mfence：在mfence指令前的讀寫操作當必須在mfence指令後的讀寫操作前完成。

 

至於帶lock的記憶體操作，會在鎖記憶體匯流排之前，就把之前的讀寫操作結束，功能相當於mfence，當然執行效率上要差一些。

說起來，現在寫點底層代碼真不容易，既要注意SMP問題，又要注意cpu亂序讀寫問題，還要注意cache問題，還有裝置DMA問題，等等。

 

多處理器間同步的實現
      多處理器間同步所使用的自旋鎖實現，已經有專門的文章介紹，見《spin lock在kernel 2.4與2.6中的實現與改進》。

本篇文章來源於 Linux公社網站(www.linuxidc.com)  原文連結：http://www.linuxidc.com/Linux/2011-10/44623.htm