Czy num++ może być atomowe dla 'int num'?

...a teraz włączmy optymalizacje:

f():
        rep ret

OK, dajmy temu szansę:

void f(int& num)
{
  num = 0;
  num++;
  --num;
  num += 6;
  num -=5;
  --num;
}

Wynik:

f(int&):
        mov     DWORD PTR [rdi], 0
        ret

Inny Obserwujący wątek (nawet ignorując opóźnienia synchronizacji pamięci podręcznej) nie ma możliwości obserwowania poszczególnych zmian.

Porównaj z:

#include <atomic>

void f(std::atomic<int>& num)
{
  num = 0;
  num++;
  --num;
  num += 6;
  num -=5;
  --num;
}

Gdzie wynikiem jest:

f(std::atomic<int>&):
        mov     DWORD PTR [rdi], 0
        mfence
        lock add        DWORD PTR [rdi], 1
        lock sub        DWORD PTR [rdi], 1
        lock add        DWORD PTR [rdi], 6
        lock sub        DWORD PTR [rdi], 5
        lock sub        DWORD PTR [rdi], 1
        ret

Teraz każda modyfikacja to:-

1. obserwowalne w innym wątku i
2. respektując podobne modyfikacje zachodzące w innych nici.

Atomicity nie jest tylko na poziomie instrukcji, obejmuje cały rurociąg od procesora, przez pamięć podręczną, do pamięci i z powrotem.

Dalsze informacje

Dotyczące efektu optymalizacji aktualizacji std::atomics.

Zasada as-if jest konserwatywna, w szczególności dotyczy atomiki.

Rozważmy:

void incdec(int& num) {
    ++num;
    --num;
}

Ponieważ nie ma blokad mutex, Atomic ani żadnych innych konstrukcji wpływających na sekwencjonowanie między wątkami, argumentowałbym, że kompilator może dowolnie przepisać tę funkcję jako NOP, np:

void incdec(int&) {
    // nada
}

Dzieje się tak dlatego, że w modelu pamięci c++ nie ma możliwości, aby inny wątek obserwował wynik przyrostu. Oczywiście. być inne, jeśli num było volatile (może wpływać na zachowanie sprzętu). Ale w tym przypadku ta funkcja będzie jedyną funkcją modyfikującą tę pamięć (w przeciwnym razie program jest źle uformowany).

void incdec(std::atomic<int>& num) {
    ++num;
    --num;
}

num jest atomowy. Zmiany w nimmuszą być widoczne dla innych wątków, które oglądają. Zmiany, które same wprowadzają te wątki (takie jak ustawienie wartości na 100 pomiędzy przyrostem i zmniejszeniem) będą miały bardzo dalekosiężny wpływ na ostateczną wartość num.

Oto demo:

#include <thread>
#include <atomic>

int main()
{
    for (int iter = 0 ; iter < 20 ; ++iter)
    {
        std::atomic<int> num = { 0 };
        std::thread t1([&] {
            for (int i = 0 ; i < 10000000 ; ++i)
            {
                ++num;
                --num;
            }
        });
        std::thread t2([&] {
            for (int i = 0 ; i < 10000000 ; ++i)
            {
                num = 100;
            }
        });
        
        t2.join();
        t1.join();
        std::cout << num << std::endl;
    }
}

Przykładowe wyjście:

99
99
99
99
99
100
99
99
100
100
100
100
99
99
100
99
99
100
100
99

Bez wielu komplikacji instrukcja jak add DWORD PTR [rbp-4], 1 jest bardzo CISC stylu.

Wykonuje trzy operacje: załaduj operand z pamięci, zwiększ go, Zapisz operand z powrotem do pamięci.
Podczas tych operacji CPU nabywa i zwalnia magistralę dwa razy, między innymi każdy inny agent może ją zdobyć, a to narusza atomiczność.

AGENT 1          AGENT 2

load X              
inc C
                 load X
                 inc C
                 store X
store X

