目前的高階處理器，為了提高內部邏輯元件的利用率以提高執行速度，通常會採用多指令發射、亂序執行等各種措施。現在普遍使用的一些超標量處理器通常
能夠在一個指令週期內併發執行多條指令。處理器從L1
I-Cache預取了一批指令後，就會分析找出那些互相沒有關聯可以併發執行的指令，然後送到幾個獨立的執行單元進行併發執行。比如下面這樣的程式碼（假定
編譯器不做優化）： 
z = x + y;
p = m + n;
CPU就有可能將這兩行無關程式碼分別送到兩個算術單元去同時執行。像Freescale的MPC8541這種嵌入式處理器一個指令週期能夠載入4條指令、發射2條指令到流水線、用5個獨立的執行單元來併發執行。 
通常來說訪存指令（由LSU單元執行）所需要的指令週期可能很多（可能要幾十甚至上百個週期），而一般的算術指令通常在一個指令週期就搞
定。所以有 可能程式碼中的訪存指令耗費了多個週期完成執行後，其他幾個執行單元可能已經把後面有多條邏輯上無關的算術指令都執行完了，這就產生了亂序。
另外訪存指令之間也存在亂序的問題。高階的CPU可以根據自己Cache的組織特性，將訪存指令重新排序執行。訪問一些連續地址的可能會
先執行，因
為這時候Cache命中率高。有的還允許訪存的Non-blocking，即如果前面一條訪存指令因為Cache不命中，造成長延時的儲存訪問時，後面的
訪存指令可以先執行以便從Cache取數。對寫指令的訪存亂序有可能造成的錯誤後果，所以處理器通常有專門的機制（通常是做了個緩衝）保證在出現異常或者
錯誤的時候，可以丟棄異常點後面的寫指令的結果不做寫入。 
處理器的分支預測功能也能引起併發執行。處理器的分支預測單元有可能直接把兩條分支的指令都預取來一塊併發執行掉。等到分支判斷的結果出來以後，再丟棄錯誤分支的計算結果。這樣在很多情況下可以實現0週期跳轉。比如這樣的程式碼（假定編譯器不做優化）： 
z = x + y; 
if (z > 0) then
    p = m + n;
else
    p = m - n;
看上去如果z不計算出來是無法繼續的。但是實際上CPU有可能先把三個加法都同時進行計算，然後根據z=x+y的結果直接挑選正確的p值。 
因此，即使是從彙編上看順序正確的指令，其執行的順序也是不可預知的。處理器能夠保證併發和亂序執行不會得到錯誤結果，但是如果是對一些硬
件暫存器
的操作不能允許亂序的話，程式設計師就必須把這個情況告訴CPU。告訴的方法就是通過CPU提供的一組同步指令實現，通常在CPU的文件裡面有對同步指令的使
用說明。系統函式庫裡面的記憶體屏障（rmb/wmb/mb）實際上也是通過這些同步指令實現的。因此在C編碼的時候，只要設定好記憶體屏障，就能告訴CPU
哪些程式碼是不能亂序的。 
編譯器的亂序優化
受到處理器預取單元的能力限制，處理器每次只能分析一小塊指令的併發性，如果指令相隔比較遠就無能為力了。但是從編譯器的角度來看，編譯器能夠對很
大一個範圍的程式碼進行分析，能夠從更大的範圍內分辨出可以併發的指令，並將其儘量靠近排列讓處理器更容易預取和併發執行，充分利用處理器的亂序併發功能。
所以現代的高效能編譯器在目標碼優化上都具備對指令進行亂序優化的能力。並且可以對訪存的指令進行進一步的亂序，減少邏輯上不必要的訪存，以及儘量提高
Cache命中率和CPU的LSU（load/store
unit）的工作效率。所以在開啟編譯器優化以後，看到生成的彙編碼並不嚴格按照程式碼的邏輯順序是正常的。和處理器一樣，如果想要告訴編譯器不要去對某些
指令亂序優化，也要通過一些方式來告訴編譯器。通常可以通過volatile關鍵字來抑制（注意，不是禁止）編譯器對相關變數的訪問優化。舉個例子： 
int *p, *q; 
......; 
*p = 1; 
*p = 2; 
*q = *p;
這樣，編譯器通常會優化掉前面一個對*p的寫入（邏輯上冗餘），僅對*p寫入2。而對*q賦值的時候，編譯器認為此時*q的結果就應該是上次*p的值，會優化掉從*p取數的過程，直接把在暫存器中儲存的*p的值給*q（PowrPC彙編）： 
（假設r3=p，r4=q） 
li   r5, 2      // r5賦值2 
stw  r5, 0(r3)  // 把r5寫到*p 
stw  r5, 0(r4)  // 把r5寫到*q
但是如果為p指標加上了volatile關鍵字，情況就不同了： 
volatile int *p; 
int *q; 
......; 
*p = 1; 
*p = 2; 
*q = *p;
在這種情況下，編譯器看見*p是volatile的時候，就會： 

