Inicialización segura de subprocesos de variables estáticas

Question

He estado utilizando este patrón para inicializar datos estáticos en mis clases. Parece seguro para mí, pero sé lo sutiles que pueden ser los problemas de enhebrado. Aquí está el código:

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; } } 
} 

¿Hay algún agujero aquí? Tal vez hay una manera más simple de hacer esto.

ACTUALIZACIÓN: El consenso parece ser que un constructor estático es el camino a seguir. Se me ocurrió la siguiente versión usando un constructor estático.

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; } 
} 

Espero que esto sea mejor.

Answer 1

Puede usar constructores estáticos para inicializar sus variables estáticas, y las garantías de C# solo se invocarán una vez dentro de cada dominio de aplicación. No estoy seguro si los consideraste.

Así que usted puede leer esto: http://msdn.microsoft.com/en-us/library/aa645612(VS.71).aspx (estático Constructores)

Y esto: Is the C# static constructor thread safe?

Answer 2

Dependiendo de su caso de uso (es decir, si las discusiones no tienen que pasar información entre sí utilizando esta variable) , marcando la variable miembro como [ThreadStatic] puede ser una solución.
Ver here.

Answer 3

Realizar lock() en _myResource y cambiarlo por lock() parece una mala idea. Considere siguiente flujo de trabajo:

1. hilo 1 llama MyClass().
2. ejecución se detiene antes de la línea _init = true; justo después de asignar _myResource.
3. procesador cambia a la rosca 2.
4. rosca 2 llamadas MyClass(). Como _init sigue siendo false y la referencia _myResource ha cambiado, entra con éxito en el bloque de instrucción lock().
5. _init sigue siendo false, por lo que el subproceso 2 reasigna _myResource.

Solución: crear una estática object y bloquear sobre este objeto en lugar de recursos inicializado:

private static readonly object _resourceLock = new object(); 

/*...*/ 

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

Answer 4

Su clase no es seguro:

1. Se cambia el objeto que está en bloqueo después de haberlo bloqueado
2. Tiene una propiedad que obtiene el recurso sin bloquearlo.
3. Se bloquea en un primitive type, que generalmente no es una buena práctica.

Esto debe hacerlo por usted:

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; 
     } 
    } 
} 

Actualización:
correcta, el recurso estático no debe ser devuelto directamente ... He corregido mi ejemplo en consecuencia.

Answer 5

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

Debido a la cadena de internados, no debe bloquear un literal de cadena.

ACTUALIZACIÓN

Sí, @RaoulRubin, por lo que si se bloquea en una cadena literal y que literal de cadena es utilizada por múltiples clases entonces usted va a compartir esa cerradura. Esto puede causar un comportamiento inesperado.