X jest zwiększany tylko raz.

Instrukcja add jest a nie atomowa. Odwołuje się do pamięci, a dwa rdzenie procesora mogą mieć różną lokalną pamięć podręczną tej pamięci.

IIRC atomowy wariant instrukcji add nazywa się lock xadd

Ponieważ linia 5, która odpowiada num++ jest jedną instrukcją, czy możemy wnioskować, że num++ jest atomowe w tym przypadku?

Niebezpieczne jest wyciąganie wniosków w oparciu o" inżynierię odwrotną " generowanego zespołu. Na przykład, wydaje się, że skompilowałeś kod z wyłączoną optymalizacją, w przeciwnym razie kompilator wyrzuciłby tę zmienną lub załadowałby 1 bezpośrednio do niej bez wywoływania operator++. Ponieważ generowany zespół może się znacznie zmienić, w oparciu o optymalizację flagi, procesor docelowy itp., twój wniosek opiera się na piasku.

Nawet jeśli twój kompilator zawsze emitował to jako operację atomową, dostęp do {[2] } z dowolnego innego wątku jednocześnie stanowiłby wyścig danych zgodnie ze standardami C++11 i C++14, a program miałby nieokreślone zachowanie.

int main()
{
  std::unique_ptr<std::vector<int>> vec;
  int ready = 0;
  std::thread t{[&]
    {
       while (!ready);
       // use "vec" here
    });
  vec.reset(new std::vector<int>());
  ++ready;
  t.join();
}

Nawet jeśli przyjmiemy optymistycznie, że ++ready jest "atomowa" i że kompilator generuje pętlę sprawdzającą w razie potrzeby (jak powiedziałem, jest to UB i dlatego kompilator może ją usunąć, zastąpić nieskończoną pętlą itp.), kompilator nadal może przesunąć przypisanie wskaźnika, lub co gorsza inicjalizację vector do punktu po operacji inkrementacji, powodując chaos w nowym wątku. W praktyce nie zdziwiłbym się wszystko, jeśli kompilator optymalizujący usunął zmienną ready i pętlę sprawdzającą całkowicie, ponieważ nie wpływa to na obserwowalne zachowanie zgodnie z regułami języka(w przeciwieństwie do prywatnych nadziei).

W rzeczywistości, na zeszłorocznej konferencji Meeting C++, słyszałem od dwóch programistów, że bardzo chętnie wdrażają optymalizacje, które sprawiają, że naiwnie napisane wielowątkowe programy źle się zachowują, o ile pozwalają na to reguły języka, jeśli nawet niewielka poprawa wydajności jest widoczna w języku C++. poprawnie napisane programy.

Wreszcie, nawet jeśli Nie dbałeś o przenośność, a Twój kompilator był magicznie miły, procesor, którego używasz, jest bardzo prawdopodobny typu SUPERSALARNEGO CISC i będzie rozkładał instrukcje na mikro-operacje, zmieniał kolejność i/lub spekulatywnie je wykonywał, w stopniu ograniczonym tylko przez synchronizację prymitywów, takich jak (w Intelu) prefiks LOCK lub ogrodzenia pamięci, w celu maksymalizacji operacji na sekundę.

W skrócie mówiąc, naturalne obowiązki programowania bezpiecznego dla wątku to:

1. Twoim obowiązkiem jest pisanie kodu, który ma dobrze zdefiniowane zachowanie zgodnie z regułami języka (a w szczególności standardowym modelem pamięci języka).
2. Twoim obowiązkiem kompilatora jest generowanie kodu maszynowego, który ma takie samo dobrze zdefiniowane (obserwowalne) zachowanie w modelu pamięci docelowej architektury.
3. obowiązkiem Twojego procesora jest wykonanie tego kodu, aby obserwowane zachowanie było zgodne z jego własną architekturą model pamięci.

PS: poprawnie napisany przykład:

