簡介 C++11 atomic 和 memory order
前一篇文章是以一個小例子從開發者的角度，從上層到下層說明 thread 之間何時會同步資料。這篇只從 C++ 的角度討論 C++11 訂的 API。
Architectures (e.g., x86, ARM) 為了提升效率，會作許多事，這裡借用《C++ and Beyond 2012: Herb Sutter — atomic<> Weapons》的圖：
從上表可知，有些最佳化會影響到程式執行的效果：
- CPU 會調整指令執行順序 (out-of-order execution)。
- CPU 會從 cache 讀資料。
- CPU 各自有 store buffer，CPU 之間不會立即看到其它 CPU 的更新。
上述操作和 Memory model 有關。Memory model 討論 thread 或 CPU (看是從程式語言或 architectures 的角度看) 如何同步資料 (會被上述幾件事影響)，並提供 API 讓開發者寫 multi-thread 程式的時候可以保證程式正確 。
在 C++11 定義 memory model 以前，開發者得自己用 Architectures 提供的 API，不同平台都要作一次，很累也容易出錯。有了 C++ 11 memory model，開發者只要用 C++11 提供的 API 寫一次就好了，剩下的就交給 compiler 去煩惱吧。
C++11 提供許多方法同時解決上面說的問題，像是易於使用的 mutex 和高效能的 atomic。mutex 很好理解，以下我們將重點放在 atomic。
atomic 的 load 和 store 本身是 atomic operation (不見得是 lock-free，可用 is_lock_free 確認)。確保 atomic variable 的 load 會讀到 store 寫入最新的值，並且 load/store 之間沒有 data race。舉例來說，在 32-bit architecture 上需要兩個指令才能寫入 int64_t，所以讀 int64_t 變數的時候可能會讀到寫到一半的結果。型別改用 std::atomic<std::int64_t> 的話，可以確保 load 不會讀到不完整的更新。
此外，load/store 帶有參數 memory_order 影響其它非 atomic 資料同步的情況。後面簡述 memory_order 的效果。
memory_order_relaxed
memory order 沒有額外保證。準官方文件有個有趣的例子：
// Thread 1:
r1 = y.load(memory_order_relaxed); // A
x.store(r1, memory_order_relaxed); // B
// Thread 2:
r2 = x.load(memory_order_relaxed); // C
y.store(42, memory_order_relaxed); // D程式結果有可能是 r1 == r2 == 42。我的理解是 C 和 D 可以互調順序 (這樣沒改變 single thread 執行時的語意)，互調後有可能造成 r1 == r2 == 42。
memory_order_consume
和 memory_order_acquire 功用相似，但對 architecture 的限制比較弱 (有更多最佳化空間)。但是直到 2016/06 的進展，全部 compiler 的實作都將 memory_order_consume 當作 memory_order_acquire，詳見《P0371R1: Temporarily discourage memory_order_consume》 (感謝 Scott 告知)。
關於 memory_order_consume 的語意和優勢，詳見《The Purpose of memory_order_consume in C++11》和 《N1525: Memory-Order Rationale》 舉的例子。
memory_order_acquire 和 memory_order_release
這兩個 order 要一起使用。假設 thread 1 使用 load-acquire X，thread 2 使用 store-release X。合起來的效果是：
- thread 1 load-acquire 之後可以看見 thread 2 store-release 之前寫入的資料。
- thread 1 load-acquire 之後的 read/write 不能搬到 load-acquire 之前。
- thread 2 store-release 之前的 read/write 不能搬到 store-release 之後。
三者合在一起才有效果，所以有這樣的限制滿合理的。注意這個同步是所有用 X 的 thread 都有效。一個 thread store-release X，兩個 thread load-acquire X，結果是這三個 thread 都會看到第一個 thread 寫入 X 以及 store-release 之前寫入的值。更詳細的說明可以參考《Acquire and Release Semantics》，這位作者寫了許多簡短易懂的介紹。
memory_order_acq_rel
同時有 acquire + release。
memory_order_seq_cst
預設值，用起來和 single thread 一樣，效果最強。附帶一提，atomic::operator= 和 atomic::store() 等價。
聽 Scott 說這個限制太強，和 architectures 運作方式差太多，有些情境可能會比 mutex 還慢。比方說 critical section 內有多個變數，考慮兩個作法：
- 用 mutex 保護，只作一次 acquire lock、一次 release lock。
- 變數都宣告成 atomic，然後 load/store 的 memory order 用 memory_order_seq_cst。
結果 1 可能會比 2 快，因為 2 要求太多不必要的資料同步，而同步資料的代價頗高的。一知半解的人可能會真的這麼作，需要留意一下。
結語
這裡都是從 C++11 的角度來看，compilers 依平台可能會提供更強的限制。看的時候不要管各個 architectures 如何運作，會比較容易理解。
C++11 atomic 還有提供 atomic_thread_fence，有多個 atomic operation 的時候，讓 atomic operation 使用 memory_order_relaxed，然後配上一個 fence 使用 memory_order_acquire/memory_order_release 會比較有效率。《N1525: Memory-Order Rationale》有個 C 的例子：
不過我覺得 load/store 直接使用 non- relaxed memory order 比較容易理解，這裡不深入討論 atomic_thread_fence，也可以參考《Acquire and Release Fences Don’t Work the Way You’d Expect》和 cppreference。。
總結來說：
- 只需要單一變數是 atomic 也不關心前後資料同步的話，用 load/store 配 memory_order_relaxed (使用情境: 自己實作 shared pointer 的 reference count)。
- 需要同步某個區塊的話用 load-acquire + store-release，同時影響程式執行順序和資料同步的時機。
- 怕寫錯就用 mutex 吧，可以少煩惱很多事。
