Czy wątek konstruktora statycznego C # jest bezpieczny?

Innymi słowy, czy ten wątek implementacyjny Singleton jest bezpieczny:

public class Singleton
{
    private static Singleton instance;

    private Singleton() { }

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

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

Gwarantuje się, że statyczne konstruktory są uruchamiane tylko raz na domenę aplikacji, przed utworzeniem instancji klasy lub dostępem do elementów statycznych. https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/static-constructors

Przedstawiona implementacja jest wątkowo bezpieczna dla początkowej konstrukcji, to znaczy, nie jest wymagane blokowanie ani testowanie zerowe do budowy obiektu Singleton. Nie oznacza to jednak, że wszelkie użycie instancji zostanie zsynchronizowane. Można to zrobić na wiele sposobów; Pokazałem jeden poniżej.

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

Chociaż wszystkie te odpowiedzi dają tę samą ogólną odpowiedź, jest jedno zastrzeżenie.

Pamiętaj, że wszystkie potencjalne pochodne klasy ogólnej są zestawiane jako poszczególne typy. Dlatego należy zachować ostrożność przy wdrażaniu konstruktorów statycznych dla typów ogólnych.

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

EDYTOWAĆ:

Oto demonstracja:

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

W konsoli:

Hit System.Object
Hit System.String

Korzystanie z konstruktora statycznego jest w rzeczywistości bezpieczne dla wątków. Konstruktor statyczny może zostać wykonany tylko raz.

Ze specyfikacji języka C # :

Konstruktor statyczny dla klasy wykonuje się najwyżej raz w danej domenie aplikacji. Wykonanie konstruktora statycznego jest wyzwalane przez pierwsze z następujących zdarzeń, które mają miejsce w domenie aplikacji:

• Utworzono instancję klasy.
• Odwołanie dotyczy dowolnego statycznego elementu klasy.

Więc tak, możesz ufać, że twój singleton zostanie poprawnie utworzony.

Zooba doskonale podkreśliła (i 15 sekund przede mną!), Że statyczny konstruktor nie gwarantuje bezpiecznego wątku wspólnego dostępu do singletonu. Trzeba to potraktować w inny sposób.

Oto wersja Cliffnotes z powyższej strony MSDN na c # singleton:

Użyj następującego wzoru, zawsze nie możesz się pomylić:

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

   private Singleton(){}

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

Poza oczywistymi funkcjami singletonu, daje ci te dwie rzeczy za darmo (w odniesieniu do singletonu w c ++):

1. leniwa konstrukcja (lub brak konstrukcji, jeśli nigdy nie została wywołana)
2. synchronizacja

Konstruktory statyczne mają gwarancję, że będą uruchamiane tylko raz na domenę aplikacji, więc twoje podejście powinno być OK. Jednak funkcjonalnie nie różni się od bardziej zwięzłej, wbudowanej wersji:

private static readonly Singleton instance = new Singleton();

Bezpieczeństwo wątków jest większym problemem, gdy leniwie inicjujesz różne rzeczy.

Konstruktor statyczny zakończy działanie wcześniej dowolny wątek dostęp do klasy.

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

Powyższy kod wygenerował poniższe wyniki.

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

Mimo że statyczny konstruktor długo działał, pozostałe wątki zatrzymały się i czekały. Wszystkie wątki odczytują wartość _x ustawioną na dole konstruktora statycznego.

Specyfikacja Common Language Infrastructure gwarantuje, że „inicjalizator typu będzie uruchamiany dokładnie raz dla każdego typu, chyba że zostanie wyraźnie wywołany przez kod użytkownika”. (Sekcja 9.5.3.1.) Jeśli więc nie masz jakiejś zwariowanej IL na luźnym wywołaniu Singleton ::. Cctor bezpośrednio (mało prawdopodobne), twój konstruktor statyczny uruchomi się dokładnie raz przed użyciem typu Singleton, zostanie utworzona tylko jedna instancja Singleton, a twoja właściwość Instancji jest bezpieczna dla wątków.

Należy zauważyć, że jeśli konstruktor Singleton uzyskuje dostęp do właściwości Instancji (nawet pośrednio), wówczas właściwość Instancji będzie miała wartość NULL. Najlepsze, co możesz zrobić, to wykryć, kiedy to nastąpi, i zgłosić wyjątek, sprawdzając, czy instancja nie ma wartości NULL w module dostępu do właściwości. Po zakończeniu konstruktora statycznego właściwość Instancja będzie inna niż null.

Jak wskazuje odpowiedź Zoomba, będziesz musiał zapewnić Singletonowi bezpieczny dostęp z wielu wątków lub zaimplementować mechanizm blokujący za pomocą instancji singletonu.

Po prostu pedantyczny, ale nie ma czegoś takiego jak konstruktor statyczny, ale raczej inicjatory typu statycznego, oto mała demonstracja zależności cyklicznego konstruktora statycznego, która ilustruje ten punkt.

Konstruktor statyczny gwarantuje bezpieczeństwo wątków. Zapoznaj się także z dyskusją na temat Singleton na stronie DeveloperZen: http://web.archive.org/web/20160404231134/http://www.developerzen.com/2007/07/15/whats-wrong-with-this-code -1-dyskusja /

Chociaż inne odpowiedzi są w większości poprawne, istnieje jeszcze jedno zastrzeżenie dotyczące konstruktorów statycznych.

Zgodnie z § II.10.5.3.3 ras i zakleszczenia na Infrastruktury ECMA-335 wspólny język

Sama inicjacja typu nie spowoduje zakleszczenia, chyba że jakiś kod wywołany z inicjatora typu (bezpośrednio lub pośrednio) wyraźnie wywoła operacje blokowania.

Poniższy kod powoduje zakleszczenie

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

Oryginalnym autorem jest Igor Ostrovsky, zobacz jego post tutaj .