ReaderWriterLockSlim是否對ThreadAbortException有抵抗力？

Question

我想檢查以下代碼是否抵抗ThreadAbortException並且不會導致孤立鎖定。 如果不是，那么避免孤兒鎖定的最佳模式是什么？

ReaderWriterLockSlim _lock = new ReaderWriterLockSlim();

public void DoStaff()
{
  _lock.EnterWriteLock();
  //Is this place where ThreadAbotException can corrupt my code, or is there JIT optimalization which prevent this from happening??? 
  try
  {
    ...
  }
  finally
  {
    _lock.ExitWriteLock();
  }
}

根據以下鏈接http://chabster.blogspot.cz/2013/07/a-story-of-orphaned-readerwriterlockslim.html ，有（或至少有）可能的方法如何創建孤兒鎖，但我正在運行示例代碼一段時間沒有任何運氣。

我使用的是.NET 4.0

Debug和Release中的行為有什么區別嗎？

Answer 1

是的， ThreadAbortException可能在那里發生，在這種情況下不會輸入try ，因此你永遠不會退出寫鎖。

這個問題沒有很好的通用解決方案。 這就是為什么Eric Lippert（以及其他人）說Locks和例外不混合的原因 。

你特別詢問ThreadAbortException ，這讓我相信你正在考慮在你的應用程序中使用Thread.Abort進行某種線程控制。 我勸你重新考慮一下。 如果你想要取消你的線程，你應該使用取消或類似的東西。 在最嚴峻的情況下使用Thread.Abort是一個可怕的壞主意。 它當然不應該是您的程序整體設計的一部分。

Answer 2

為了使得使用鎖定原語的代碼在線程中止時是健壯的，每個鎖定獲取和鎖定釋放請求必須通過或者通過非共享令牌執行，該令牌可以被賦予“所有權”。鎖。 根據鎖定API的設計，令牌可以是某種特定類型的Object ，任意Object或作為ref參數傳遞的變量。 然而，必須在獲取鎖之前通過某種方式創建和存儲令牌，以便如果令牌被創建但存儲失敗，則可以毫無困難地放棄令牌。 不幸的是，盡管監視器鎖已經添加了（在.NET 4.0中）使用ref bool作為令牌的Monitor.Enter和Monitor.TryEnter重載，但我知道沒有讀寫器鎖的等價物。

如果想要一個中止安全的讀寫器鎖定功能，我建議你需要一個圍繞它設計的類; 它應該跟蹤哪些線程持有讀取器或寫入器訪問權限，而不是依賴線程來釋放鎖，它應該在等待釋放鎖時，確保持有它的線程仍然存活。 如果線程在保持讀訪問權限時死亡，則應該釋放它。 如果線程在持有正確訪問權限時死亡，則任何未決或將來嘗試獲取鎖定都應立即引發異常。

否則，有一些技巧可以保護代碼塊免受Thread.Abort() 。 不幸的是，我不知道任何干凈的方法來圍繞鎖定獲取請求包含代碼，以便當請求本身可以在沒有成功的情況下干凈地中止時Abort將工作，但是如果請求成功則將延遲。

有一些方法可以使框架安全地允許無限循環中的線程被另一個線程殺死，但是設計可以安全使用的機制需要比放入Thread.Abort()更多的努力。