Best Practices in der Verwendung eines lock

Angenommen ich habe die folgende Eigenschaft in einer Klasse, und hat den Zweck verwendet werden, wie eine Sperre. 

protected object SyncRoot { get; private set; }

Sowieso, unabhängig davon, ob und wie diese festgelegt wurde. Was ist die beste Praxis zu gehen über die Verwendung von es, wenn es, in der Tat, gesetzt?

Da lock funktioniert nicht mit null-Objekten, sollte ich damit umgehen, wie diese?

lock (SyncRoot ?? new object())
    SomeMethod();

Oder sollte ich auf null prüfen, wie diese?

if (SyncRoot != null)
    lock (SyncRoot)
        SomeMethod();
else
    SomeMethod();

Wenn es ist, in der Tat, gesetzt, ich möchte es verwenden, um zu sperren. Ansonsten ich don ' T care. Ist die erste Lösung ineffizient oder überflüssig sowieso?

EDIT: Alle diese Antworten sind gut. Jedoch kann ich nur eine auswählen. Angesichts meiner situation, wie besprochen, mit Luke, gibt es keinen Grund, warum meine SyncRoot, sollte null sein. Der Aufwand für eine Sperre in einem einzigen Multithread-Umgebung ist es kein biggy, aber notwendig, wenn in einem multi-fädelte ein.

(Abstimmung ups für alle 4 ya) Danke Euch allen für Eure schnelle Antworten.