不對*p操作生成亂序指令（通常如此，具體請看後面的解釋） 

每次從*p取資料的時候，一定會進行一次訪存操作，哪怕前面不久才取過*p的值放在暫存器裡。 

不合並對*p的寫操作（也只是通常如此，解釋見後）
所以這回的結果如下（PowrPC彙編）： 
（假設r3=p，r4=q） 
li   r5, 1      // r5賦值1 
stw  r5, 0(r3)  // 把r5寫到*p 
li   r5, 2      // r5賦值2 
stw  r5, 0(r3)  // 把r5寫到*p 
lwz  r5, 0(r3)  // 從*p取值到r5 
stw  r5, 0(r4)  // 把r5寫到*q
這樣編譯器會在彙編碼級別保證指令有序和不優化掉訪存操作。通常簡單地使用volatile關鍵字就可以解決編譯器的亂序問題，但是這些指令到了處理器執行的時候，仍然可能被亂序。對於處理器亂序執行的避免就需要用到一組記憶體屏障函式（barrier）了。 
重要 
絕大多數的編譯器，通常不會優化掉對volatile物件的訪問，並且通常保持同一個volatile物件的一系列讀寫操作是有序的（但是不能保證不同的volatile物件之間有序）。 
但是，這不是絕對的。因為ANSI
C99標準關於對volatile物件訪問時編譯器是否要絕對保證禁止亂序（reorder）和禁止訪問合併（combine
access）並沒有做任何規定！僅僅是鼓勵編譯器最好不要去優化對volatile物件的訪問，而唯一的強制要求僅僅是要求編譯器保證對
volatile物件的訪問優化不會跨越“sequence point”即可（所謂sequence
point是指一些諸如外部函式呼叫、條件或迴圈跳轉等關鍵點，具體定義請查閱C99標準內的詳細說明）。 
這就是說，如果一個編譯器在兩個sequence point之間像對待普通變數一樣去優化volatile變數，也是完全符合C99標準的！比如：
volatile int a;
if (...) { ... }  // sequence point
a = 1;
a = 2;
a = 3;
printk("...");    // sequence point
在兩個sequence
point之間，要是有編譯器對a的賦值操作合併（即僅寫入3）或者亂序（如寫1和寫2對調），都是完全符合C99標準的。所以，我們在使用的時候，不能
指望用了volatile以後絕對能生成有序的完整的彙編碼，即不要指望volatile來保證訪存有序。實質上
volatile最大的作用主要還是在保證每次使用從記憶體中取值，而並不能保證編譯器不做其他任何優化（畢竟volatile從字面上看意思是“易變”而
不是“有序”。編譯器只保證對volatile物件即時更新但不保證訪問有序也不是說不過去的）。
從另一個角度看，即使是編譯器生成的彙編碼有序，處理器也不一定能保證有序。就算編譯器生成了有序的彙編碼，到了處理器那裡也拿不準是不
是會按照程式碼順序執行。所以就算編譯器保證有序了，程式設計師也還是要往程式碼裡面加記憶體屏障才能保證絕對訪存有序，這倒不如編譯器乾脆不管算了，因為記憶體屏障
本身就是一個sequence point，加入後已經能夠保證編譯器也有序。 
因此，對於切實是需要保障訪存順序的程式碼，就算當前使用的編譯器能夠編譯出有序的目標碼來，我們也還是必須通過設定記憶體屏障的方式來保證有序，否則都是不嚴謹，有隱患的。
Barrier屏障函式
Barrier函式可以在程式碼中設定屏障，這個屏障可以阻擋編譯器的優化，也可以阻擋處理器的優化。 
對於編譯器來說，設定任何一個屏障都可以保證： 

編譯器的亂序優化不會跨越屏障，即屏障前後的程式碼不會亂序； 

在屏障後所有對變數或者地址的操作，都會重新從記憶體中取值（相當於重新整理暫存器中的變數副本）。
而對於處理器來說，根據不同的屏障有不同的表現（以下僅僅列舉3種最簡單的屏障）： 

