C＃ - 作為關鍵字真的需要“易變”嗎？

Question

當我更深入地閱讀volatile關鍵字的含義時，我不斷對自己說“這是實現的方式 ，這不應該是高級編程語言的一部分”。
我的意思是，CPU緩存數據的事實對於JIT編譯器應該是有趣的，而不是C＃程序員。

一個可觀的替代方案可能是屬性（例如， VolatileAttribute ）。

你怎么看？

Answer 1

我認為你是側面跟蹤的。 所有關於緩存等技術的東西都是嘗試用低級術語解釋它的一部分。 volatile的功能描述是“我可能會被共享”。 鑒於默認情況下線程之間沒有任何東西可以共享，這並不奇怪。 而且我認為基本上足以保證屬性上的關鍵字，但我認為它在很大程度上受到歷史決策的影響（C ++）

替換/優化它的一種方法是使用VolatileRead（）和VolatileWrite（）調用。 但這更像是“實施”。

Answer 2

嗯，我當然同意，這樣的實現細節暴露是非常可怕的。 然而，它與lock關鍵字所公開的完全相同。 我們仍然遠離該 bug生成器，從我們的代碼中完全刪除。

硬件人員有很多工作要做。 volatile關鍵字對許多具有弱內存模型的CPU內核很重要。 市場對他們並不友好，Alpha和Itanium表現不佳。 不完全確定原因，但我懷疑為這些內核編寫實線程代碼的難度與它有很大關系。 搞錯是調試的噩夢。 關於volatile的MSDN Library文檔中的措辭適用於這些類型的處理器，否則它對於x86 / x64內核來說是非常不合適的，並且使得關鍵字的效果遠遠超過實際情況。 Volatile僅防止變量值存儲在這些核心上的CPU寄存器中。

不幸的是，在非常精選的情況下，volatile仍然在x86內核上很重要 。 我還沒有找到任何證據表明它在x64核心上很重要。 據我所知，並且SSCLI20中的源代碼支持，Opcodes.Volatile指令是x64抖動的無操作，既不改變編譯器狀態也不改變任何機器代碼。 那是正確的方向。

通用建議是，無論您在考慮volatile，使用鎖或其中一個同步類都應該是您的首要考慮因素。 避免他們嘗試優化您的代碼是微觀優化，當您的程序出現線程競爭問題時，您將失去的睡眠數量會失敗。

Answer 3

使用屬性是可以接受的，如果是相反的方式，也就是說，編譯器會假設所有變量都是易失性的，除非明確標記了一個屬性，說它是安全的。 這對於表現來說是非常不利的。

因此，假設由於在編譯器視圖之外更改了變量的值是一種異常，編譯器會認為它沒有發生。

但是，這可能發生在一個程序中，因此語言本身必須有一種方式來表明這一點。

此外，您似乎對“實施細節”感到困惑。 該術語指的是編譯器背后的事情。 這不是這種情況。 您的代碼正在修改編譯器視圖之外的變量。 它是在你的代碼中，它將永遠是真的。 因此，語言必須能夠表明這一點。

Answer 4

IIIRC，在C ++中volatile主要是關於內存映射的I / O而不是緩存。 如果您兩次閱讀相同的端口，您會得到不同的答案。 不過，我同意你的評估，即在C＃中作為屬性更清晰地表達。

另一方面，C＃中volatile的大多數實際用途無論如何都可以更好地理解為線程鎖定，因此volatile的選擇可能有點不幸。

編輯 ：只是添加：兩個鏈接顯示在C / C ++中`volatile 明確 不是用於多線程。

Answer 5

c＃中的volatile會發出正確的障礙或柵欄，這對程序員進行多線程工作很重要。 請記住，編譯器，運行時和處理器都可以在某種程度上重新排序讀/寫（每個都有自己的規則）。 雖然CLR 2.0具有比EC ECMA指定的更強的內存模型，但CLR內存模型仍然不是最嚴格的內存模型，因此您需要在C＃中使用volatile 。

作為屬性，我認為您不能在方法體內使用屬性，因此關鍵字是必需的。