Inizializzazione di variabili statiche thread-safe

Question

Ho utilizzato questo modello per inizializzare i dati statici nelle mie classi. Mi sembra thread-safe, ma so quanto possano essere sottili problemi di threading. Ecco il codice:

public class MyClass // bad code, do not use 
{ 
    static string _myResource = ""; 
    static volatile bool _init = false; 
    public MyClass() 
    { 
     if (_init == true) return; 
     lock (_myResource) 
     { 
      if (_init == true) return; 
      Thread.Sleep(3000); // some operation that takes a long time 
      _myResource = "Hello World"; 
      _init = true; 
     } 
    } 
    public string MyResource { get { return _myResource; } } 
} 

Ci sono dei buchi qui? Forse c'è un modo più semplice per farlo.

AGGIORNAMENTO: Il consenso sembra essere che un costruttore statico è la strada da percorrere. Ho trovato la seguente versione usando un costruttore statico.

public class MyClass 
{ 
    static MyClass() // a static constructor 
    { 
     Thread.Sleep(3000); // some operation that takes a long time 
     _myResource = "Hello World"; 
    } 

    static string _myResource = null; 

    public MyClass() { LocalString = "Act locally"; } // an instance constructor 

    // use but don't modify 
    public bool MyResourceReady { get { return _myResource != null; } } 
    public string LocalString { get; set; } 
} 

Spero che questo è meglio.

Answer 1

È possibile utilizzare i costruttori statici per inizializzare le variabili statiche, le cui garanzie C# verranno chiamate una sola volta all'interno di ciascun AppDomain. Non sono sicuro se li hai considerati.

Così si può leggere questo: http://msdn.microsoft.com/en-us/library/aa645612(VS.71).aspx (Static Costruttori)

E questo: Is the C# static constructor thread safe?

Answer 2

A seconda del caso d'uso (vale a dire se le discussioni non hanno bisogno di passare informazioni tra loro utilizzando questa variabile) , contrassegnando la variabile membro come [ThreadStatic] potrebbe essere una soluzione.
Vedere here.

Answer 3

Eseguire un lock() su _myResource e modificarlo all'interno dell'istruzione lock() sembra una cattiva idea. Considerate seguente flusso di lavoro:

1. filo 1 chiamate MyClass().
2. interruzioni di esecuzione prima della riga _init = true; subito dopo l'assegnazione di _myResource.
3. Il processore passa al thread 2.
4. thread 2 chiama MyClass(). Dal _init è ancora false e refrence _myResource modificato, con successo entra nel blocco di istruzioni lock().
5. _init è ancora false, quindi il thread 2 riassegna _myResource.

Soluzione: creare una statica object e blocco su questo oggetto, invece di risorse inizializzato:

private static readonly object _resourceLock = new object(); 

/*...*/ 

lock(_resourceLock) 
{ 
    /*...*/ 
} 

Answer 4

La classe non è sicuro:

1. Si modifica l'oggetto che stai blocco su dopo averlo bloccato.
2. Si dispone di una proprietà che ottiene la risorsa senza bloccarla.
3. Si blocca su un primitive type, che in genere non è una buona pratica.

Questo dovrebbe farlo per voi:

public class MyClass 
{ 
    static readonly object _sync = new object(); 
    static string _myResource = ""; 
    static volatile bool _init = false; 

    public MyClass() 
    { 
     if (_init == true) return; 
     lock (_sync) 
     { 
      if (_init == true) return; 
      Thread.Sleep(3000); // some operation that takes a long time 
      _myResource = "Hello World"; 
      _init = true; 
     } 
    } 

    public string MyResource 
    { 
     get 
     { 
      MyClass ret; // Correct 
      lock(_sync) 
      { 
       ret = _myResource; 
      } 
      return ret; 
     } 
    } 
} 

Aggiornamento:
corretta, la risorsa statico non deve essere restituito direttamente ... Ho corretto il mio esempio di conseguenza.

Answer 5

static string _myResource = ""; 
... 
public MyClass() 
{ 
    ... 
    lock (_myResource) 
    { 
    } 
} 

A causa dell'internamento delle stringhe, non si deve bloccare un letterale di stringa.

UPDATE

Sì, @RaoulRubin, quindi se si blocca su una stringa letterale e che stringa letterale viene utilizzato da più classi, allora si può condividere quella serratura. Questo può potenzialmente causare un comportamento imprevisto.