int main()
{
  std::unique_ptr<std::vector<int>> vec;
  std::atomic<int> ready{0}; // NOTE the use of the std::atomic template
  std::thread t{[&]
    {
       while (!ready);
       // use "vec" here
    });
  vec.reset(new std::vector<int>());
  ++ready;
  t.join();
}

Jest to bezpieczne, ponieważ:

1. sprawdzania ready nie można zoptymalizować zgodnie z regułami językowymi.
2. The ++ready dzieje się-przed czekiem, który widzi {[7] } jako nie zero, a inne operacje nie mogą być uporządkowane wokół tych operacji. Dzieje się tak dlatego, że ++ready i sprawdzanie są sekwencyjnie spójne, co jest innym terminem opisanym w modelu pamięci C++ i które zabrania tego konkretnego uporządkowania. Dlatego kompilator nie może zmieniać kolejności instrukcji, a także musi powiedzieć procesorowi, że nie może np. odłożyć zapisu do vec NA po przyroście ready. sekwencyjnie spójne jest najsilniejszą gwarancją dotyczącą atomiki w standard językowy. Mniejsze (i teoretycznie tańsze) Gwarancje są dostępne np. za pomocą innych metod std::atomic<T>, ale są one zdecydowanie tylko dla ekspertów i mogą nie być zbytnio optymalizowane przez programistów, ponieważ są rzadko używane.

Na jednordzeniowej maszynie x86 Instrukcja add będzie zazwyczaj atomowa w odniesieniu do innego kodu na procesorze¹. Przerwanie nie może rozdzielić ani jednej instrukcji na środek.

Out-of-order execution jest wymagane, aby zachować iluzję instrukcji wykonujących pojedynczo w kolejności w obrębie jednego rdzenia, więc każda instrukcja uruchomiona na tym samym procesorze stanie się całkowicie przed lub całkowicie po add.

Nowoczesne systemy x86 są wielordzeniowe, więc specjalny przypadek uniprocesora nie ma zastosowania.

Jeśli ktoś celuje w mały wbudowany komputer i nie ma planów przeniesienia kodu na cokolwiek innego, atomowa natura instrukcji "add" może zostać wykorzystana. Z drugiej strony platformy, na których operacje są z natury atomowe, stają się coraz rzadsze.

(to nie pomaga, jeśli piszesz w C++, chociaż. Kompilatory nie mają opcji wymagającej num++ kompilacji do pamięci docelowej add lub xadd BEZ a lock prefiks. Mogą wybrać załadowanie num do rejestru i zapisanie wyniku przyrostu za pomocą oddzielnej instrukcji, i prawdopodobnie zrobią to, jeśli użyjesz wyniku.)

Przypis 1: prefiks lock istniał nawet na oryginalnym 8086, ponieważ urządzenia We/Wy działają jednocześnie z procesorem; sterowniki w systemie jednordzeniowym muszą lock add atomicznie zwiększyć wartość w pamięci urządzenia, jeśli urządzenie może ją również zmodyfikować, lub w odniesieniu do dostępu DMA.

W czasach, gdy komputery x86 miały jeden procesor, użycie pojedynczej instrukcji zapewniało, że przerwania nie będą rozdzielać odczytu/modyfikacji/zapisu i jeśli pamięć nie będzie używana jako bufor DMA, w rzeczywistości była atomowa (A C++ nie wspominało o wątkach w standardzie, więc nie było to rozwiązywane).

Kiedy rzadko było mieć podwójny procesor (np. Dual-socket Pentium Pro) na pulpicie klienta, skutecznie użyłem tego, aby uniknąć prefiksu blokady na jednordzeniowej maszynie i poprawić wydajność.

Dzisiaj pomogłoby to tylko w walce z wieloma wątkami, które były ustawione na to samo powinowactwo CPU, więc wątki, o które się martwisz, wejdą w grę tylko poprzez wygaśnięcie time slice i uruchomienie drugiego wątku na tym samym procesorze (rdzeniu). To nie jest realistyczne.

