Il programma multithreading è bloccato in modalità ottimizzata ma funziona normalmente in -O0

Ho scritto un semplice programma di multithreading come segue:

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

Si comporta normalmente in modalità debug in Visual Studio o -O0in gc c e stampa il risultato dopo 1pochi secondi. Ma è bloccato e non stampa nulla in modalità di rilascio o -O1 -O2 -O3.

Due thread, accedendo a una variabile non atomica, non protetta sono UB Questo riguarda finished. Si potrebbe fare finisheddi tipo std::atomic<bool>per risolvere questo problema.

La mia correzione:

#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;
}

Produzione:

result =1023045342
main thread id=140147660588864

Demo live su coliru

Qualcuno potrebbe pensare 'È un bool- probabilmente un po'. Come può essere non atomico? (L'ho fatto quando ho iniziato con il multi-thread me stesso.)

Ma nota che la mancanza di lacrimazione non è l'unica cosa che std::atomicti dà. Rende inoltre ben definito l'accesso simultaneo in lettura e scrittura da più thread, impedendo al compilatore di assumere che la rilettura della variabile visualizzi sempre lo stesso valore.

Rendere un boolnon custodito, non atomico può causare ulteriori problemi:

• Il compilatore potrebbe decidere di ottimizzare la variabile in un registro o persino CSE in più accessi in uno e sollevare un carico da un ciclo.
• La variabile potrebbe essere memorizzata nella cache per un core della CPU. (Nella vita reale, le CPU hanno cache coerenti . Questo non è un problema reale, ma lo standard C ++ è abbastanza lento da coprire ipotetiche implementazioni C ++ su memoria condivisa non coerente dove atomic<bool>con memory_order_relaxedarchivio / carico funzionerebbe, ma dove volatilenon funzionerebbe. volatile per questo sarebbe UB, anche se funziona in pratica su implementazioni C ++ reali.)

Per evitare che ciò accada, al compilatore deve essere esplicitamente detto di non farlo.

Sono un po 'sorpreso dall'evolversi della discussione sulla potenziale relazione di volatilequesto problema. Quindi, vorrei spendere i miei due centesimi:

• È volatile utile con i thread
• Chi ha paura di un compilatore male ottimizzato? .

La risposta di Scheff descrive come riparare il tuo codice. Ho pensato di aggiungere alcune informazioni su ciò che sta realmente accadendo in questo caso.

Ho compilato il tuo codice su godbolt usando il livello di ottimizzazione 1 ( -O1). La tua funzione si compila così:

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

Quindi, cosa sta succedendo qui? Innanzitutto, abbiamo un confronto: cmp BYTE PTR finished[rip], 0- questo controlla se finishedè falso o no.

Se è non è falso (aka vero) dobbiamo uscire dal ciclo alla prima esecuzione. Ciò ottiene jne .L4che j UMPS quando n ot e qual all'etichetta .L4cui il valore di i( 0) è memorizzato in un registro per un uso successivo e restituisce la funzione.

Se è falso, tuttavia, ci spostiamo a

.L5:
  jmp .L5

Questo è un salto incondizionato, per etichettare .L5che è proprio il comando di salto stesso.

In altre parole, il thread viene inserito in un loop occupato infinito.

Allora perché è successo?

Per quanto riguarda l'ottimizzatore, i thread non rientrano nella sua sfera di competenza. Presuppone che altri thread non leggano o scrivano variabili contemporaneamente (perché sarebbe UB data-race). Devi dirlo che non può ottimizzare gli accessi. È qui che arriva la risposta di Scheff. Non mi preoccuperò di ripeterlo.

Poiché all'ottimizzatore non viene detto che la finishedvariabile può potenzialmente cambiare durante l'esecuzione della funzione, vede che finishednon viene modificata dalla funzione stessa e presuppone che sia costante.

Il codice ottimizzato fornisce i due percorsi del codice che risulteranno dall'inserimento della funzione con un valore bool costante; o esegue il ciclo all'infinito o il ciclo non viene mai eseguito.

al -O0compilatore (come previsto) non ottimizza il corpo del loop e il confronto via:

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

pertanto la funzione, quando non ottimizzata funziona, la mancanza di atomicità qui non è in genere un problema, poiché il codice e il tipo di dati sono semplici. Probabilmente il peggio che potremmo incontrare qui è un valore iche è fuori da quello che dovrebbe essere.

Un sistema più complesso con strutture di dati ha molte più probabilità di provocare dati danneggiati o un'esecuzione impropria.

Per completezza nella curva di apprendimento; dovresti evitare di usare variabili globali. Hai fatto un buon lavoro rendendolo statico, quindi sarà locale all'unità di traduzione.

Ecco un esempio:

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

Live su wandbox