Va bene leggere un flag booleano condiviso senza bloccarlo quando un altro thread può impostarlo (al massimo una volta)?

Question

Vorrei che il mio thread si spenga più agevolmente, quindi sto cercando di implementare un semplice meccanismo di segnalazione. Non credo che voglio un filo completamente event-driven quindi ho un lavoratore con un metodo per graceully fermarla con una sezione critica Monitor (equivalente a un C# lock credo):

DrawingThread.h

class DrawingThread { 
    bool stopRequested; 
    Runtime::Monitor CSMonitor; 
    CPInfo *pPInfo; 
    //More.. 
} 

DrawingThread.cpp

void DrawingThread::Run() { 
    if (!stopRequested) 
     //Time consuming call#1 
    if (!stopRequested) { 
     CSMonitor.Enter(); 
     pPInfo = new CPInfo(/**/); 
     //Not time consuming but pPInfo must either be null or constructed. 
     CSMonitor.Exit(); 
    } 
    if (!stopRequested) { 
     pPInfo->foobar(/**/);//Time consuming and can be signalled 
    } 
    if (!stopRequested) { 
     //One more optional but time consuming call. 
    } 
} 


void DrawingThread::RequestStop() { 
    CSMonitor.Enter(); 
    stopRequested = true; 
    if (pPInfo) pPInfo->RequestStop(); 
    CSMonitor.Exit(); 
} 

ho capito (almeno in Windows) Monitor/lock s sono i meno costosi sincronizzazione dei thread primitivo ma sono desiderosi di evitare un uso eccessivo. Dovrei essere avvolgente ogni lettura di questa bandiera booleana? Viene inizializzato su false e viene impostato una sola volta su true quando viene richiesto stop (se richiesto prima che l'attività venga completata).

I miei tutor consigliavano di proteggere anche bool perché la lettura/scrittura potrebbe non essere atomica. Penso che questa bandiera unica sia l'eccezione che conferma la regola?

Answer 1

Non è mai corretto leggere qualcosa eventualmente modificato in una thread diversa senza sincronizzazione. Quale livello di sincronizzazione è necessario dipende da ciò che stai effettivamente leggendo. Per i tipi primitivi, dovresti dare un'occhiata alle letture atomiche, ad es. nella forma di std::atomic<bool>.

Il motivo per cui la sincronizzazione è sempre necessaria è che i processori dispongano dei dati eventualmente condivisi in una riga della cache. Non ha motivo di aggiornare questo valore a un valore eventualmente modificato in un thread diverso se non esiste alcuna sincronizzazione. Peggio ancora, tuttavia, se non c'è sincronizzazione, potrebbe scrivere il valore sbagliato se qualcosa memorizzato vicino al valore è cambiato e sincronizzato.

Answer 2

L'assegnazione booleana è atomica. Non è questo il problema

Il problema è che un thread potrebbe non vedere le modifiche apportate a una variabile da un thread diverso a causa del riordino o del caching delle istruzioni del compilatore o della CPU (ovvero il thread che legge il flag booleano può leggere un valore memorizzato nella cache, del valore attuale aggiornato).

La soluzione è una fence di memoria, che in realtà viene implicitamente aggiunta dalle istruzioni di blocco, ma per una singola variabile è eccessivo. Basta dichiararlo volatile.

Answer 3

No, devi proteggere ogni accesso, poiché i compilatori e le cpus moderni riordinano il codice senza le tue attività di multithreading in mente. L'accesso in lettura da diversi thread potrebbe funzionare, ma non deve funzionare.

Answer 4

La risposta, credo, è "dipende". Se stai usando C++ 03, il threading non è definito nello standard, e dovrai leggere cosa dicono il tuo compilatore e la tua libreria di thread, anche se questo genere di cose viene solitamente chiamato "razza benigna" and is usually OK.

Se si utilizza C++ 11, le razze benigne sono comportamenti indefiniti. Anche quando un comportamento non definito non ha senso per il tipo di dati sottostante. Il problema è che i compilatori possono supporre che i programmi non abbiano un comportamento indefinito, and make optimizations based on that (vedere anche la Parte 1 e la Parte 2 collegati da lì). Ad esempio, il compilatore potrebbe decidere di leggere il flag una volta e memorizzare il valore nella cache perché è un comportamento indefinito scrivere sulla variabile in un altro thread senza alcun tipo di mutex o barriera di memoria.

Ovviamente, è possibile che il tuo compilatore prometta di non eseguire tale ottimizzazione. Avrai bisogno di guardare.

La soluzione più semplice è utilizzare std::atomic<bool> in C++ 11 o qualcosa di simile a Hans Boehm's atomic_ops altrove.