爲什麼我沒有看到IDisposable實現併發的任何實現？

Question

當我看看IDisposable的示例實現時，我沒有發現任何線程安全的。爲什麼IDisposable未實現線程安全？ （相反，呼叫者有責任確保只有一個線程呼叫Dispose()）。

Answer 1

Brian Lambert寫了一篇博文，標題爲A simple and totally thread-safe implementation of IDisposable。
它包含以下實現：

using System; 
using System.Threading; 

/// <summary> 
/// DisposableBase class. Represents an implementation of the IDisposable interface. 
/// </summary> 
public abstract class DisposableBase : IDisposable 
{ 
    /// <summary> 
    /// A value which indicates the disposable state. 0 indicates undisposed, 1 indicates disposing 
    /// or disposed. 
    /// </summary> 
    private int disposableState; 

    /// <summary> 
    /// Finalizes an instance of the DisposableBase class. 
    /// </summary> 
    ~DisposableBase() 
    { 
     // The destructor has been called as a result of finalization, indicating that the object 
     // was not disposed of using the Dispose() method. In this case, call the DisposeResources 
     // method with the disposeManagedResources flag set to false, indicating that derived classes 
     // may only release unmanaged resources. 
     this.DisposeResources(false); 
    } 

    /// <summary> 
    /// Gets a value indicating whether the object is undisposed. 
    /// </summary> 
    public bool IsUndisposed 
    { 
     get 
     { 
      return Thread.VolatileRead(ref this.disposableState) == 0; 
     } 
    } 

    #region IDisposable Members 

    /// <summary> 
    /// Performs application-defined tasks associated with disposing of resources. 
    /// </summary> 
    public void Dispose() 
    { 
     // Attempt to move the disposable state from 0 to 1. If successful, we can be assured that 
     // this thread is the first thread to do so, and can safely dispose of the object. 
     if (Interlocked.CompareExchange(ref this.disposableState, 1, 0) == 0) 
     { 
      // Call the DisposeResources method with the disposeManagedResources flag set to true, indicating 
      // that derived classes may release unmanaged resources and dispose of managed resources. 
      this.DisposeResources(true); 

      // Suppress finalization of this object (remove it from the finalization queue and 
      // prevent the destructor from being called). 
      GC.SuppressFinalize(this); 
     } 
    } 

    #endregion IDisposable Members 

    /// <summary> 
    /// Dispose resources. Override this method in derived classes. Unmanaged resources should always be released 
    /// when this method is called. Managed resources may only be disposed of if disposeManagedResources is true. 
    /// </summary> 
    /// <param name="disposeManagedResources">A value which indicates whether managed resources may be disposed of.</param> 
    protected abstract void DisposeResources(bool disposeManagedResources); 
} 

但是絕對和完整的整體是有爭議的評論了一下，無論在博客和這裏。

Answer 2

在完成之前，您不應該處置對象。如果有其他線程引用該對象，並且有可能需要調用它的方法，則不應該對其進行處理。

因此，Dispose不是必須的線程安全。

Answer 3

線程安全的Dispose模式的唯一真正好處是您可以保證在發生跨線程誤操作時獲得ObjectDisposedException而不是潛在的不可預知的行爲。請注意，這意味着該模式需要超過線程安全的Dispose;它要求所有依賴不被處置的類的方法與處理機制正確地互鎖。

可以做到這一點，但是要覆蓋只有在存在使用錯誤（即錯誤）時纔會發生的邊界情況是很費事的。

Answer 4

我不確定Microsoft爲什麼不在非虛擬處置方法中使用互鎖Disposing標誌（打算終結器 - 如果有的話 - 應該使用相同的標誌）。多線程可能嘗試處理對象的情況很少，但並不禁止。例如，可能會發生這樣的對象，它們應該執行一些異步任務並自行清理，但如果需要，可以儘早將其清除。對象處理不應該經常發生，因爲Interlocked.Exchange有任何有意義的性能成本。

。另一方面，需要注意的是，同時保護對處置多次調用是一個恕我直言明智的政策是非常重要的，它是不足以使處置真的是線程安全的。還有必要確保在正在使用的對象上調用Dispose會使事情處於良好狀態。有時最好的模式是設置一個「KillMeNow」標誌，然後在由Monitor.TryEnter守護的塊中，處理該對象。它使用該對象必須既獲取之前和解除鎖定，以查看是否KillMeNow被設定後，即可獲得操作期間的鎖，但是測試每例程（比其它處置）;如果是這樣，請執行Monitor.TryEnter並執行處理邏輯。

與進行線程安全的IDisposable更大的問題是，微軟並沒有指定一個事件的RemoveHandler方法必須是線程安全的了無死鎖的風險的事實。 IDisposable.Dispose經常需要刪除事件處理程序;如果沒有這種保證線程安全的方式，寫一個線程安全的Dispose幾乎是不可能的。