Ist ein einfacher Thread für statische Eigenschaften sicher und sicher?

Question

Mögliche Duplizieren:
Are C# auto-implemented static properties thread-safe?

Im folgenden Beispiel Klasse

static class Shared 
{ 
    public static string[] Values { get; set; } 
} 

viele Leser Threads gelesen das Values String-Array periodisch, während von Zeit zu Zeit ein einzelner writer ersetzt das gesamte Array durch einen neuen Wert mit dem Setter. Muss ich eine ReaderWriterLock verwenden, oder wird dies von C# automatisch gehandhabt?

Edit: In meinem Fall ist die einzige erforderliche "Thread-Sicherheit": Nichts Schlechtes sollte passieren, wenn der Schreiber das Array ersetzt, während der Leser nach einem Wert sucht. Es ist mir egal, ob die Leser den neuen Wert sofort verwenden werden, solange sie ihn in Zukunft verwenden.

Answer 1

Diese Verwendung ist Thread-sicher:

string[] localValues = Shared.Values; 
for (int index = 0; index < localValues.length; index++) 
    ProcessValues(localValues[index]); 

Diese Verwendung ist nicht Thread-sicher, und in Out-of-bounds Ausnahmen führen kann:

for (int index = 0; index < Shared.Values.Length; index++) 
    ProcessValues(Shared.Values[index]); 

Ich würde es vorziehen zu machen thread safe ruft natürlicher auf, indem man so etwas tut:

static class Shared 
{ 
    private static string[] values; 
    public static string[] GetValues() { return values; } 
    public static void SetValues(string[] values) { Shared.values = values; } 
} 

Natürlich können die Benutzer GetValues ​​() in die Schleifen setzen, und es wäre genauso schlimm, aber zumindest ist es offensichtlich schlecht.

Je nach Situation kann eine noch bessere Lösung darin bestehen, Kopien zu verteilen, damit der aufrufende Code das Array nicht mutieren kann. Dies ist, was ich normalerweise tun würde, aber es kann nicht in Ihrer Situation angemessen sein.

static class Shared 
{ 
    private static string[] values; 
    public static string[] GetValues() 
    { 
     string[] currentValues = values; 
     if (currentValues != null) 
      return (string[])currentValues.Clone(); 
     else 
      return null; 
    } 
    public static void SetValues(string[] values) 
    { 
     Shared.values = values; 
    } 
} 

Answer 2

Dies ist nicht threadsicher. Ja, Sie müssen ein Schloss verwenden.

Answer 3

Es hängt davon ab, was Sie unter Thread-Safe verstehen.

Das Lesen und Ersetzen ist garantiert atomar, aber es ist nicht garantiert, dass ein Lesen nach einem Schreibvorgang notwendigerweise den neuen Wert liest.

Als Antwort auf Ihre bearbeiten ...

Nichts Schlimmes wird mit Ihrem vorhandenen Code geschehen (zum Beispiel liest zerrissen), aber es gibt keine Garantie, dass Ihre Leser jemals den neuen Wert zu sehen . Zum Beispiel ist es möglich - wenn auch vielleicht unwahrscheinlich -, dass die alte Referenz für immer in einem Register zwischengespeichert wird.

Answer 4

Ohne zusätzlichen Schutz gibt es keine Garantie, dass ein Lesen Thread jemals den neuen Wert sehen wird. In der Praxis wird den neuen Wert sehen, solange der Lese-Thread etwas Bedeutendes tut. Insbesondere werden Sie niemals "halb" ein Update sehen, mit einem Verweis auf Totraum.

Wenn Sie das Feld volatile machen, glaube ich, dass auch diese Gefahr entfernt wird - aber Lock-Free-Programmierung ist in der Regel schwer zu begründen. Dies bedeutet natürlich, dass es aufgegeben wird, eine automatisch implementierte Eigenschaft zu sein.

Answer 5

Ich würde sperren. Verwenden Sie für mehrfaches Lesen, gelegentliches Schreiben eine ReaderWriterLockSlim - viel effizienter als ReaderWriteLock.

static class Shared 
{ 
    private static ReaderWriterLockSlim _rwLock = new ReaderWriterLockSlim(); 
    private static string[] _values; 

    public static string[] Values 
    { 
     get 
     { 
      _rwLock.EnterReadLock(); 
      try 
      { 
       return _values; 
      } 
      finally 
      { 
       _rwLock.ExitReadLock(); 
      } 
     } 
     set 
     { 
      _rwLock.EnterWriteLock(); 
      try 
      { 
       _values = value; 
      } 
      finally 
      { 
       _rwLock.ExitWriteLock(); 
      } 
     } 
    } 
} 

Answer 6

Um etwas off-topic zu gehen, fügt der Java 2 1.5 Speichermodell zwei Garantien (siehe Java theory and practice: Fixing the Java Memory Model, Part 2):

• flüchtig liest/schreibt auch Barrieren Speicher sind.
• final Felder erscheinen außerhalb des Konstruktors vollständig initialisiert.

Letzteres ist ein interessanter Fall: Sie verwendet der Lage sein, die leere Zeichenfolge zu tun foo = new String(new char[]{'a','b','c'}); in einem Thread und foo = "123"; System.out.println(foo) in einem anderen Thread und drucken, weil es keine Garantie dafür, dass die Schreibvorgänge auf foo endgültigen Felder passieren wird, bevor das Schreiben an foo.

Ich bin mir nicht sicher über die Details der .NET-Array-Initialisierung; Möglicherweise müssen Sie Thread.MemoryBarrier() (am Anfang des Getters und am Ende des Setter) verwenden, um sicherzustellen, dass die Leser nur vollständig initialisierte Arrays sehen.