W nowoczesnych procesorach x86/x64 pojedyncza instrukcja jest dzielona na kilka mikroprocesorów , a ponadto odczyt i zapis pamięci jest buforowany. Tak różne wątki działają na różne procesory nie tylko zobaczą to jako nieatomowe, ale mogą zobaczyć niespójne wyniki dotyczące tego, co czyta z pamięci i co zakłada, że inne wątki przeczytały do tego momentu: musisz dodać ogrodzenia pamięci , aby przywrócić zdrowe zachowanie.

Nie. https://www.youtube.com/watch?v=31g0YE61PLQ W odcinku "nie"pojawia się w odcinku "Biuro".]}

Czy zgadzasz się, że będzie to możliwe wyjście dla programu:

Przykładowe wyjście:

100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100

Jeśli tak, to kompilator może sprawić, że tylko będzie możliwe wyjście dla programu, niezależnie od tego, w jaki sposób kompilator chce. ie a main (), który po prostu wystawia 100s.

Jest to reguła "jak gdyby".

I niezależnie od wyjście, można myśleć o synchronizacji wątku w ten sam sposób-jeśli wątek a robi num++; num--; i wątek B czyta num wielokrotnie, to możliwe poprawne przeplatanie jest takie, że wątek B nigdy nie czyta między num++ i num--. Ponieważ to przeplatanie jest poprawne, kompilator może sprawić, że tylko będzie możliwe przeplatanie. I po prostu całkowicie usuń incr / decr.

Jest tu kilka ciekawych implikacji:

while (working())
    progress++;  // atomic, global

(tj. wyobraź sobie, że niektóre inne wątki aktualizują pasek postępu UI na podstawie progress)

Czy kompilator może zamienić to na:

int local = 0;
while (working())
    local++;

progress += local;

