Ich habe den folgenden Artikel gelesen:http: //msdn.microsoft.com/en-us/magazine/cc817398.asp "Lösen von 11 wahrscheinlichen Problemen in Ihrem Multithread-Code" von Joe Duffy

Und es stellte sich mir die Frage: "Wir müssen ein .NET Int32 sperren, wenn wir es in einem Multithread-Code lesen?"

Ich verstehe, dass wenn es ein Int64 in einem 32-Bit-SO wäre, es reißen könnte, wie es im Artikel erklärt wird. Aber für Int32 habe ich mir folgende Situation vorgestellt:

class Test
{
  private int example = 0;
  private Object thisLock = new Object();

  public void Add(int another)
  {
    lock(thisLock)
    {
      example += another;
    }
  }

  public int Read()
  {
     return example;
  }
}

Ich sehe keinen Grund, eine Sperre in die Read-Methode aufzunehmen. Machst du

Aktualisiere Basierend auf den Antworten (von Jon Skeet und ctacke) verstehe ich, dass der obige Code immer noch für Multiprozessor-Caching anfällig ist (jeder Prozessor hat seinen eigenen Cache, der nicht mit anderen synchronisiert ist). Alle drei unten aufgeführten Änderungen beheben das Problem:

Zu "int example" die Eigenschaft "volatile" hinzufügen Einfügen eines Thread.MemoryBarrier (); vor dem eigentlichen Lesen von "int example"Lesen Sie "int example" in einem "lock (thisLock)"

Und ich denke auch, dass "volatile" die eleganteste Lösung ist.