它看起來像單實施具有ReaderWriterLockSlim
方法內沒有MemoryBarrier
電話。因此,當我在write lock
內進行任何更改時,我可以在使用read lock
的另一個線程中接收舊的緩存值。我是否需要使用ReaderWriterLockSlim的MemoryBarrier?
真的有可能嗎?我應該在讀寫鎖內的代碼前後插入MemoryBarrier
嗎?
它看起來像單實施具有ReaderWriterLockSlim
方法內沒有MemoryBarrier
電話。因此,當我在write lock
內進行任何更改時,我可以在使用read lock
的另一個線程中接收舊的緩存值。我是否需要使用ReaderWriterLockSlim的MemoryBarrier?
真的有可能嗎?我應該在讀寫鎖內的代碼前後插入MemoryBarrier
嗎?
看着(我的想法是)the mono source,單聲道ReaderWriterLockSlim
是使用Interlocked
調用實現的。
這些調用include a memory barrier on x86,所以你不應該需要添加一個。
正如Peter正確指出的那樣,該實現的確引入了內存障礙,但並不明確。
更一般地說:C#語言規範要求某些副作用在鎖定方面排序良好。雖然該規則僅適用於使用C#lock
語句輸入的鎖,但自定義鎖定基元的提供者使鎖定對象不遵循相同規則將會非常奇怪。你明智的做法是仔細檢查,但總的來說,你可以假設如果它是一個線程原語,那麼它的設計就是確保重要的副作用在它周圍是有序的。
有一些CPU,可以有一個CAS沒有記憶障礙,但他們是相當罕見的,我想即使他們有記憶障礙CAS形式,只是還沒有CAS當你真的想在併發了極致。 –