InformationsquelleAutor Beljoda | 2012-08-03
  1. 21

    Verwende ich normalerweise eine private member-variable, nicht eine Eigenschaft, dh

    private static object MyLock = new object();

    Diese Weise seinen immer initialisiert.

    Können Sie auch eine nicht statische Variante wie

    private readonly object MyLock = new object();
    • In meiner Eltern-Klasse diese Eigenschaft festgelegt ist, gegeben eine bestimmte Bedingung. Es ist meine Absicht, mit dieser Variablen oder Eigenschaft, die in abgeleiteten Klassen, wenn diese Bedingung wahr ist. Würden Sie denken, dass lock(SyncRoot ?? new object()) kommt mit zu viel Aufwand?
    • ein lock-Objekt ist nur eine new object() - warum würden Sie sich jemals die Mühe zu verlassen, es ist null? (warum würden Sie nicht nur initialisieren, wenn es erklärt, die Beseitigung dieses Anliegen standardmäßig?)
    • Es ist für meine manager-Klasse, die Schnittstellen, um mir den Zugang zu einer Script-Sprache. Das lock-Objekt ist null, wenn ich zunächst entscheiden, nicht automatisch zu kompilieren des Skripts. Wenn ich entscheiden, um es einrichten, um automatisch kompilieren, verwende ich diese Sperre, so dass ich nicht eine Methode aufrufen in der Mitte, die es neu definiert.
    • aber warum nicht einfach immer Sperre? Haben Sie Angst vor der overhead? Es ist ehrlich gesagt eine seltene situation, wo der Aufwand für das sperren bietet eine Verteidigung für diese Art von zusätzliche Komplexität.
    • Hmm... Ihr Recht. Das Sperrobjekt wird festgelegt, wenn es eine chance gibt, der mehrere threads auf diese manager-Klasse (da automatisch kompilieren von code mit mehreren threads erzeugt, die durch Ereignisse). Interne auf diese manager-Klasse, die nur einem thread wäre das ausführen von code in dieser Klasse, wenn automatisch kompilieren ist nicht festgelegt. Und der Aufwand für eine Sperre ist nicht schrecklich behindern. Ich könnte genauso gut sperren wie jedes mal.
    • lock(SyncRoot ?? new object()) ist nicht eine furchtbar gute option, wenn Sie die Verriegelung auf " new object()' es nicht gehen, um eine Wirkung auf alle. eine Sperre nur dann wirklich funktioniert, weil das Objekt gemeinsam von mehreren threads, in diesem Fall wird das Objekt nicht mehr gemeinsam auf allen

    InformationsquelleAutor Luke McGregor
  2. 11

    Synchronisieren auf

    SyncRoot ?? new object()

    macht keinen Sinn, denn wenn SyncRoot ist null jeder thread ein neues Objekt jedes mal. Synchronisierung über separate Objekte hat keinen Effekt: die threads werden auch weiterhin richtige Weg, denn niemand sonst könnte eventuell die Synchronisierung auf dem gleichen new Objekt.

    Sollten Sie initialisieren SyncRoot im Konstruktor, bevor der erste thread versucht, erhalten eine Sperre.

    • funktioniert die Synchronisierung mit einem neuen Objekt kommen, mit allen Folgen wie Behinderung in der Geschwindigkeit?
    • die performance-Auswirkungen von Synchronisation auf new object() ist strittig, da es ein völlig nutzlos idiom.
    • Geschwindigkeit spielt keine Rolle, wenn jeder thread, der Pässe durch den code erzeugt ein neues lock-Objekt, dann ist dein code ist nicht geschützt, die von mehreren threads den Zugriff auf die geschützte Ressource. Um die threads zu line-up und den Zugriff auf die geschützte Ressource ein zu einer Zeit, die Sie haben, um alle sperren auf DERSELBEN Objekt-Instanz.
    • Synchronisierung auf ein neues Objekt bedeutet, dass keine Synchronisation überhaupt: der einzige Grund, einen thread bekommen würde, ein Schloss und die anderen warten würde, ist, dass Sie sich an der dieselbe - Objekt. Das wird nicht geschehen, wenn jeder thread erhält ein neues Objekt, auf dem Sie synchronisieren.
    • Recht. Also, sollte ich nur verwenden Ihre Lösung, unabhängig davon, ob meine Klasse ist innerhalb eines single-oder multi-threaded-Anwendung. Danke
    InformationsquelleAutor dasblinkenlight
  3. 3

    Wird das erste problem sein, denn es wird zu nichts gutem führen Synchronisation:

    lock (SyncRoot ?? new object())
    SomeMethod();

    Der Grund dafür ist, dass, wenn Sie erstellen ein neues Objekt wird auf dem heap, aber es wird kein Hinweis darauf. Also, wenn ein anderer thread kommt, wird es nicht finden... Es wird absolut nutzlos, und es wird nicht blockiert den Zugriff auf den kritischen Abschnitt.

    Den zweiten Ansatz funktionieren wird, aber ich kann wirklich nicht verstehen, warum Sie möchten, verwenden Sie die Sperre, wenn es nur verfügbar ist.

    InformationsquelleAutor Stas
  4. 2

    Ihre beste option ist immer initialisieren des lock-Objekt, vor jeder Verbraucher das lock-Objekt hat eine chance, es zu benutzen. Die Kosten immer reservieren, das lock-Objekt ist klein, und die Kosten der Einnahme der lock ist klein, wenn es kein Streit-thread.

    So hinzufügen lock/no lock prüft alle über Ihren code verdoppelt die Komplexität des Codes und wahrscheinlich vorstellen subtile threading bugs, aber wird wahrscheinlich nicht produziert keine spürbaren performance-Vorteil.

    Code vereinfachen: nehmen Sie immer die Sperre.

    InformationsquelleAutor dthorpe
  5. 2

    Aus der Dokumentation:
    https://msdn.microsoft.com/en-us/library/c5kehkcz.aspx

    Vermeiden Sie im Allgemeinen die Sperre einer öffentlichen geben, oder Instanzen, die über code Steuern. Die gemeinsamen Konstrukte lock (this), lock (typeof (MyType)) und lock ("myLock") gegen diese Richtlinie:

    • lock (this) ist ein problem, wenn auf die Instanz öffentlich zugegriffen werden kann.
    • lock (typeof (MyType)) ist ein problem, wenn MyType ist öffentlich zugänglich.
    • lock("myLock") ist ein problem, da jeder andere code in den Prozess, der dieselbe Zeichenfolge verwendet, dieselbe Sperre.

    Best-practice - ist die Definition einer eigenes Objekt zu sperren, die auf, oder ein private
    statische Objekte variable     zum Schutz der Daten, die allen Instanzen gemeinsam.

    Beispiel:

     class Account
{
    decimal balance;
    private Object thisLock = new Object();

    public void Withdraw(decimal amount)
    {
        lock (thisLock)
        {
            if (amount > balance)
            {
                throw new Exception("Insufficient funds");
            }
            balance -= amount;
        }
    }
}
    InformationsquelleAutor Teoman shipahi
Schreibe einen Kommentar