對于Linux內核中的內存屏障的總結
前言
之前讀了關于順序一致性和緩存一致性討論的文章，感覺豁然開朗。對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問題，等等。
