Czy dostęp do zmiennej w C# jest operacją atomową?

Jest to (zła) forma wzorca blokowania podwójnego sprawdzenia, który jest , a nie wątkiem bezpiecznym W C#!

Jest jeden duży problem w tym kodzie:

S_Initialized nie jest lotny. Oznacza to, że zapis w kodzie inicjalizacyjnym może się poruszać po ustawieniu s_initialized na true, a inne wątki mogą zobaczyć niezainializowany Kod, nawet jeśli s_initialized jest dla nich prawdą. Nie dotyczy to implementacji frameworka firmy Microsoft, ponieważ każdy zapis jest zapisem zmiennym.

Ale również w implementacji Microsoftu odczyt niezainicjalizowanych danych może być ponownie uporządkowany (tj. wstępnie ustawiony przez Procesor), więc jeśli s_initialized jest prawdą, odczyt danych, które powinny być zainicjalizowane, może skutkować odczytaniem starych, niezainicjalizowanych danych z powodu Cache-hits (tj. odczyty są zmieniane).

Na przykład:

Thread 1 reads s_Provider (which is null)  
Thread 2 initializes the data  
Thread 2 sets s\_Initialized to true  
Thread 1 reads s\_Initialized (which is true now)  
Thread 1 uses the previously read Provider and gets a NullReferenceException

Przeniesienie odczytu s_Provider przed odczytem s_Initialized jest całkowicie legalne, ponieważ nigdzie nie ma zmiennego odczytu.

Jeśli s_Initialized będzie volatile, odczyt s_Provider nie będzie mógł się poruszać przed odczytem s_Initialized, a także inicjalizacja dostawcy nie będzie mogła się poruszać po ustawieniu s_initialized na true i wszystko jest teraz w porządku.

Joe Duffy napisał również artykuł o tym problemie: Broken variants on double-checked locking

Poczekaj ... pytanie, które jest w tytule, zdecydowanie nie jest prawdziwym pytaniem, które zadaje Rory.

Tytułowe pytanie ma prostą odpowiedź " Nie " - ale to wcale nie pomaga, gdy widzisz prawdziwe pytanie - na które chyba nikt nie dał prostej odpowiedzi.

Prawdziwe pytanie, które zadaje Rory, jest przedstawione znacznie później i jest bardziej trafne do przykładu, który podaje.

Dlaczego pole s_Initialized jest odczytywane poza zamek?

Odpowiedź na to pytanie jest również prosta, choć zupełnie niezwiązana z atomicznością zmiennego dostępu.

Pole s_Initialized jest odczytywane poza blokadą, ponieważ blokady są drogie.

Ponieważ pole s_Initialized jest zasadniczo "write once", nigdy nie zwróci fałszywie dodatniego wyniku.

Jest to ekonomiczne, aby odczytać go poza zamkiem.

Jest to niski koszt aktywność z wysoki szansa na korzyści.

Dlatego jest odczytywany poza zamkiem - aby uniknąć ponoszenia kosztów używania zamka, chyba że jest wskazany.

Gdyby zamki były tanie, kod byłby prostszy i pomijałby pierwszą kontrolę.

(edit: miła odpowiedź rory. Odczyty logiczne są bardzo atomowe. Gdyby ktoś zbudował procesor z niematomicznymi odczytami boolean, byłby opisywany na DailyWTF.)

Prawidłowa odpowiedź brzmi: "tak, głównie."

1. odpowiedź Johna odnosząca się do specyfikacji CLI wskazuje, że dostęp do zmiennych nie większych niż 32 bity na 32-bitowym procesorze jest atomowy.

2. Dalsze potwierdzenie ze specyfikacji C#, sekcja 5.5, Atomiczność odniesień zmiennych :

   Odczyt i zapis następujących typów danych są atomowe: bool, char, byte, sbyte, short, ushort, uint, int, float i typy referencyjne. Ponadto czyta i zapisy typów enum z typem bazowym na poprzedniej liście są również atomowe. Odczyty i zapisy innych typów, w tym long, ulong, double i decimal, jak również typów zdefiniowanych przez użytkownika, nie są gwarantowane jako atomowe.

