Öffentlich sichtbares Sperrobjekt: Manchmal nützlich oder Hinweis für Designfehler?

Question

Ich überwache eine Subkontraktversorgung einer Softwarekomponente, die eine Netzwerkkommunikation auf niedriger Ebene verwaltet. Mit dieser Komponente bewertet den ich dies gefunden:

public static object SyncRoot { get { return syncRoot; } } 

Innerhalb dieser sehr wichtig Klasse fast jedes Verfahren verwendet dieses Sperrobjekt während Dinge zu tun. Jetzt frage ich mich, ob dies eine gute Entscheidung ist, einen solchen Engpass zu implementieren, oder ist es schließlich ein ernsthafter Konstruktionsfehler. Ist das nicht eine seltsame Art von Multithreading?

Neben dem Problem der möglichen Deadlocking ist Verriegelung schnell? Wie hoch ist der Überwachungseffekt, um alle diese konkurrierenden Threads zu verwalten? Wäre es nicht besser (wenn es irgendwie notwendig wäre), etwas wie eine synchrone Pause/Resume-Methode zu implementieren, um diese Klasse von außen zu starten? In welcher Situation ist ein öffentlich sichtbares Lock-Objekt nützlich? Gibt es irgendwelche?

Answer 1

Public SyncRoot wird im MS-Framework verwendet, das ist richtig, aber das ist eine Instanzeigenschaft, keine statische Eigenschaft. Sie geben keine Details zum Umfang oder zur Verfügbarkeit des von der (Static) SyncRoot-Eigenschaft in Ihrem Beispiel zurückgegebenen syncRoot-Objekts an. Die Dokumentation (http://msdn.microsoft.com/en-us/library/ms173179.aspx) warnt vor dem Sperren eines öffentlichen Typs oder eines Objekts, das "außerhalb der Kontrolle Ihrer Anwendung" liegt. Es gibt eine sehr gute Diskussion über Multithreading unter http://www.albahari.com/threading/.

Answer 2

dies oft für die Sammlung Synchronisation im Rahmen MS verwendet wird

http://msdn.microsoft.com/en-us/library/system.collections.icollection.syncroot.aspx

Answer 3

Die SyncLock ist im Wesentlichen ein Designfehler in dem .NET-Framework. Aus diesem Grund stellen die .NET 2.0-Sammlungen diese Eigenschaft nicht direkt zur Verfügung (sie ist explizit implementiert und aus Gründen der Abwärtskompatibilität erforderlich). Das Problem besteht darin, dass das Sperren häufig zu granular erfolgt, das Sperren auf einem zu niedrigen Niveau erfolgt. In der Regel kann dieses Problem gelöst werden, indem eine Komponente auf höherer Ebene gesperrt wird, die die Sammlung steuert.

Mit der Eigenschaft SyncRoot gibt es tatsächlich Änderungen von Deadlocks, da Sie keine Kontrolle darüber haben, wie die Benutzer dieses gesperrte Objekt verwenden. Sie können auch eine Sperre für eine sehr lange Zeit nehmen oder vergessen, sie zu entsperren. Die Idee von Pause/Resume klingt sehr beängstigend.

Das Übliche ist, die Komponente fadensicher zu machen. Wenn Sie dies tun, benötigen Sie die Eigenschaft SyncRoot nicht.