我對使用鎖定空閒隊列有疑問。關於鎖定空閒隊列的問題
假設我有一個單生產者單消費者隊列，其中 生產者和消費者綁定到單獨的核心。隊列元素 是共享內存的緩衝區，它在開始時由生產者和消費者兩者進行映射。
生產者獲得一個隊列元素，用數據填充緩衝區，然後 對它進行排隊，然後消費者將元素出隊，讀取它並以 以某種方式對其進行處理。
作爲無鎖隊列的用戶，我是否必須明確確保生產者編寫的緩衝區對用戶是可見的？或者算法核心的CAS（或其他類似的）基元自動提供 障礙嗎？
這兩個例子，我看到使用整數作爲有效載荷， 所以這個內存同步問題不會出現。
謝謝，
互鎖原語，如比較並交換一般有不同的存儲器阻擋語義變體。它們在架構之間有所不同，但通常您會希望（最遲）在生產者中使用「釋放」語義，使得結構對消費者可見，並且在您之前使用消費者中的「獲取」語義訪問數據結構。
在一些體系（特別是香草86）你實際上並沒有得到一個選擇，因爲每互鎖操作意味着一個完整的障礙 - 但如果你進入不要求任何障礙它將的習慣，由於墨菲，回來，咬你一些其他的建築。 （相反，如果您仔細研究選項並在各處插入正確的屏障，事件可能會共同使得您所編寫的任何代碼都不需要在x86以外的任何程序上運行）。
這個定義是特定於架構的。對於英特爾CPU上的GCC，使用GCC Atomic Builins--其中大部分意味着完全內存屏障。
一些結構與CAS的記憶障礙有聯繫; x86/x64是其中之一。
其他（ARM，例如）不。在ARM上，您執行LL/SC，前後只有手動數據存儲屏障。
作爲無鎖隊列的用戶，我是否必須明確確保生產者編寫的緩衝區對用戶是可見的？或者算法核心的CAS（或其他類似的）基元自動提供屏障？
從語義上講，推送數據到併發隊列應該至少有一個釋放欄，並且從隊列中彈出至少應該有一個獲取欄。我相信一個很好的無鎖實現不應該把關於內存隔離等問題強加給它的用戶。即使無鎖算法不會自動將柵欄放入適當的位置（或不適用於每種架構），實現（而不是用戶）必須確保正確的可見性和排序。用戶應該只關心選擇「正常工作」的實現（可能/必須包括測試它的工作原理）:)
已經回答了，有人可能會喜歡閱讀一次。 http://drdobbs.com/cpp/210600279 –