3. Kod w moim przykładzie został sparafrazowany z klasy członkowskiej, napisanej przez ASP.NET zespół się, więc zawsze można było założyć, że sposób uzyskiwania dostępu do pola s_Initialized jest poprawny. Teraz wiemy dlaczego.

Edytuj: Jak zauważa Thomas Danecker, mimo że dostęp do pola jest atomowy, s_Initialized naprawdę powinien być oznaczony volatile, aby upewnić się, że blokada nie zostanie przerwana przez procesor zmieniający kolejność odczytów i zapisów.

Funkcja Initialize jest nieprawidłowa. Powinno to wyglądać bardziej TAK:

private static void Initialize()
{
    if(s_initialized)
        return;

    lock(s_lock)
    {
        if(s_Initialized)
            return;
        s_Initialized = true;
    }
}

Bez drugiego sprawdzenia wewnątrz zamka możliwe, że kod inicjujący zostanie wykonany dwukrotnie. Tak więc pierwsza kontrola polega na tym, aby wydajność oszczędziła niepotrzebnie robienia blokady, a druga sprawdza przypadek, w którym wątek wykonuje kod inicjujący, ale nie ustawił jeszcze znacznika s_Initialized, a więc drugi wątek przejdzie pierwszą kontrolę i będzie czekał na blokadę.

Odczyty i zapisy zmiennych nie są atomowe. Musisz użyć interfejsów API synchronizacji, aby emulować atomowe odczyty/zapisy.

Aby dowiedzieć się więcej o tym i wielu innych kwestiach związanych z współbieżnością, Pobierz kopię najnowszego spektaklu Joe Duffy ' ego . To Rozpruwacz!

" czy dostęp do zmiennej w C# jest operacją atomową?"

Nie. I nie chodzi o C#, ani nawet o. net, tylko o procesor.

OJ jest na miejscu, że Joe Duffy jest facetem, aby przejść do tego rodzaju informacji. A "interlocked" to świetny termin wyszukiwania, jeśli chcesz wiedzieć więcej.

"Torn reads" może wystąpić na dowolnej wartości, której pola są większe niż rozmiar wskaźnika.

@Leon
Rozumiem twój punkt widzenia-sposób, w jaki zadałem, a następnie skomentowałem, pytanie pozwala na podjęcie go na kilka różnych sposobów.

Aby było jasne, chciałem wiedzieć, czy jest bezpieczne, aby współbieżne wątki odczytywały i zapisywały do pola logicznego bez wyraźnego kodu synchronizacji, tzn.

Następnie użyłem kodu członkostwa, aby podać konkretny przykład, ale to wprowadziło kilka zakłóceń, podobnie jak blokowanie double-check, fakt, że s_Initialized jest ustawiany tylko raz, i że skomentowałem sam kod inicjalizacyjny.

Mój błąd.

Można również ozdobić s_Initialized słowem kluczowym volatile i całkowicie zrezygnować z używania lock.

Myślę, że pytasz, czy s_Initialized może być w niestabilnym stanie, gdy odczyt poza zamkiem. Krótka odpowiedź brzmi: nie. Proste przypisanie / odczyt sprowadzi się do pojedynczej instrukcji montażu, która jest atomowa na każdym procesorze, o którym mogę myśleć.

Nie jestem pewien, jaki jest przypadek przypisania do zmiennych 64 bitowych, to zależy od procesora, zakładam, że nie jest atomowy, ale prawdopodobnie jest na nowoczesnych procesorach 32 bitowych i na pewno na wszystkich procesorach 64 bitowych. Przypisanie kompleksu typy wartości nie będą atomowe.

Myślałem, że były - nie jestem pewien punktu blokady w twoim przykładzie, chyba że jednocześnie robisz coś z s_Provider - wtedy blokada zapewni, że te połączenia będą miały miejsce razem.

