O thread do construtor estático do C # é seguro?

Em outras palavras, esse segmento de implementação Singleton é seguro:

public class Singleton
{
    private static Singleton instance;

    private Singleton() { }

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

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

É garantido que os construtores estáticos sejam executados apenas uma vez por domínio de aplicativo, antes de qualquer instância de uma classe ser criada ou qualquer membro estático ser acessado. https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/static-constructors

A implementação mostrada é segura para threads para a construção inicial, ou seja, nenhum teste de bloqueio ou nulo é necessário para a construção do objeto Singleton. No entanto, isso não significa que qualquer uso da instância será sincronizado. Existem várias maneiras de fazer isso; Eu mostrei um abaixo.

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

Embora todas essas respostas dêem a mesma resposta geral, há uma ressalva.

Lembre-se de que todas as derivações potenciais de uma classe genérica são compiladas como tipos individuais. Portanto, tenha cuidado ao implementar construtores estáticos para tipos genéricos.

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

EDITAR:

Aqui está a demonstração:

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

No console:

Hit System.Object
Hit System.String

Usar um construtor estático é realmente seguro para threads. O construtor estático é garantido para ser executado apenas uma vez.

Na especificação da linguagem C # :

O construtor estático de uma classe é executado no máximo uma vez em um determinado domínio de aplicativo. A execução de um construtor estático é acionada pelo primeiro dos seguintes eventos dentro de um domínio de aplicativo:

• Uma instância da classe é criada.
• Qualquer um dos membros estáticos da classe é referenciado.

Então, sim, você pode confiar que seu singleton será instanciado corretamente.

Zooba fez um excelente argumento (e 15 segundos antes de mim também!) De que o construtor estático não garantirá o acesso compartilhado seguro por thread ao singleton. Isso precisará ser tratado de outra maneira.

Aqui está a versão Cliffnotes da página acima do MSDN em c # singleton:

Use o seguinte padrão, sempre, você não pode dar errado:

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

   private Singleton(){}

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

Além dos recursos óbvios do singleton, ele oferece essas duas coisas de graça (em relação ao singleton em c ++):

1. construção preguiçosa (ou nenhuma construção, se nunca foi chamada)
2. sincronização

É garantido que os construtores estáticos são acionados apenas uma vez por domínio de aplicativo, portanto sua abordagem deve ser boa. No entanto, funcionalmente não é diferente da versão mais concisa e em linha:

private static readonly Singleton instance = new Singleton();

A segurança do encadeamento é mais um problema quando você está inicializando preguiçosamente as coisas.

O construtor estático terminará a execução antes que qualquer thread possa acessar a classe.

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

O código acima produziu os resultados abaixo.

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).

Embora o construtor estático tenha demorado muito para ser executado, os outros threads pararam e esperaram. Todos os threads lêem o valor de _x definido na parte inferior do construtor estático.

A especificação Common Language Infrastructure garante que "um inicializador de tipo seja executado exatamente uma vez para qualquer tipo, a menos que seja explicitamente chamado pelo código do usuário". (Seção 9.5.3.1.) Portanto, a menos que você tenha alguma IL louca na chamada solta Singleton ::. Cctor diretamente (improvável), seu construtor estático será executado exatamente uma vez antes que o tipo Singleton seja usado, apenas uma instância do Singleton será criada, e sua propriedade Instance é segura para threads.

Observe que, se o construtor de Singleton acessar a propriedade Instance (mesmo que indiretamente), a propriedade Instance será nula. O melhor que você pode fazer é detectar quando isso acontece e lançar uma exceção, verificando se a instância não é nula no acessador de propriedade. Após a conclusão do construtor estático, a propriedade Instance será não nula.

Como a resposta de Zoomba aponta, você precisará tornar o Singleton seguro para acessar a partir de vários threads ou implementar um mecanismo de bloqueio usando a instância singleton.

Só para ser pedante, mas não existe construtor estático, mas inicializadores de tipo estático, aqui está uma pequena demonstração da dependência cíclica do construtor estático que ilustra esse ponto.

O construtor estático é garantido como seguro para threads. Além disso, confira a discussão sobre Singleton no DeveloperZen: http://www.developerzen.com/2007/07/15/whats-wrong-with-this-code-1-discussion/

Embora outras respostas estejam na maior parte corretas, há ainda outra ressalva com os construtores estáticos.

De acordo com a seção II.10.5.3.3, corridas e impasses da infraestrutura de idioma comum ECMA-335

A inicialização de tipo sozinha não deve criar um conflito, a menos que algum código chamado de um inicializador de tipo (direta ou indiretamente) invoque explicitamente operações de bloqueio.

O código a seguir resulta em um conflito

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

O autor original é Igor Ostrovsky, veja seu post aqui .