1樓：
剛才上廁所的時候想了一下這個問題。
對於 barrier，解決的問題之一就是所謂的 cache coherency problem。就是說在乙個多核心的機器上，每個核心有自己的 cache，但是它們共享一片記憶體區域。那麼就有可能出現這樣一種情況：
核心 A 更新了自己的 cache，但是這個更新的值還沒 flush 到那片共享的記憶體上，也就是說處理器看不見這個更新的值。
假設核心 A 先更改了某個變數 x 之後更改了 y。這些值需要 flush 到記憶體中別的處理器才會發覺值變了。那麼就有可能它先把 y 的值 flush 到記憶體中。
這樣就導致核心 B 發現先更新了 y。哎呀，這樣就不好玩了。。。
再回來看這裡。第二個 barrier 僅僅保證的是在本執行緒內，初始化的寫先於 m_instance，並不保證對於其他執行緒也是這樣的。這時候，可能 m_instance 在記憶體中的更新先於其指向的物件（物件的成員更新可能僅僅是在 A 的 cache 中，還沒 flush 或者沒有完全 flush）。
這時另乙個核心 B 發現，哦，m_instance 還沒空，返回了乙個還沒初始化的物件的指標。這個 barrier 保證了讀取 m_instance 的時候其初始化的寫已經進入記憶體中。
這個文章說得很好！
Reordering on an Alpha processor不保證對哈，錯了請指點糾正。
2樓：叛逆者
其實，std::atomic_thread_fence那兩條都不是必須的。第乙個load的引數改成std::
memory_order_consume，最後store的引數改成std::memory_order_release，就相當於內建fence了。這些都是為了保證編譯後產生的讀寫順序跟預期一致。
詳情看我的文章 C++中線程安全並且高效的singleton
3樓：
（DISCLAMER: 錯了別怪我）
首先，我們要知道，編譯器是個一根筋的傢伙，所有的優化都是基於單執行緒的。
其次，編譯器會優化、摺疊一些變數，減少對記憶體的訪問。
所以在我們的問題裡，第乙個barrier的作用是防止編譯器把get_instance摺疊掉，將每次必要的函式呼叫摺疊成暫存器訪問。
4樓：
首先，一道check肯定是需要的對吧？
然後，外面那一道是為了避免不必要的加鎖吧，加鎖還是很費時間的。
複雜的是同步操作，要避免編譯器級別和指令級別的亂序執行造成的同步問題
5樓：盧旺杉
C++11直接用
static
Singleton
&get_instance
()編譯器會幫你處理race的問題。
另外推薦盡量少用singleton，沒有多少情況是必須的。
Go中，使用runtime Gosched，time Sleep哪個效能更好？
成雋 sleep不精確啊。https 這個bug已經留了2個大版本還沒解決。 假裝懂程式設計 從cpu利用率來說runtime.Gosched應該更好吧，都是讓出cpu，runtime.Gosched讓出後，後續交給go本身的runtime去排程，不需要像sleep那樣自己定義time，runtim...
Material Design的插圖中使用的陰影是如何製作的？
鑑於這個問題也算是晾了一段時間，我自己也來新增乙個官方的部落格文章 https 題目叫鹽和胡椒，說明了谷歌設計師為實現這一特殊高光及陰影效果所使用的一些方法，也比較有參考價值。 Wongbo 瀉藥 這個絕對不是普通雜色修改透明度和顏色混合模式搞定的。我個人比較喜歡在 Ps 內完成這個噪點效果，在 P...
為什麼在 Mathematica 中使用迴圈是低效的？
yi feng 沒用過該軟體，僅從寫程式的角度來回答這個問題，若有偏頗或者錯誤請提醒或者摺疊。程式都有空間與時間之間的矛盾，也就是說某種資料結構及演算法在面對不同型別問題時不可能總是最省記憶體又算得最快的，但在面對某一類問題時是最好的。同一問題，該軟體有多種寫法，不同寫法在內部由不同演算法和資料結構...