variabili di multithreading volatile C++

Question

Sto scrivendo un'app C++.

Ho una variabile di classe a cui sta scrivendo più di un thread.

In C++, tutto ciò che può essere modificato senza che il compilatore "capisca" di essere cambiato deve essere contrassegnato come volatile? Quindi se il mio codice è multi-thread e un thread può scrivere su var mentre un altro lo legge, devo contrassegnare il var volaltile?

[non ho una condizione di competizione dal momento che sto contando sulla scrittura per interi essere atomica]

Grazie!

Answer 1

volatile istruire il compilatore a non ottimizzare "intuizione" di un valore o di un utilizzo variabile poiché potrebbe essere ottimizzato "dall'esterno".

volatile non fornirà comunque alcuna sincronizzazione e la tua ipotesi di scrittura su int atomica è quasi realistica!

Suppongo che avremmo bisogno di vedere un po 'di utilizzo per sapere se volatile è necessario nel tuo caso (o controllare il comportamento del tuo programma) o, soprattutto, se vedi una sorta di sincronizzazione.

Answer 2

Senza il blocco si possono ancora ottenere riordinamenti "impossibili" eseguiti dal compilatore o dal processore. E non c'è alcuna garanzia che le scritture su inti siano atomiche.

Sarebbe meglio usare un bloccaggio adeguato.

Answer 3

C++ non ha ancora nessuna disposizione per il multithreading. In pratica, volatile non fa ciò che intendi (è stato progettato per hardware con memoria indirizzata e mentre i due problemi sono simili sono abbastanza diversi da rendere volatile la cosa giusta - nota che volatile è stato utilizzato in altri linguaggio per usi in contesti mt).

Quindi, se si desidera scrivere un oggetto in un thread e leggerlo in un altro, è necessario utilizzare le funzionalità di sincronizzazione necessarie per l'implementazione quando ne ha bisogno. Per quello che conosco, la volatilità non gioca alcun ruolo in questo.

FYI, il prossimo standard prenderà in considerazione MT e volatile non avrà alcun ruolo in questo. In modo che non cambierà. Avrai solo condizioni standard definite in cui è necessaria la sincronizzazione e un modo standard definito per raggiungerle.

Answer 4

Volatile risolverà il problema, ad es. garantirà la coerenza tra tutte le cache del sistema. Tuttavia sarà inefficienza dal momento che aggiornerà la variabile in memoria per ogni accesso R o W. Si potrebbe prendere in considerazione l'utilizzo di una barriera di memoria, solo quando è necessario, invece. Se si lavora con o gcc/ICC hanno sguardo sulla sincronizzazione built-in: http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html

EDIT (per lo più su commenti PM100): Capisco che le mie convinzioni non sono un punto di riferimento così ho trovato qualcosa di citare :)

La parola chiave volatile è stata concepita per impedire ottimizzazioni del compilatore che potrebbero rendere il codice errato in presenza di determinati eventi asincroni.Ad esempio,se si dichiara una variabile primitiva come volatile, il compilatore non è consentito di memorizzare nella cache in un registro

Da Dr Dobb's

Più interessante:

campi volatili sono linearizzabile. Leggere un campo volatile è come acquistare una serratura; la memoria di lavoro viene invalidata e il valore corrente del campo volatile viene riletto dalla memoria. Scrivere un campo volatile è come liberare un blocco: il campo volatile viene immediatamente riscritto in memoria. (questo è tutto di coerenza, non si tratta di atomicità)

da L'arte della programmazione multiprocessore, Maurice Herlihy & Nir Shavit

blocco contiene codice di sincronizzazione di memoria, se non si blocca, è necessario fare qualcosa e usare parole chiave volatili è probabilmente la cosa più semplice che puoi fare (anche se è stato progettato per dispositivi esterni con memoria legata allo spazio degli indirizzi, non è il punto qui)

Answer 5

Sì, volatile è il minimo assoluto che tu " Ho bisogno. Assicura che il generatore di codice non generi codice che memorizza la variabile in un registro e esegue sempre letture e scritture da/verso la memoria. La maggior parte dei generatori di codice può fornire garanzie di atomicità su variabili che hanno le stesse dimensioni della parola CPU nativa, assicureranno che l'indirizzo di memoria sia allineato in modo tale che la variabile non possa scavalcare un limite di cache-line.

Questo non è tuttavia un contratto molto forte per le moderne CPU multi-core. Volatile fa non promettere che un altro thread che gira su un altro core può vedere gli aggiornamenti alla variabile. Ciò richiede una barriera di memoria, di solito un'istruzione che svuota la cache della CPU. Se non si fornisce una barriera, il filo continuerà a funzionare fino a quando non si verificherà un flusso naturale. Ciò accadrà alla fine, lo scheduler del thread è destinato a fornirne uno. Questo può richiedere millisecondi.

Una volta che ci si è occupati di dettagli come questo, alla fine si sarà reinventato una variabile di condizione (nota anche come evento) che probabilmente non sarà più veloce di quella fornita da una libreria di threading. O altrettanto testato. Non inventare il tuo, il threading è abbastanza difficile da essere corretto, non hai bisogno del FUD di non essere sicuro che i primitivi di base siano solidi.

Answer 6

Penso che lo standard volatile si applichi davvero solo alla lettura, in particolare alla lettura di registri I/O mappati in memoria.

Può essere utilizzato per indicare al compilatore di non dare per scontato che una volta che ha letto da una posizione di memoria che il valore non cambierà:

while (*p) 
{ 
    // ... 
} 

Nel codice di cui sopra, se *p non viene scritto all'interno del ciclo, il compilatore potrebbe decidere di spostare la lettura di fuori del ciclo, più simile a questo:

cached_p=*p 
while (cached_p) 
{ 
    // ... 
} 

Se p è un puntatore ad una porta I/O mappato in memoria, si vorrebbe la prima versione in cui il la porta viene controllata prima che il ciclo venga inserito sempre y tempo

Se p è un puntatore alla memoria in un'app multi-thread, non è ancora garantito che le scritture siano atomiche.