Lock-in-Eigenschaften, guter Ansatz?

In meinem multithreading-Anwendung verwende ich einige Variablen, die geändert werden können, durch viele Instanzen in der gleichen Zeit. Es ist komisch, aber es hat alles geklappt ohne Probleme..aber natürlich werde ich brauchen, um es thread-sicher. Ich bin am Anfang mit Schlössern, so würde ich appretiate Ihre Beratung:

Wenn der client verbindet, die Klasse Client erstellt, wo jeder Kunde hat seine eigene "A" - variable.

Manchmal, Client ruft die Methode so:

Client selectedClient SelectOtherClientClassByID(sentID);

selectedClient.A=5;

Keine Probleme bis jetzt, auch wenn die 5 Klassen wurden dabei in der gleichen Zeit (threadpool), aber ich dachte, was über das hinzufügen von sperren, um Ein Eigenschaften?

Wie:

A {
    get { return mA; }
    set {
        //use lock here for settting A to some value
    }    
}

Wäre es OK?

InformationsquelleAutor Petr | 2009-10-23

  1. 16

    Müssen Sie sperren in BEIDEN get-und set -. Diese Sperre muss das gleiche Objekt. Zum Beispiel:

    private object mylock = new object();

public int A {

  get {
    int result;
    lock(mylock) {
    result = mA; 
    }
    return result;
  } 

  set { 
     lock(mylock) { 
        mA = value; 
     }
  }
}
    Danke...btw zum Lesen sein, weil es könnte sich während der Lektüre durch die anderen in der Klasse?
    Es ist nicht eine gute Idee, die Sperre auf dieses, wie es ist von außen zugänglich der Typ.
    Könnte es ändern, während Sie die Einstellung. Das Schloss wirkt wie eine Barriere und verhindert, dass andere Maßnahmen, bis der lock-Eigentümer gibt die Sperre frei.
    Ich bin damit einverstanden. Die änderung an meinem code. War einfach nur zeigen.
    Sorry, ich war auf dem treffen, _NT bitte, wie haben Sie Ihren code sehen, bevor Sie ändern, ich meine, was war das problem, Brian erwähnt? Ich möchte so viel lernen wie ich kann 🙂

    InformationsquelleAutor NT_

  2. 6

    Sperren den Zugriff auf Eigenschaften innerhalb der Zugriffsmethoden kann führen zu falschen Ergebnissen. Zum Beispiel, betrachten Sie den folgenden code:

    class C {
    private object mylock = new object();

    public int A {

      get {
        int result;
        lock(mylock) {
        result = mA; 
        }
        return result;
      } 

      set { 
         lock(mylock) { 
            mA = value; 
         }
      }
    }
}
C obj = new C;
C.A++;

    (ja, ich habe es kopiert aus der ersten Antwort)
    Es ist eine race-Bedingung hier! Operation "C. A++" tatsächlich erfordert zwei separate Zugänge, Eine, einer, um den Wert und die andere um die aktualisierten Wert. Nichts garantiert, dass diese zwei Zugänge durchgeführt werden als zusammen ohne context-switch zwischen Ihnen. Klassisches Szenario für race-condition!

    So, Vorsicht! Es ist nicht eine gute Idee, um Schlösser innen-Accessoren, Schlösser sollten explizit erhalten, wie in der vorhergehenden Antwort erläutert (obwohl es nicht mit SyncRoots, jedes Objekt tun wird)

    Auch du meinst manuell hinzufügen lock-Objekt, um alle Anrufe in den code? Ich denke, es gibt mindestens 20 Lesungen und 15 Schriften iny mein code bisher.
    Zu tun, erweitern Sie Ihr Schloss zur Abdeckung der gesamten kritischen region. Tun Sie das nicht A++.
    NT: ich verstehe nicht, Sie wahrscheinlich auch. Ich habe rund 15 Methoden mit verschiedenen Operationen mit dieser Variablen auf die andere Instanz. Im nicht sicher, wie Sie Sie bedeutete die Ausweitung der sperren. Damit die Eigenschaften sperren ist nicht gut, wenn ich das richtig gelesen habe alle oben
    Ich lenkte meinen vorherigen Kommentar zu ilial. Wie für Ihren Kommentar, Sie brauchen würden, um festzustellen, ob diese einen gemeinsamen synchonisation Objekt. In diesem Fall sollten Sie eine einzelne Sperre. Wenn Sie neu auf all dies haben Sie einen Blick auf diese interessanten link: codeproject.com/KB/threads/...

    InformationsquelleAutor ilial

  3. 2

    Es ist sehr selten, wenn alles, was Sie brauchen, ist nur mit einem einzigen Eigenschaft. Mehr oft selectedClient.A = 5 wird ein Teil eines viel größeren logischen operation, die beinhaltet mehrere Zuordnungen/Bewertungen/etc. Während dieser ganzen operation würden Sie lieber selectedClient werden in einem konsistenten Zustand, und nicht die Einführung deadlocks/race-conditions. Daher wird es viel besser zu entlarven SyncRoot Eigenschaft in Ihrem Client Klasse und sperren auf, die vom aufrufenden code:

    Client selectedClient = GetClient(...);

lock(selectedClient.SyncRoot)
{
    selectedClient.A = 5;
    selectedClient.B = selectedClient.A * 54;
}
    Ich habe keine anderen Variablen teilen als eine Liste und int. Vor allem, ich weiß nichts über SyncRoot noch: -)
    SyncRoot wird nicht empfohlen: Siehe blogs.msdn.com/brada/archive/2003/09/28/50391.aspx
    Zitat aus dem blog-post: "seien Sie versichert, wir werden nicht den gleichen Fehler machen, wie wir bauen, die generischen Versionen der Sammlungen." Und hier sind wir nun, 6 Jahre später, mit List<T>.SyncRoot-ohne demotivierende Hinweise in der MSDN: msdn.microsoft.com/en-us/library/bb356596.aspx
    MSDN ist kaum die beste Quelle für korrekte Programmierung! SyncRoot, ist eine öffentlich-Sperre und eine Katastrophe warten, um zu geschehen (nach "CLR via C#" von Jeffrey Richter amazon.co.uk/gp/reader/0735621632/ref=sib_dp_pt#reader-link)

    InformationsquelleAutor Anton Gogolev

Schreibe einen Kommentar