¿Por qué no he visto ninguna implementación de concurrencia de implementación IDisposable?

Question

Cuando miro a través de implementaciones de muestra de IDisposable, no he encontrado ninguno que sea seguro para la tarea. ¿Por qué IDisposable no está implementado para seguridad de hilos? (En cambio, quienes llaman tienen la responsabilidad de asegurarse de que solo un hilo llame al Dispose()).

Answer 1

Brian Lambert escribió una publicación de blog titulada A simple and totally thread-safe implementation of IDisposable.
, incluye la siguiente aplicación:

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); 
} 

Sin embargo, la totalidad absoluta y completa se disputa un poco en los comentarios, tanto en el blog y aquí.

Answer 2

No debe deshacerse de un objeto hasta que haya terminado con él. Si hay otros hilos que hacen referencia al objeto y existe la posibilidad de que quieran llamar a sus métodos, no debería deshacerse de él.

Por lo tanto, no es necesario que el Dispose sea seguro para subprocesos.

Answer 3

El único beneficio real para un patrón Dispose seguro de subprocesos es que se le puede garantizar que obtenga una ObjectDisposedException en lugar de un comportamiento potencialmente impredecible en caso de mal uso de hilos cruzados. Tenga en cuenta que esto significa que el patrón requiere más de un desecho seguro para hilos. requiere que todos los métodos que dependen de que la clase no esté Dispuesta se entrelacen adecuadamente con el mecanismo de Eliminación.

Es posible hacer esto, pero es un gran esfuerzo cubrir un caso límite que solo ocurre si hay un error de uso (es decir, un error).

Answer 4

No estoy seguro de por qué Microsoft no utiliza un indicador de Disposición interbloqueado en el método de disposición no virtual (con la intención de que un finalizador, si lo hubiera, use el mismo indicador). Las situaciones en las que varios hilos pueden intentar deshacerse de un objeto son raras, pero no están prohibidas. Podría ocurrir, por ejemplo, con objetos que se supone que realizan alguna tarea asincrónica y limpian después de ellos mismos, pero que pueden eliminarse temprano si es necesario. La eliminación de objetos no debe ocurrir con la frecuencia suficiente para que un Interbloque.Exchange tenga un costo de rendimiento significativo.

Por otro lado, es importante tener en cuenta que, si bien proteger Dispose contra múltiples invocaciones es una política acertada en mi humilde opinión, no es suficiente hacer que Dispose realmente sea seguro para subprocesos. También es necesario asegurarse de que llamar a Dispose en un objeto que está en uso deje las cosas en buen estado. A veces, el mejor patrón para esto es disponer de un marcador "KillMeNow" y luego en un bloque protegido por Monitor.TryEnter, desechar el objeto. Cada rutina (que no sea Dispose) que utiliza el objeto debe adquirir el bloqueo durante la operación, pero pruebe ambos antes de adquirir y después de soltar el bloqueo para ver si KillMeNow está configurado; si es así, haga un Monitor.TryEnter y realice la lógica de eliminación.

Un problema mayor al hacer que un hilo seguro es identificable es el hecho de que Microsoft no especifica que el método RemoveHandler de un evento debe ser seguro para subprocesos sin riesgo de interbloqueo. Con frecuencia es necesario para un IDisposable. Desea eliminar los controladores de eventos; sin una forma segura de hacer thread-safe, es casi imposible escribir un Dispose seguro para subprocesos.