Prawdopodobnie jest to słuszne. Ale prawdopodobnie nie to, na co programista liczył: - (

Komitet wciąż nad tym pracuje. Obecnie "działa", ponieważ Kompilatory nie optymalizują zbytnio atomiki. Ale to się zmienia.

I nawet gdyby progress również było niestabilne, to i tak byłoby ważne:

int local = 0;
while (working())
    local++;

while (local--)
    progress++;

:-/

Tak, ale...

Atomic nie jest tym, co chciałeś powiedzieć. Pewnie pytasz źle.

Przyrost jest z pewnością atomowy . Jeśli pamięć masowa nie jest wyrównana (a ponieważ pozostawiono wyrównanie do kompilatora, nie jest), musi być wyrównana w obrębie jednej linii bufora. W przeciwieństwie do specjalnych instrukcji nie buforowania strumieniowego, każdy zapis przechodzi przez pamięć podręczną. Kompletne linie pamięci podręcznej są atomicznie odczytywane i zapisywane, nigdy nic inaczej.
Dane mniejsze od cacheline są oczywiście również zapisywane atomicznie (ponieważ otaczająca linia cache jest).

Czy to bezpieczne?

To jest inne pytanie i istnieją co najmniej dwa dobre powody, aby odpowiedzieć definitywnie "nie!".

Po pierwsze, istnieje możliwość, że inny rdzeń może mieć kopię tej linii pamięci podręcznej w L1 (L2 i w górę jest zwykle współdzielone, ale L1 jest normalnie per-core!), a jednocześnie modyfikuje tę wartość. Oczywiście, że dzieje się też atomicznie, ale teraz masz dwie" poprawne " (poprawnie, atomicznie, zmodyfikowane) wartości-która z nich jest teraz naprawdę poprawna?
Oczywiście procesor jakoś to rozwiąże. Ale wynik może nie być tym, czego oczekujesz.

Po drugie, jest kolejność pamięci, lub inaczej sformułowane dzieje się-przed gwarancjami. Najważniejszą rzeczą w instrukcjach atomowych jest nie tyle to, że są one atomowe . To rozkaz.

Masz możliwość wyegzekwowania gwarancja, że wszystko, co dzieje się w pamięci, jest realizowane w pewnej gwarantowanej, dobrze określonej kolejności, w której masz gwarancję "zdarzyło się wcześniej". To zamówienie może być tak "zrelaksowany" (Czytaj jako: w ogóle) lub tak rygorystyczne, jak trzeba.

Na przykład, możesz ustawić wskaźnik na jakiś blok danych (np. wyniki obliczeń), a następnie atomicznie zwolnić znacznik "data is ready". Ktokolwiek zdobędzie tę flagę, będzie myślał, że wskaźnik jest prawidłowy. I rzeczywiście, to będzie Zawsze być ważnym wskaźnikiem, nigdy nic innego. To dlatego, że zapis do wskaźnika miał miejsce przed operacją atomową.

To, że wyjście pojedynczego kompilatora, na określonej architekturze procesora, z wyłączonymi optymalizacjami (ponieważ gcc nawet nie kompiluje ++ do add podczas optymalizacji w szybkim i brudnym przykładzie), wydaje się sugerować, że zwiększanie w ten sposób jest atomowe, nie oznacza, że jest to zgodne ze standardami (spowodowałbyś niezdefiniowane zachowanie podczas próby uzyskania dostępu num w wątku), i tak jest złe, ponieważ add jest , a nie. Atomic w x86.

Zauważ, że Atomics (używając instrukcji lock prefix) są stosunkowo ciężkie dla x86 (zobacz tę odpowiednią odpowiedź ), ale nadal znacznie mniej niż mutex, co nie jest zbyt odpowiednie w tym przypadku użycia.

Poniższe wyniki pochodzą z clang++ 3.8 podczas kompilacji z -Os.

Zwiększenie int przez odniesienie, "regularny" sposób:

void inc(int& x)
{
    ++x;
}

To zestawia się w:

inc(int&):
    incl    (%rdi)
    retq

Inkrementacja int przekazywana przez odniesienie, droga atomowa:

#include <atomic>

void inc(std::atomic<int>& x)
{
    ++x;
}

Ten przykład, który nie jest dużo bardziej złożony niż zwykły sposób, po prostu dostaje prefiks lock dodany do instrukcji incl - ale uwaga, jak wcześniej wspomniano, jest to , a nie tanie. To, że montaż wygląda na krótki, nie oznacza, że jest szybki.

inc(std::atomic<int>&):
    lock            incl    (%rdi)
    retq

Gdy kompilator używa tylko jednej instrukcji do przyrostu, a maszyna jest jednowątkowa, kod jest bezpieczny. ^^

Spróbuj skompilować ten sam kod na maszynie innej niż x86, a szybko zobaczysz bardzo różne wyniki montażu.

Powód num++ wydaje się, że jest atomowa, ponieważ na maszynach x86 inkrementacja 32-bitowej liczby całkowitej jest w rzeczywistości atomowa (zakładając, że nie ma miejsca odzyskiwanie pamięci). Ale nie jest to gwarantowane przez standard c++, ani nie jest prawdopodobne, aby miało to miejsce na komputerze, który nie używa zestawu instrukcji x86. Więc ten kod nie jest międzyplatformowy bezpieczny od wyścigu warunki.

Nie masz także silnej gwarancji, że ten kod jest bezpieczny nawet na architekturze x86, ponieważ x86 nie ustawia obciążeń i nie zapisuje ich do pamięci, chyba że zostanie to wyraźnie określone. Tak więc, jeśli wiele wątków próbowało zaktualizować tę zmienną jednocześnie, mogą one zakończyć się zwiększeniem wartości buforowanych (nieaktualnych)

Powodem, dla którego mamy std::atomic<int> i tak dalej jest to, że gdy pracujemy z architekturą, w której atomiczność podstawowych obliczenia nie są gwarantowane, masz mechanizm, który zmusi kompilator do generowania kodu atomowego.