¿Es seguro el hilo del constructor estático C #?

En otras palabras, ¿es seguro este hilo de implementación de Singleton?

public class Singleton
{
    private static Singleton instance;

    private Singleton() { }

    static Singleton()
    {
        instance = new Singleton();
    }

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

Se garantiza que los constructores estáticos se ejecuten solo una vez por dominio de aplicación, antes de que se creen instancias de una clase o se acceda a cualquier miembro estático. https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/static-constructors

La implementación que se muestra es segura para subprocesos para la construcción inicial, es decir, no se requiere ninguna prueba de bloqueo o nula para construir el objeto Singleton. Sin embargo, esto no significa que cualquier uso de la instancia se sincronizará. Hay una variedad de formas en que esto se puede hacer; He mostrado uno a continuación.

public class Singleton
{
    private static Singleton instance;
    // Added a static mutex for synchronising use of instance.
    private static System.Threading.Mutex mutex;
    private Singleton() { }
    static Singleton()
    {
        instance = new Singleton();
        mutex = new System.Threading.Mutex();
    }

    public static Singleton Acquire()
    {
        mutex.WaitOne();
        return instance;
    }

    // Each call to Acquire() requires a call to Release()
    public static void Release()
    {
        mutex.ReleaseMutex();
    }
}

Si bien todas estas respuestas dan la misma respuesta general, hay una advertencia.

Recuerde que todas las derivaciones potenciales de una clase genérica se compilan como tipos individuales. Por lo tanto, tenga cuidado al implementar constructores estáticos para tipos genéricos.

class MyObject<T>
{
    static MyObject() 
    {
       //this code will get executed for each T.
    }
}

EDITAR:

Aquí está la demostración:

static void Main(string[] args)
{
    var obj = new Foo<object>();
    var obj2 = new Foo<string>();
}

public class Foo<T>
{
    static Foo()
    {
         System.Diagnostics.Debug.WriteLine(String.Format("Hit {0}", typeof(T).ToString()));        
    }
}

En la consola:

Hit System.Object
Hit System.String

Usar un constructor estático en realidad es seguro para subprocesos. El constructor estático está garantizado para ejecutarse solo una vez.

De la especificación del lenguaje C # :

El constructor estático para una clase se ejecuta como máximo una vez en un dominio de aplicación dado. La ejecución de un constructor estático se desencadena por el primero de los siguientes eventos que ocurren dentro del dominio de una aplicación:

• Se crea una instancia de la clase.
• Se hace referencia a cualquiera de los miembros estáticos de la clase.

Entonces, sí, puede confiar en que su singleton se instanciará correctamente.

Zooba hizo un excelente comentario (¡y 15 segundos antes que yo también!) De que el constructor estático no garantizará un acceso compartido seguro para subprocesos al singleton. Eso tendrá que ser manejado de otra manera.

Aquí está la versión Cliffnotes de la página MSDN anterior en c # singleton:

Utilice el siguiente patrón, siempre, no puede salir mal:

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

   private Singleton(){}

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

Más allá de las características obvias de singleton, le ofrece estas dos cosas de forma gratuita (con respecto a singleton en c ++):

1. construcción perezosa (o ninguna construcción si nunca se llamó)
2. sincronización

Se garantiza que los constructores estáticos se dispararán solo una vez por dominio de aplicación, por lo que su enfoque debería ser correcto. Sin embargo, funcionalmente no es diferente de la versión en línea más concisa:

private static readonly Singleton instance = new Singleton();

La seguridad de subprocesos es más un problema cuando está inicializando cosas perezosamente.

El constructor estático terminará de ejecutarse antes de que cualquier hilo pueda acceder a la clase.

    private class InitializerTest
    {
        static private int _x;
        static public string Status()
        {
            return "_x = " + _x;
        }
        static InitializerTest()
        {
            System.Diagnostics.Debug.WriteLine("InitializerTest() starting.");
            _x = 1;
            Thread.Sleep(3000);
            _x = 2;
            System.Diagnostics.Debug.WriteLine("InitializerTest() finished.");
        }
    }

    private void ClassInitializerInThread()
    {
        System.Diagnostics.Debug.WriteLine(Thread.CurrentThread.GetHashCode() + ": ClassInitializerInThread() starting.");
        string status = InitializerTest.Status();
        System.Diagnostics.Debug.WriteLine(Thread.CurrentThread.GetHashCode() + ": ClassInitializerInThread() status = " + status);
    }

    private void classInitializerButton_Click(object sender, EventArgs e)
    {
        new Thread(ClassInitializerInThread).Start();
        new Thread(ClassInitializerInThread).Start();
        new Thread(ClassInitializerInThread).Start();
    }

El código anterior produjo los resultados a continuación.

10: ClassInitializerInThread() starting.
11: ClassInitializerInThread() starting.
12: ClassInitializerInThread() starting.
InitializerTest() starting.
InitializerTest() finished.
11: ClassInitializerInThread() status = _x = 2
The thread 0x2650 has exited with code 0 (0x0).
10: ClassInitializerInThread() status = _x = 2
The thread 0x1f50 has exited with code 0 (0x0).
12: ClassInitializerInThread() status = _x = 2
The thread 0x73c has exited with code 0 (0x0).

Aunque el constructor estático tardó mucho en ejecutarse, los otros subprocesos se detuvieron y esperaron. Todos los hilos leen el valor de _x establecido en la parte inferior del constructor estático.

La especificación de Common Language Infrastructure garantiza que "un inicializador de tipo se ejecutará exactamente una vez para cualquier tipo dado, a menos que el código de usuario lo llame explícitamente". (Sección 9.5.3.1.) Entonces, a menos que tenga un poco de IL en la llamada suelta Singleton ::. Cctor directamente (poco probable) su constructor estático se ejecutará exactamente una vez antes de que se use el tipo Singleton, solo se creará una instancia de Singleton, y su propiedad de instancia es segura para subprocesos.

Tenga en cuenta que si el constructor de Singleton accede a la propiedad Instancia (incluso indirectamente), la propiedad Instancia será nula. Lo mejor que puede hacer es detectar cuándo sucede esto y lanzar una excepción, verificando que esa instancia no sea nula en el descriptor de acceso a la propiedad. Después de que su constructor estático se complete, la propiedad Instancia no será nula.

Como señala la respuesta de Zoomba, deberá hacer que Singleton sea seguro para acceder desde múltiples subprocesos, o implementar un mecanismo de bloqueo utilizando la instancia de singleton.

Solo para ser pedante, pero no existe un constructor estático, sino más bien inicializadores de tipo estático, aquí hay una pequeña demostración de la dependencia cíclica del constructor estático que ilustra este punto.

El constructor estático garantiza la seguridad de los hilos. Además, consulte la discusión sobre Singleton en DeveloperZen: http://web.archive.org/web/20160404231134/http://www.developerzen.com/2007/07/15/whats-wrong-with-this-code -1-discusión /

Aunque otras respuestas son en su mayoría correctas, hay otra advertencia con los constructores estáticos.

Según la sección II.10.5.3.3 Razas y puntos muertos de la infraestructura de lenguaje común ECMA-335

La inicialización de tipo por sí sola no creará un punto muerto a menos que algún código invocado desde un inicializador de tipo (directa o indirectamente) invoque explícitamente operaciones de bloqueo.

El siguiente código da como resultado un punto muerto

using System.Threading;
class MyClass
{
    static void Main() { /* Won’t run... the static constructor deadlocks */  }

    static MyClass()
    {
        Thread thread = new Thread(arg => { });
        thread.Start();
        thread.Join();
    }
}

El autor original es Igor Ostrovsky, vea su publicación aquí .