Was ist die richtige Art von hinzufügen thread-Sicherheit auf ein IDisposable-Objekt?

Die einfachste Sache, die Sie tun können, ist daneben die privaten entsorgt variable als volatile und überprüfen Sie es am Anfang Ihrer Methoden. Sie können dann werfen Sie einen ObjectDisposedException wenn das Objekt bereits veräußert worden.

Gibt es zwei Vorbehalte zu diesem:

1. Sollten Sie nicht throw eine ObjectDisposedExceptionwenn die Methode als event-handler. Stattdessen sollten Sie nur anmutig Ausstieg aus der Methode, wenn das möglich ist. Der Grund dafür ist, dass es existiert eine race condition, wo Ereignisse ausgelöst werden können, nachdem Sie sich davon Abmelden. (Siehe dieser Artikel von Eric Lippert für weitere Informationen.)

2. Diese nicht aufhören, Ihre Klasse aus wird entsorgt, während Sie in der Mitte der Ausführung eines Ihrer Klasse Methoden. Also, wenn Ihre Klasse-Instanz-Mitglieder kann nicht zugegriffen werden, nach der Entsorgung, sind Sie gehen zu müssen, um das setup einige locking-Verhalten zu gewährleisten, dass der Zugang zu diesen Ressourcen gesteuert werden.

Microsoft-Führung um IDisposable sagt, Sie sollten prüfen, die darauf angeordnet sind sämtliche Methoden, aber ich habe keine persönlich fand dies für notwendig. Die Frage ist wirklich, ist etwas, das werfen einer exception oder die Ursache für unbeabsichtigte Nebenwirkungen, wenn Sie zulassen, dass eine Methode ausgeführt werden, nachdem die Klasse entsorgt wird. Wenn die Antwort ja ist, werden Sie brauchen, um einige Arbeit zu tun, um sicherzustellen, dass das nicht passiert.

In Bezug auf, ob alle IDisposable-Klassen sollte thread-sicher: Nein. Die meisten Anwendungsfälle für Einweg-Klassen umfassen Sie immer nur zugegriffen, die von einem einzelnen thread.

Dass gesagt wird, Sie Mai wollen untersuchen, warum Sie benötigen, um Ihre Einweg-Klasse thread-sicher, wie es fügt eine Menge zusätzliche Komplexität. Gibt es vielleicht eine Alternative Implementierung erlaubt, dass Sie nicht haben, um sorgen um die thread-Sicherheit in Ihre Einweg-Klasse.

Ich Neige dazu, verwenden Sie eine ganze Zahl statt einer boolean als Ihr Feld für die Speicherung der entsorgt status, weil Sie dann verwenden können, die thread-safe-Interlocked-Klasse zu testen, ob Dispose bereits aufgerufen wurde.

Etwas wie dieses:

private int _disposeCount;

public void Dispose()
{
    if (Interlocked.Increment(ref _disposeCount) == 1)
    {
        //disposal code here
    }
}

Dadurch wird sichergestellt, dass die Entsorgung der code wird nur einmal aufgerufen, egal wie oft die Methode aufgerufen wird, und ist absolut thread-sicher.

Dann jeder Methode können ganz einfach verwenden Sie diese Methode aufrufen, die als Barriere check:

private void ThrowIfDisposed()
{
   if (_disposeCount > 0) throw new ObjectDisposedException(GetType().Name);
}

Hinblick auf die Synchronisierung von jeder Methode - werden Sie sagen, eine einfache Barriere-check nicht, dass Sie aufhören wollen anderen threads, die möglicherweise bereits ausgeführten code in die Instanz. Dies ist ein komplexeres problem. Ich weiß nicht, was dein code tut, aber überlegen Sie, wenn Sie wirklich brauchen, dass - wird eine einfache Barriere-check nicht?

Wenn Sie einfach nur gemeint bezüglich der entsorgt schauen Sie selbst, mein Beispiel oben ist in Ordnung.

EDIT: Antwort auf die Bemerkung "Was ist der Unterschied zwischen diesem und ein volatile bool flag? Es ist leicht verwirrend, wenn ein Feld mit dem Namen somethingCount und lassen Sie es halten Sie 0 und 1 nur die Werte"

Flüchtig ist zur Sicherung der read-oder write-operation die operation ist atomar und sicher. Es macht nicht den Prozess der Zuordnung und einen Wert überprüfen thread-sicher. So, zum Beispiel, der folgende Code ist nicht thread-sicher trotz der volatilen:

private volatile bool _disposed;

public void Dispose()
{
    if (!_disposed)
    {
        _disposed = true

        //disposal code here
    }
}

Das problem hier ist, dass, wenn zwei Fäden eng zusammen, die zunächst überprüfen könnte, _disposed, Lesen Sie false, geben Sie den code-block und Holen Sie ausgeschaltet, bevor Sie _disposed zu wahren. Die zweite prüft dann _disposed, sieht falsch und tritt auch die code-block.

Verwendung von Interlocked sorgt zum einen für die Zuweisung und die anschließende lese, sind einer einzigen atomaren operation.

FWIW, Ihre Beispielcode entspricht meiner Kollegen und ich in der Regel mit diesem Thema befassen. Wir in der Regel definieren ein eigenes CheckDisposed Methode für die Klasse:

private volatile bool isDisposed = false; //Set to true by Dispose

private void CheckDisposed()
{
    if (this.isDisposed)
    {
        throw new ObjectDisposedException("This instance has already been disposed.");
    }
}

Dann nennen wir die CheckDisposed() Methode an der Spitze aller öffentlichen Methoden.

Thread, wenn Streit über die Entsorgung wird als wahrscheinlich angesehen, eher als ein Fehler aufgetreten ist, werde ich auch eine öffentliche IsDisposed() Methode (Ähnlich Kontrolle.IsDisposed).

Update: Basierend auf die Kommentare mit Bezug auf den Wert der isDisposed flüchtigen, beachten Sie, dass der "Zaun" Problem ist eher trivial gegeben, wie ich die CheckDisposed() Methode. Es ist im wesentlichen ein tool zur Fehlerbehebung für schnell fangen den Fall, wo der code ruft eine öffentliche Methode auf das Objekt, nachdem es bereits veräußert worden. Aufruf CheckDisposed() am Beginn einer öffentlichen Methode in keiner Weise garantiert, dass das Objekt nicht entsorgt werden innerhalb dieser Methode. Wenn ich bedenke, dass es eine inhärente Risiko in meiner Klasse design, im Gegensatz zu einer Fehlerbedingung, die ich nicht berücksichtigt, für, dann nutze ich die oben genannten IsDisposed - Methode zusammen mit der entsprechenden Verriegelung.