Bloqueo verificado en .NET

Question

Me encontré con este article discutiendo por qué el paradigma de bloqueo de doble comprobación se rompe en Java. ¿El paradigma es válido para .NET (en particular, C#), si las variables se declaran volatile?

Answer 1

Implementing the Singleton Pattern in C# habla sobre este problema en la tercera versión.

Dice:

Hacer la instancia de variable volátil puede hacer que funcione, como lo haría barrera de memoria explícita llama, aunque en este último caso, incluso los expertos no se ponen de acuerdo exactamente lo que se requieren barreras. ¡Tiendo a tratar de evitar situaciones en las que los expertos no están de acuerdo con lo que está bien y lo que está mal!

El autor parece dar a entender que el doble bloqueo tiene menos probabilidades de funcionar que otras estrategias y, por lo tanto, no debe utilizarse.

Answer 2

Tenga en cuenta que en Java (y muy probablemente en .Net también), el bloqueo con doble comprobación para la inicialización de singleton es completamente innecesario y está roto. Como las clases no se inicializan hasta que se usan por primera vez, la inicialización lenta deseada ya se logra con esto;

private static Singleton instance = new Singleton(); 

A menos que su clase Singleton contiene cosas como constantes que se pueda acceder antes de que se utiliza una instancia de Singleton principio, esto es todo lo que necesita hacer.

Answer 3

El bloqueo de doble comprobación ahora funciona tanto en Java como en C# (el modelo de memoria de Java cambió y este es uno de los efectos). Sin embargo, debe obtenerlo exactamente derecha. Si ensucias las cosas aunque sea levemente, puedes terminar perdiendo la seguridad del hilo.

Como han dicho otras respuestas, si está implementando el singleton pattern hay formas mucho mejores de hacerlo. Personalmente, si estoy en una situación en la que tengo que elegir entre el bloqueo doblemente comprobado y el código de "bloqueo cada vez", me iría por el bloqueo cada vez hasta que tuviera evidencia real de que estaba causando un cuello de botella. Cuando se trata de enhebrar, un patrón simple y obviamente correcto vale mucho.

Answer 4

.NET 4.0 tiene un nuevo tipo: Lazy<T> que quita cualquier preocupación acerca de obtener el patrón incorrecto. Es parte de la nueva Task Parallel Library.

Véase el MSDN Parallel Computing Center Dev: http://msdn.microsoft.com/en-us/concurrency/default.aspx

Por cierto, hay una backport (creo que no es compatible) para .NET 3.5 SP1 disponible here.

Answer 5

He conseguido una doble comprobación de bloqueo a trabajar mediante el uso de un valor booleano (es decir, utilizando una primitiva para evitar la inicialización perezoso):

private static Singleton instance; 
private static boolean created; 
public static Singleton getInstance() { 
    if (!created) { 
     synchronized (Singleton.class) { 
      if (!created) { 
       instance = new Singleton(); 
       created = true; 
      } 
     } 
    } 
    return instance; 
} 

Answer 6

He conseguido una doble comprobación de bloqueo de trabajar por utilizando un booleano (es decir, utilizando una primitiva para evitar la inicialización diferida):

El singleton que utiliza booleano no funciona. El orden de las operaciones como se ve entre los diferentes hilos no está garantizado a menos que atraviese una barrera de memoria. En otras palabras, como se ve desde un segundo hilo, created = true pueden ser ejecutados antes de instance= new Singleton();

Answer 7

No acabo de entender por qué hay un montón de patrones de implementación de bloqueo doble comprobación (aparentemente para evitar la idiosincrasia del compilador en varios idiomas). El artículo de Wikipedia sobre este tema muestra el método ingenuo y las posibles maneras de resolver el problema, pero ninguno es tan simple como esto (en C#):

public class Foo 
{ 
    static Foo _singleton = null; 
    static object _singletonLock = new object(); 

    public static Foo Singleton 
    { 
    get 
    { 
     if (_singleton == null) 
     lock (_singletonLock) 
      if (_singleton == null) 
      { 
      Foo foo = new Foo(); 

      // Do possibly lengthy initialization, 
      // but make sure the initialization 
      // chain doesn't invoke Foo.Singleton. 
      foo.Initialize(); 

      // _singleton remains null until 
      // object construction is done. 
      _singleton = foo; 
      } 
     return _singleton; 
    } 
    } 

En Java, se haría uso sincronizado() en lugar de lock(), pero básicamente es la misma idea. Si existe la posible incoherencia de cuándo se asigna el campo singleton, ¿por qué no utilizar primero una variable de ámbito local y luego asignar el campo singleton en el último momento posible antes de salir de la sección crítica? ¿Me estoy perdiendo de algo?

Existe el argumento de @michael-borgwardt que en C# y Java el campo estático solo se inicializa una vez en el primer uso, pero que el comportamiento es específico del idioma. Y he usado este patrón frecuentemente para la inicialización lenta de una propiedad de colección (por ejemplo, user.Sessions).

Answer 8

No entiendo por qué todas las personas dicen que el doble bloqueo es un mal patrón, pero no adaptan el código para que funcione correctamente. En mi opinión, este código a continuación debería funcionar bien.

Si alguien pudiera decirme si este código sufre el problema mencionado en el artículo de Cameron, hágalo.

public sealed class Singleton { 
    static Singleton instance = null; 
    static readonly object padlock = new object(); 

    Singleton() { 
    } 

    public static Singleton Instance { 
     get { 
      if (instance != null) { 
       return instance; 
      } 

      lock (padlock) { 
       if (instance != null) { 
        return instance; 
       } 

       tempInstance = new Singleton(); 

       // initialize the object with data 

       instance = tempInstance; 
      } 
      return instance; 
     } 
    } 
}