¿Cuáles son los peligros de utilizar un Singleton en una aplicación de subprocesos múltiples

Question

Estoy buscando utilizar un singleton en un servicio Win multiproceso para hacer el registro y quería saber cuáles son algunos de los problemas que podría encontrar. Ya configuré la instancia get para administrar la sincronización con

private static volatile Logging _instance; 
    private static object _syncRoot = new object(); 

    private Logging(){} 
    public static Logging Instance 
    { 
     get 
     { 
      if (_instance==null) 
      { 
       lock(_syncRoot) 
       { 
        if (_instance == null) 
        { 
         _instance = new Logging(); 
        } 
       } 
      } 
      return _instance; 
     } 
    } 

¿Hay alguna otra cosa de la que deba preocuparme?

Answer 1

Eso se ve bastante bien para mí.

Consulte Implementing the Singleton Pattern in C# para obtener más información.

Editar: Sin embargo, probablemente debería poner la devolución dentro de la cerradura.

Answer 2

Creo que si los métodos de instancia de registro son seguros para subprocesos, no hay de qué preocuparse.

Answer 3

Los Singleton tienen el potencial de convertirse en un cuello de botella para acceder al recurso incorporado por la clase, y forzar el acceso secuencial a un recurso que de otro modo podría usarse en paralelo.

En este caso, eso puede no ser algo malo, porque no quiere que varios elementos escriban en su archivo en el mismo instante, y aún así no creo que su implementación tenga ese resultado. Pero es algo de lo que debes estar consciente.

Answer 4

Está utilizando double-checked locking lo que se considera un antipatrón. Wikipedia tiene patrones con y sin inicialización diferida para diferentes idiomas.

Después de crear la instancia de singleton, debe asegurarse de que todos los métodos sean seguros para la ejecución de subprocesos.

Answer 5

Esto es más informativo que cualquier otra cosa.

Lo que has enviado es el una doble comprobación de bloqueo algoritmo - y lo que has publicado hará el trabajo, por lo que yo soy consciente. (A partir de Java 1.5 también funciona allí). Sin embargo, es muy frágil: si te equivocas un poco, puedes introducir condiciones de carrera muy sutiles.

por lo general prefiero para inicializar el singleton en el inicializador estático: (. Añadir un constructor estático si quieres un poco de pereza adicional)

public class Singleton 
{ 
    private static readonly Singleton instance = new Singleton(); 

    public static Singleton Instance 
    { 
     get { return instance; } 
    } 

    private Singleton() 
    { 
     // Do stuff 
    } 
} 

más fácil de esa patrón para hacerlo bien, y en la mayoría de los casos, lo hace igual de bien.

Hay más detalles en mi C# singleton implementation page (también vinculado por Michael).

En cuanto a los peligros, diría que el mayor problema es que se pierde la capacidad de prueba. Probablemente no demasiado malo para el registro.

Answer 6

Una mejor sugerencia sería establecer el registrador en un paso de configuración de un solo subproceso, por lo que está garantizado que estará allí cuando lo necesite. En un servicio de Windows, OnStart es un gran lugar para hacer esto.

Otra opción que tiene es utilizar el método System.Threading.Interlocked.CompareExchange (T%, T, T): T para cambiar. Es menos confuso y está garantizado que funciona.

System.Threading.Interlocked.CompareExchange<Logging>(_instance, null, new Logging()); 

Answer 7

es necesario asegurarse de que cada método en el registrador son seguros en forma concurrente, es decir, que no se escriben en estado compartido y sin bloqueo adecuado.

Answer 8

Existe cierto debate con respecto a la necesidad de realizar la primera comprobación del uso nulo Thread.VolatileRead() si utiliza el patrón de bloqueo comprobado doble y desea que funcione en todos los modelos de memoria. Un ejemplo del debate se puede leer en http://social.msdn.microsoft.com/forums/en-US/csharpgeneral/thread/b1932d46-877f-41f1-bb9d-b4992f29cedc/.

Dicho esto, normalmente utilizo la solución de Jon Skeet desde arriba.