Sta ottenendo e impostando un filetto di proprietà statiche semplice sicuro?

Question

Eventuali duplicati:
Are C# auto-implemented static properties thread-safe?

Nella seguente classe esempio

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

molti fili lettore leggere la matrice Values stringa periodicamente, mentre di volta in volta un singolo scrittore sostituirà l'intero array con un nuovo valore usando il setter. Devo usare un ReaderWriterLock o C# è qualcosa che gestirà automaticamente?

Modifica: nel mio caso l'unica richiesta "sicurezza del thread" è: Niente di brutto dovrebbe accadere quando il writer sostituisce l'array mentre il lettore sta cercando un valore. Non mi interessa se i lettori useranno il nuovo valore immediatamente fintanto che lo useranno in futuro

Answer 1

Questo uso è thread-safe:

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

Questo uso non è thread-safe, e può causare eccezioni out-of-bounds:

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

Io preferirei fare thread sicuro chiama più naturale facendo qualcosa del genere:

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

Ovviamente, gli utenti possono ancora inserire GetValues ​​() nei loop, e sarebbe altrettanto male, ma almeno è ovviamente negativo.

A seconda della situazione, una soluzione ancora migliore potrebbe essere quella di distribuire copie, in modo che il codice chiamante non possa mutare affatto l'array. Questo è quello che farei di solito, ma potrebbe non essere appropriato nella tua situazione.

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

Questo non è thread-safe. Sì, dovrai usare un lucchetto.

Answer 3

Dipende da cosa intendi per thread-safe.

La lettura e la sostituzione sono garantite per essere atomiche, ma non è garantito che una lettura che segue una scrittura necessariamente leggerà il valore fresco.

In risposta alla tua modifica ...

Niente di male accadrà con il codice esistente (ad esempio, strappato letture), ma non v'è alcuna garanzia che i tuoi lettori si mai vedere il nuovo valore . Ad esempio, è possibile, anche se forse improbabile, che il vecchio riferimento venga memorizzato per sempre in un registro.

Answer 4

Senza alcuna protezione aggiuntiva, non c'è garanzia che un thread di lettura sarà mai vedere il nuovo valore. In pratica, se il thread di lettura sta facendo qualcosa di significativo, lo vedrà il nuovo valore. In particolare, non vedrai mai "metà" di un aggiornamento, con un riferimento che punta allo spazio morto.

Se si effettua il campo volatile, credo che anche questo pericolo venga rimosso, ma la programmazione senza blocco è generalmente difficile da ragionare. Questo significa abbandonare il fatto che sia una proprietà implementata automaticamente, ovviamente.

Answer 5

Vorrei bloccare. Per la lettura multipla, la scrittura occasionale utilizza ReaderWriterLockSlim - molto più efficiente di 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

Per andare un po 'off-topic, il modello 1.5 di memoria Java 2 aggiunge due garanzie (vedi Java theory and practice: Fixing the Java Memory Model, Part 2):

• volatili letture/scritture sono anche barriere di memoria.
• final i campi appaiono completamente inizializzati al di fuori del costruttore.

Quest'ultimo è un caso interessante: è stato utilizzato per essere in grado di fare foo = new String(new char[]{'a','b','c'}); in un thread e foo = "123"; System.out.println(foo) in un altro thread e stampare la stringa vuota, perché non vi era alcuna garanzia che le operazioni di scrittura ai campi finali di foo accadrà prima scrivere a foo.

Non sono sicuro dei dettagli dell'inizializzazione dell'array .NET; potrebbe essere il caso in cui è necessario utilizzare Thread.MemoryBarrier() (all'inizio del getter e alla fine del setter) per garantire che i lettori vedano solo array completamente inizializzati.