Program wielowątkowy utknął w trybie zoptymalizowanym, ale działa normalnie w -O0

Napisałem proste programy wielowątkowe w następujący sposób:

static bool finished = false;

int func()
{
    size_t i = 0;
    while (!finished)
        ++i;
    return i;
}

int main()
{
    auto result=std::async(std::launch::async, func);
    std::this_thread::sleep_for(std::chrono::seconds(1));
    finished=true;
    std::cout<<"result ="<<result.get();
    std::cout<<"\nmain thread id="<<std::this_thread::get_id()<<std::endl;
}

Zachowuje się normalnie w trybie debugowania w Visual Studio lub -O0w gc c i drukuje wynik po 1kilku sekundach. Ale utknął i nie drukuje niczego w trybie Release lub -O1 -O2 -O3.

Dwa wątki, uzyskujące dostęp do nieatomowej, niechronionej zmiennej to UB Dotyczy to finished. Można zrobić finishedtypu std::atomic<bool>, aby to naprawić.

Moja poprawka:

#include <iostream>
#include <future>
#include <atomic>

static std::atomic<bool> finished = false;

int func()
{
    size_t i = 0;
    while (!finished)
        ++i;
    return i;
}

int main()
{
    auto result=std::async(std::launch::async, func);
    std::this_thread::sleep_for(std::chrono::seconds(1));
    finished=true;
    std::cout<<"result ="<<result.get();
    std::cout<<"\nmain thread id="<<std::this_thread::get_id()<<std::endl;
}

Wynik:

result =1023045342
main thread id=140147660588864

Demo na żywo na coliru

Ktoś może pomyśleć: „To bool- prawdopodobnie trochę. Jak to może być nieatomowe? (Zrobiłem to, kiedy sam zacząłem z wielowątkowością.)

Ale zauważ, że brak łez nie jest jedyną rzeczą, która std::atomicci daje. Umożliwia także dobrze zdefiniowany dostęp do odczytu i zapisu z wielu wątków, uniemożliwiając kompilatorowi zakładanie, że ponowne czytanie zmiennej zawsze zobaczy tę samą wartość.

Wykonanie boolniestrzeżonego, nieatomowego atomu może powodować dodatkowe problemy:

• Kompilator może zdecydować o zoptymalizowaniu zmiennej w rejestrze lub nawet wielokrotnym dostępie CSE do jednego i wyciągnięciu obciążenia z pętli.
• Zmienna może być buforowana dla rdzenia procesora. (W prawdziwym życiu, procesory mają spójnej pamięci podręcznej . To nie jest prawdziwy problem, ale standardem C ++ jest luźna wystarczy na pokrycie hipotetyczny C ++ implementacje na niekoherentnego pamięci współdzielonej, gdzie atomic<bool>ze memory_order_relaxedsklepu / obciążenie będzie działać, ale gdzie volatilenie. Za pomocą niestabilna w tym przypadku byłaby UB, nawet jeśli działa w praktyce na rzeczywistych implementacjach C ++.)

Aby temu zapobiec, należy wyraźnie powiedzieć kompilatorowi, aby tego nie robił.

Jestem trochę zaskoczony ewoluującą dyskusją dotyczącą potencjalnego związku volatiletego problemu. Dlatego chciałbym wydać dwa centy:

• Jest niestabilny przydatne w wątkach
• Kto się boi wielkiego, źle zoptymalizowanego kompilatora? .

Odpowiedź Scheffa opisuje, jak naprawić twój kod. Pomyślałem, że dodam trochę informacji o tym, co faktycznie dzieje się w tej sprawie.

Skompilowałem Twój kod na Godbolt, używając poziomu optymalizacji 1 ( -O1). Twoja funkcja kompiluje się tak:

func():
  cmp BYTE PTR finished[rip], 0
  jne .L4
.L5:
  jmp .L5
.L4:
  mov eax, 0
  ret

Co się tu dzieje? Po pierwsze, mamy porównanie: cmp BYTE PTR finished[rip], 0- to sprawdza, czy finishedjest fałszywe, czy nie.

Jeśli nie jest to fałsz (inaczej prawda), powinniśmy wyjść z pętli przy pierwszym uruchomieniu. To osiągnąć przez jne .L4który j umps gdy n ot e qual do etykiety .L4, gdy wartość i( 0) przechowywana jest w rejestrze do późniejszego wykorzystania i powrót funkcji.

Jeśli jednak jest to fałsz, przechodzimy do

.L5:
  jmp .L5

Jest to bezwarunkowy skok, .L5którego etykietą jest tak naprawdę samo polecenie skoku.

Innymi słowy, wątek jest umieszczany w nieskończonej zajętej pętli.

Dlaczego to się stało?

Jeśli chodzi o optymalizator, wątki są poza jego zakresem. Zakłada, że ​​inne wątki nie odczytują ani nie zapisują zmiennych jednocześnie (ponieważ byłoby to UB wyścigu danych). Musisz powiedzieć, że nie może zoptymalizować dostępu. Właśnie tutaj pojawia się odpowiedź Scheffa. Nie zawracam sobie głowy powtórzeniem go.

Ponieważ optymalizatorowi nie powiedziano, że finishedzmienna może potencjalnie ulec zmianie podczas wykonywania funkcji, widzi, że finishednie jest modyfikowana przez samą funkcję i zakłada, że ​​jest stała.

Zoptymalizowany kod zapewnia dwie ścieżki kodu, które będą wynikały z wejścia do funkcji ze stałą wartością bool; albo uruchamia pętlę nieskończenie, albo pętla nigdy nie jest uruchamiana.

w -O0kompilatorze (zgodnie z oczekiwaniami) nie optymalizuje treści pętli i porównuje:

func():
  push rbp
  mov rbp, rsp
  mov QWORD PTR [rbp-8], 0
.L148:
  movzx eax, BYTE PTR finished[rip]
  test al, al
  jne .L147
  add QWORD PTR [rbp-8], 1
  jmp .L148
.L147:
  mov rax, QWORD PTR [rbp-8]
  pop rbp
  ret

dlatego funkcja, gdy niezoptymalizowana działa, brak atomowości tutaj zwykle nie stanowi problemu, ponieważ kod i typ danych są proste. Prawdopodobnie najgorsze, na co moglibyśmy się tutaj natknąć, to wartość, iktóra nie jest zgodna z tym, co powinno być.

Bardziej złożony system ze strukturami danych znacznie bardziej prawdopodobne jest uszkodzenie danych lub nieprawidłowe wykonanie.

Ze względu na kompletność w krzywej uczenia się; powinieneś unikać używania zmiennych globalnych. Wykonałeś dobrą robotę, ustawiając go na statyczny, więc będzie on lokalny dla jednostki tłumaczącej.

Oto przykład:

class ST {
public:
    int func()
    {
        size_t i = 0;
        while (!finished)
            ++i;
        return i;
    }
    void setFinished(bool val)
    {
        finished = val;
    }
private:
    std::atomic<bool> finished = false;
};

int main()
{
    ST st;
    auto result=std::async(std::launch::async, &ST::func, std::ref(st));
    std::this_thread::sleep_for(std::chrono::seconds(1));
    st.setFinished(true);
    std::cout<<"result ="<<result.get();
    std::cout<<"\nmain thread id="<<std::this_thread::get_id()<<std::endl;
}

Na żywo w Wandbox