1樓：Starve Jokes
所以說了100遍了，研究東西去看最新的production級別的code和追mail list（其實都可以用google做到），去看官方資料(Intel Software Develop Manual一類的)和權威資料
不要看10+年前的code，更不要看那種解析10+年前的code的作者功力還不知道如何的書。（比如某些linux 0.11啦，什麼剖析stl啦）
2樓：神奇先生
sfence和lfence這兩個是intel x86指令集裡最沒用的兩個指令。因為他們毫無用處，等價於noop。x86的load和store都是ordered。
實現C++裡面的acquire release semantics只需要compiler barrier就行，只要compiler不reorder，x86是永遠不會reorder你的load和store的。
3樓：
不要動不動想搞個大新聞。你說它有 bug，而且還是這麼嚴重的 bug，乙個可靠的外部鏈結都不給，反正我是不信的。
首先，不要簡單地拿著非專門描述 x86 的教科書的知識，或者拿著 ARM、MIPS 的經驗來判斷 x86，x86 的那套指令集，奇葩特性一大堆，一切問題請以 Intel 開發者手冊為準。
要知道現在intel cpu都是支援多發射支援亂序執行的
這句話正確，但不重要。亂序執行是內部實現，指令集是它的對外介面，寫程式的人應該清楚實現與介面的區別吧。除了手冊中列出的兩種特例以外，x86 都保證單處理器環境下乙個核的寫操作以程式順序對其他核可見，見第三卷 8.
2.2：
Writes to memory are not reordered with other writes, with the following exceptions:
— streaming stores (writes) executed with the non-temporal move instructions (MOVNTI, MOVNTQ, MOVNTDQ, MOVNTPS, and MOVNTPD); and
— string operations (see Section 8.2.4.1).
多處理器的環境下：
Writes by a single processor are observed in the same order by all processors.
這意味著，在使用者態程式裡，絕大部分情況下，除了 non-temporal 儲存指令和 REP S 指令，無需使用 fence 指令來保證多核之間的一致性，而只需要在必要的時候阻止編譯器的亂序優化（asm volatile ("" ::: "memory");）。
手冊裡這句話出現了好多遍：
The SFENCE, LFENCE, and MFENCE instructions provide a performance-efficient way of ensuring load and store memory ordering betweenroutines that produce weakly-ordered resultsand routines that consume that data.
就寫乙個使用者態的庫而已，哪有那麼多機會 product weakly-ordered results。一般使用者態的庫也沒有誰要像核心考慮一些少見的有 bug 的 CPU 型號（核心連某些早已絕跡的 HLT 指令有 bug 的 CPU 都考慮了），也沒有諸如 DMA 之類的那些各種情況，沒那麼多需要顯式使用 fence 指令的情形。
不要太看不起 libstdc++ 和 boost 的作者了好不好？？
【最後強調一遍，以上描述僅適用於 x86，不適用於 ARM、MIPS 等使用更弱的記憶體模型的架構。弱記憶體模型架構下，寫乙個涉及多執行緒的底層使用者態庫，需要顯示 fence 的地方確實是不少的。】
c 基於zookeeper的配置工具應如何設計（類似curator的treeCache）？
譚正中 ZooKeeper的讀效能目前一般的機器都能有10 20W吧，讀效能應該不存在問題。看你們配置管理的讀取效能要求了。第乙個問題，你可以根據你自己的業務來，我們自己是使用std unordered map或者std list儲存節點資料的，因為只有一層。第二個問題，對於C 使用ZooKeepe...
請問C 的圖形庫都是基於Windows提供的GDI函式實現的嗎？
lhelpme gdi只能畫畫winform ui 更底層可以依賴 dx 或者opengl 做UI渲染vector 圖計算可以另外搞庫 例如chrome 的skia 粉蒸排骨 請問C 的圖形庫都是基於Windows提供的GDI函式實現的嗎？Linux 情何以堪？OpenGL 情何以堪？X Windo...
為什麼說基於RISC V 不適合研發高效能CPU？
moonlight 你可以說當前riscv還沒有高效能領域的CPU實現，但不能說riscv這套指令集不適合用來做高效能領域的CPU。非要扯乙個應該是當前還沒有官方版的simd？ 高效能CPU分兩類一種是面向超算一種是桌面 移動端通用 如果走超算路線 riscv還是可能的 畢竟原生指令條數本身就不多，...