讀屏障rmb() 
處理器對讀屏障前後的取數指令（LOAD）能保證有序，但是不一定能保證其他算術指令或者是寫指令的有序。對於讀指令的執行完成時間也不能保證，即它不能保證在屏障之前的讀指令一定都執行完成，只能保證屏障之前的讀指令一定能在屏障之後的讀指令之前完成。 

寫屏障wmb() 
處理器對屏障前後的寫指令（STORE）能保證有序，但是不一定能保證其他算術指令或者是讀指令的有序。對於寫指令的執行完成時間也不能保證，即它不能保證在屏障之前的寫指令一定都執行完成，只能保證屏障之前的寫指令一定能在屏障之後的寫指令之前完成。 

通用記憶體屏障mb() 
處理器保障只有屏障之前的訪存操作（包括讀寫）都完
成以後才會執行屏障之後的訪存操作。即可以保障讀寫之間的有序（但是同樣無法保證指令完成的時
間）。這種屏障對處理器的執行單元效率產生的負面影響要比單純用讀屏障或者寫屏障來的大。比如對於PowerPC來說這種通用屏障通常是使用sync指令
實現的，在這種情況下處理器會丟棄所有預取的指令並清空流水線。所以頻繁使用記憶體屏障會降低處理器執行單元的效率。 
對於驅動開發者來說，一些對裝置暫存器的操作，通常是必須保證有序的。在絕大部分情況下，一般都是寫操作。對於有序的寫操作，必須設定寫屏障（wmb）： 
例：在驅動中使用寫屏障 
/* Mask out everything */ 
im_intctl->ic_simrh = 0x00000000; 
im_intctl->ic_simrl = 0x00000000;wmb();  /* Ack everything */ 
im_intctl->ic_sipnrh = 0xffffffff;
im_intctl->ic_sipnrl = 0xffffffff;
這是一個對中斷控制器操作的例子。在設定兩個mask暫存器的值的時候，這兩個寫操作沒有順序要求，因此可以不加屏障。但是對ack暫存器的設定必須在mask暫存器完成設定以後，所以在中間要加入寫屏障wmb()以保證對兩組暫存器的寫有序。 
同樣的，對於一系列的只讀操作，也可以簡單使用rmb()來保證有序。 
注意 
任何一個rmb()或者wmb()都是可以被替換成mb()的。但是因為上面提到過的mb()的效率問題，所以應該只有在同時需要讀屏障和寫屏障的
時候，才建議使用mb()。否則應該根據實際情況來選擇合適的屏障。當然，在裝置初始化的時候，即使是使用mb()也不會對效能帶來什麼影響，因為裝置一
般只會初始化一次。但是在發生很頻繁的裝置操作（比如網口的收發幀中斷等）時，應該考慮到mb()對效能的影響。 
如果驅動不僅僅需要在單純的讀指令或者寫指令之間有序，還需要保證讀寫指令之間有序的時候，就需要設定mb()屏障了。下面將演示一個這樣的例子： 
例：使用mb()屏障保證讀寫有序 
我們假設有一個裝置，在讀取裝置資訊時需要依次對REG1～3這三個暫存器進行寫入操作（寫入裝置讀取命令），然後才能依次讀取REG4和REG5取得裝置返回的資訊。 
REG1 = a; 
wmb();  // 保證REG1和REG2的寫有序
REG2 = b; 
wmb();  // 保證REG2和REG3的寫有序
REG3 = c;
mb();   // 保證在對裝置讀之前，前面的配置操作都完成（讀寫之間有序）
*d = REG4; 
rmb();  // 保證REG4和REG5的讀有序
*e = REG5;
mb();   // 保證與未來對裝置的操作有序 
return;

• 
  對於REG1～3的寫入，可以通過設定寫屏障來保證有序； 
  
• 
  在進行REG4和5的讀取之前，因為得保證前面的暫存器寫操作都執行完才能讀，所以需要設定一個記憶體屏障mb()來保證前面對暫存器的寫都完成，以保障讀寫指令之間的有序； 
  
• 
  後面兩個讀操作之間就可以通過設定讀屏障來保證有序了； 
  
• 
  最後通常在從裝置操作函式返回之前，我們一般需要保證對裝置的操作都執行完畢了。這樣下次對裝置進行操作的時候我們可以保證裝置已經完成了上次操作，避免反覆呼叫裝置操作函式帶來的函式間的亂序問題。所以在最後設定一個記憶體屏障mb()，保障和未來對裝置的其他訪問有序。