Czy to //Perform initialization komentarz pokrywa tworzenie s_provider? Na przykład

private static void Initialize()
{
    if (s_Initialized)
        return;

    lock(s_lock)
    {
        s_Provider = new MembershipProvider ( ... )
        s_Initialized = true;
    }
}

W przeciwnym razie ta statyczna właściwość-get i tak zwróci null.

Być może daje wskazówkę. A poza tym całkiem nieźle.

Domyśliłbym się, że nie są atomowe.

Aby Twój kod zawsze działał na słabo uporządkowanych architekturach, musisz umieścić MemoryBarrier przed napisaniem s_Initialized.

s_Provider = new MemershipProvider;

// MUST PUT BARRIER HERE to make sure the memory writes from the assignment
// and the constructor have been wriitten to memory
// BEFORE the write to s_Initialized!
Thread.MemoryBarrier();

// Now that we've guaranteed that the writes above
// will be globally first, set the flag
s_Initialized = true;

Zapis pamięci, który ma miejsce w Konstruktorze MembershipProvider i zapis do s_provider nie jest gwarantowany przed zapisem do s_initialized na słabo uporządkowanym procesorze.

Wiele myśli w tym wątku jest o tym, czy coś jest atomowe, czy nie. Nie o to chodzi. Problemem jest kolejność, w której Twój wątek zapisy są widoczne dla innych wątków . Na słabo uporządkowanych architekturach zapis do pamięci nie występuje w kolejności i to jest prawdziwy problem, a nie to, czy zmienna mieści się w szynie danych.

EDIT: właściwie, mieszam platformy w moich wypowiedziach. W C# Specyfikacja CLR wymaga, aby zapisy były widoczne globalnie, w kolejności (używając drogich instrukcji dla każdego sklepu, jeśli to konieczne). Dlatego nie musisz mieć tej bariery pamięci. Gdyby jednak C lub c++ w przypadku, gdy nie ma takiej gwarancji globalnego porządku widoczności, a twoja docelowa platforma może mieć słabo uporządkowaną pamięć i jest wielowątkowa, musisz upewnić się, że zapisy konstruktorów są globalnie widoczne przed aktualizacją s_initialized, która jest testowana poza blokadą.

An If (itisso) { sprawdzanie logiki jest atomowe, ale nawet jeśli nie było nie ma potrzeby blokowania pierwszej kontroli.

Jeśli jakikolwiek wątek zakończył inicjalizację, to będzie to prawda. Nie ma znaczenia, czy kilka wątków sprawdza się jednocześnie. Wszyscy otrzymają tę samą odpowiedź i nie będzie konfliktu.

Drugie sprawdzenie wewnątrz blokady jest konieczne, ponieważ inny wątek mógł chwycić blokadę jako pierwszy i już zakończył proces inicjalizacji.

To, o co pytasz, to czy dostęp do pola w metodzie jest wielokrotnie atomowy -- na co odpowiedź brzmi nie.

W powyższym przykładzie procedura initialise jest nieprawidłowa, ponieważ może spowodować wielokrotne inicjowanie. Należy sprawdzić flagę s_Initialized wewnątrz zamka, jak również na zewnątrz, aby zapobiec Warunkom wyścigu, w którym wiele wątków odczytuje flagę s_Initialized, zanim któryś z nich faktycznie wykona kod inicjalizacji. Np.,

private static void Initialize()
{
    if (s_Initialized)
        return;

    lock(s_lock)
    {
        if (s_Initialized)
            return;
        s_Provider = new MembershipProvider ( ... )
        s_Initialized = true;
    }
}

ACK, nevermind... jak wskazano, jest to rzeczywiście błędne. Nie uniemożliwia to drugiemu wątkowi wejścia w sekcję kodu "initialize". Bah.

Można również ozdobić s_Initialized słowem kluczowym volatile i całkowicie zrezygnować z używania lock.