這一文，讓我們分析一下，《淺談 Cache》 一文中的奇怪現象，事實上如今來看也并不奇怪了。
? ? ? ? 在什么情況下 r1 和 r2 都為 0 呢？
? ? ? ? 細致看代碼，你會發現，兩個線程分別被執行在不同的 CPU 核上，而且在線程開始的階段還使用了一個隨機數，是為了讓兩個線程能盡量同一時候執行。
? ? ? ? 如果 CPU0 執行：
? ? ? ? x = 1;
? ? ? ? r1 = y;
? ? ? ? CPU1 執行:
? ? ? ? y = 1;
? ? ? ? r2 = x;
? ? ? ? 假設以下的情況發生：
? ? ? ? x 在 CPU1 的 Cache 中。 y 在 CPU0 的 Cache 中。
? ? ? ? 1. CPU0 運行 x = 1, cache miss, 發送 "read invalidate" 消息，并把 x 的值 1 存入 Store Buffer， 開始運行 r1 = y, Cache 命中，r1 為 0;
? ? ? ? 2. CPU1 運行 y = 1，cache miss, 發送 "read invalidate" 消息，并把 y 的值 1 存入 Store Buffer, 開始運行 r2 = x，Cache 命中，r2 為 0;
? ? ? ? 3. CPU0 和 CPU1 各自收到了對方的消息，并作出回應，x 和 y 的值均應用到 Cache 中，且都為 1;
? ? ? ? 主函數收到信號，比較 r1 和 r2 的值，奇跡發生了。
? ? ? ? 假設你知道我講的這些細節，就會發現，事實上這并非奇怪了。那么假設解決問題呢？
? ? ? ? 事實上答案就非常easy了，要么讓兩個線程執行在同一個核心上，要么在兩個語句之間加上內存屏障，經驗證，問題攻克了。
? ? ? ? 題外篇：
? ? ? ? 在不同 CPU 架構下，對內存的亂序訪問事實上是不同的，一般的內存亂序分為下面四種:
? ? ? ? LoadStore, LoadLoad, StoreStore, StoreLoad。而且 X86 下僅僅會出現 StoreLoad 亂序，也就是上面的樣例，我的 CPU 是 X86 的，所以出現了這樣的情況，由此可知，事實上 X86 內存亂序訪問的還不算太厲害。
? ? ? ? 簡單解釋一下，x = 1，為 Store, 讀取 y 的過程為 Load，所以 Load 指令在 X86 下同意在 Store 還未更新到 Cache 中之前被運行。
? ? ? ? 走出一個誤區，內存亂序訪問與 CPU 亂序運行（Out of Order，即 OOO）不同。
早期的處理器為有序處理器（In-order processors），有序處理器處理指令通常有下面幾步：
? ? ? ? 1. 指令獲取
?
? ? ? ? 相比之下，亂序處理器（Out-of-order processors）處理指令通常有下面幾步：
? ? ? ? 1. 指令獲取
? ? ? ? 2. 指令被分發到指令隊列
? ? ? ? 3. 指令在指令隊列中等待，直到輸入操作對象可用（一旦輸入操作對象可用，指令就能夠離開隊列，即便更早的指令未被運行）
? ? ? ? 4. 指令被分配到適當的功能單元并運行
? ? ? ? 5. 運行結果被放入隊列（而不馬上寫入寄存器堆）
? ? ? ? 僅僅有全部更早請求運行的指令的運行結果被寫入寄存器堆后，指令運行的結果才被寫入寄存器堆（運行結果重排序，讓運行看起來是有序的）
? ? ? ? 從上面的運行過程能夠看出，亂序運行相比有序運行能夠避免等待不可用的操作對象（有序運行的第二步）從而提高了效率。現代的機器上，處理器運行的速度比內存快非常多，有序處理器花在等待可用數據的時間里已經能夠處理大量指令了。
? ? ? ? 如今思考一下亂序處理器處理指令的過程，我們能得到幾個結論：
? ? ? ? 對于單個 CPU 指令獲取是有序的（通過隊列實現）
? ? ? ? 對于單個 CPU 指令運行結果也是有序返回寄存器堆的（通過隊列實現）
? ? ? ? 由此可知，在單 CPU 上，不考慮編譯器優化導致亂序的前提下，多線程運行不存在內存亂序訪問的問題
? ? ? ? CPU 盡管是亂序運行，可是是順序流出結果，在我們看來，亂序運行對我們來講是透明的，我們看到的結果和指令順序是一樣的。
? ? ? ? 在什么情況下 r1 和 r2 都為 0 呢？
? ? ? ? 細致看代碼，你會發現，兩個線程分別被執行在不同的 CPU 核上，而且在線程開始的階段還使用了一個隨機數，是為了讓兩個線程能盡量同一時候執行。
? ? ? ? 如果 CPU0 執行：
? ? ? ? x = 1;
? ? ? ? r1 = y;
? ? ? ? CPU1 執行:
? ? ? ? y = 1;
? ? ? ? r2 = x;
? ? ? ? 假設以下的情況發生：
? ? ? ? x 在 CPU1 的 Cache 中。 y 在 CPU0 的 Cache 中。
? ? ? ? 1. CPU0 運行 x = 1, cache miss, 發送 "read invalidate" 消息，并把 x 的值 1 存入 Store Buffer， 開始運行 r1 = y, Cache 命中，r1 為 0;
? ? ? ? 2. CPU1 運行 y = 1，cache miss, 發送 "read invalidate" 消息，并把 y 的值 1 存入 Store Buffer, 開始運行 r2 = x，Cache 命中，r2 為 0;
? ? ? ? 3. CPU0 和 CPU1 各自收到了對方的消息，并作出回應，x 和 y 的值均應用到 Cache 中，且都為 1;
? ? ? ? 主函數收到信號，比較 r1 和 r2 的值，奇跡發生了。
? ? ? ? 假設你知道我講的這些細節，就會發現，事實上這并非奇怪了。那么假設解決問題呢？
? ? ? ? 事實上答案就非常easy了，要么讓兩個線程執行在同一個核心上，要么在兩個語句之間加上內存屏障，經驗證，問題攻克了。
? ? ? ? 題外篇：
? ? ? ? 在不同 CPU 架構下，對內存的亂序訪問事實上是不同的，一般的內存亂序分為下面四種:
? ? ? ? LoadStore, LoadLoad, StoreStore, StoreLoad。而且 X86 下僅僅會出現 StoreLoad 亂序，也就是上面的樣例，我的 CPU 是 X86 的，所以出現了這樣的情況，由此可知，事實上 X86 內存亂序訪問的還不算太厲害。
? ? ? ? 簡單解釋一下，x = 1，為 Store, 讀取 y 的過程為 Load，所以 Load 指令在 X86 下同意在 Store 還未更新到 Cache 中之前被運行。
? ? ? ? 走出一個誤區，內存亂序訪問與 CPU 亂序運行（Out of Order，即 OOO）不同。
早期的處理器為有序處理器（In-order processors），有序處理器處理指令通常有下面幾步：
? ? ? ? 1. 指令獲取
? ? ? ? 2. 假設指令的輸入操作對象（input operands）可用（比如已經在寄存器中了），則將此指令分發到適當的功能單元中。假設一個或者多個操作對象不可用（一般是因為須要從內存中獲取），則處理器會等待直到它們可用；
? ? ? ? 3. 指令被適當的功能單元運行
? ? ? ? 4. 功能單元將結果寫回寄存器堆（Register file，一個 CPU 中的一組寄存器）?
? ? ? ? 相比之下，亂序處理器（Out-of-order processors）處理指令通常有下面幾步：
? ? ? ? 1. 指令獲取
? ? ? ? 2. 指令被分發到指令隊列
? ? ? ? 3. 指令在指令隊列中等待，直到輸入操作對象可用（一旦輸入操作對象可用，指令就能夠離開隊列，即便更早的指令未被運行）
? ? ? ? 4. 指令被分配到適當的功能單元并運行
? ? ? ? 5. 運行結果被放入隊列（而不馬上寫入寄存器堆）
? ? ? ? 僅僅有全部更早請求運行的指令的運行結果被寫入寄存器堆后，指令運行的結果才被寫入寄存器堆（運行結果重排序，讓運行看起來是有序的）
? ? ? ? 從上面的運行過程能夠看出，亂序運行相比有序運行能夠避免等待不可用的操作對象（有序運行的第二步）從而提高了效率。現代的機器上，處理器運行的速度比內存快非常多，有序處理器花在等待可用數據的時間里已經能夠處理大量指令了。
? ? ? ? 如今思考一下亂序處理器處理指令的過程，我們能得到幾個結論：
? ? ? ? 對于單個 CPU 指令獲取是有序的（通過隊列實現）
? ? ? ? 對于單個 CPU 指令運行結果也是有序返回寄存器堆的（通過隊列實現）
? ? ? ? 由此可知，在單 CPU 上，不考慮編譯器優化導致亂序的前提下，多線程運行不存在內存亂序訪問的問題
? ? ? ? CPU 盡管是亂序運行，可是是順序流出結果，在我們看來，亂序運行對我們來講是透明的，我們看到的結果和指令順序是一樣的。
