Le variabili thread_local di C ++ 11 sono automaticamente statiche?

C'è una differenza tra questi due segmenti di codice:

void f() {
    thread_local vector<int> V;
    V.clear();
    ... // use V as a temporary variable
}

e

void f() {
    static thread_local vector<int> V;
    V.clear();
    ... // use V as a temporary variable
}

Backstory: originariamente avevo un vettore STATICO V (per contenere alcuni valori intermedi, viene cancellato ogni volta che entro nella funzione) e un programma a thread singolo. Voglio trasformare il programma in uno multithreading, quindi in qualche modo devo sbarazzarmi di questo modificatore statico. La mia idea è trasformare ogni statica in thread_local e non preoccuparti di nient'altro? Può questo approccio ritorcersi contro?

Secondo lo standard C ++

Quando thread_local viene applicato a una variabile di ambito di blocco, lo specificatore di classe di archiviazione statico è implicito se non appare esplicitamente

Quindi significa che questa definizione

void f() {
    thread_local vector<int> V;
    V.clear();
    ... // use V as a temporary variable
}

è equivalente a

void f() {
    static thread_local vector<int> V;
    V.clear();
    ... // use V as a temporary variable
}

Tuttavia, una variabile statica non è la stessa di una variabile thread_local.

1 Tutte le variabili dichiarate con la parola chiave thread_local hanno una durata di archiviazione del thread. L'archiviazione per queste entità durerà per la durata del thread in cui vengono create. Esiste un oggetto o un riferimento distinto per thread e l'uso del nome dichiarato si riferisce all'entità associata al thread corrente

Per distinguere queste variabili, lo standard introduce un nuovo termine durata della memorizzazione dei thread insieme alla durata della memorizzazione statica.

Sì, "archiviazione locale del thread" è molto simile a "globale" (o "archiviazione statica"), solo che invece di "durata dell'intero programma" hai "durata dell'intero thread". Quindi una variabile locale del thread locale del blocco viene inizializzata la prima volta che il controllo passa attraverso la sua dichiarazione, ma separatamente all'interno di ogni thread, e viene distrutta quando il thread termina.

Quando viene utilizzato con thread_local, staticè implicito nell'ambito del blocco (vedere la risposta di @ Vlad), richiesto per un membro della classe; Immagino che significhi collegamento per l'ambito dello spazio dei nomi.

Per 9.2 / 6:

All'interno di una definizione di classe, un membro non deve essere dichiarato con thread_local storage-class-specifier a meno che non sia dichiarato anche static

Per rispondere alla domanda originale:

Le variabili thread_local di C ++ 11 sono automaticamente statiche?

Non c'è scelta, ad eccezione delle variabili di ambito dello spazio dei nomi.

C'è una differenza tra questi due segmenti di codice:

No.

L'archiviazione locale del thread è statica ma si comporta in modo abbastanza diverso dalla semplice archiviazione statica.

Quando dichiari una variabile statica, c'è esattamente un'istanza della variabile. Il sistema compilatore / runtime garantisce che verrà inizializzato per te qualche tempo prima di usarlo effettivamente, senza specificare esattamente quando (alcuni dettagli sono omessi qui).

C ++ 11 garantisce che questa inizializzazione sarà thread-safe, tuttavia prima di C ++ 11 questa thread safety non era garantita. Per esempio

static X * pointer = new X;

potrebbe perdere istanze di X se più di un thread ha colpito il codice di inizializzazione statica allo stesso tempo.

Quando si dichiara una variabile thread locale, ci sono potenzialmente molte istanze della variabile. Potresti pensare a loro come se fossero in una mappa indicizzata da thread-id. Ciò significa che ogni thread vede la propria copia della variabile.

Ancora una volta, se la variabile viene inizializzata, il sistema compilatore / runtime garantisce che questa inizializzazione avverrà prima che i dati vengano utilizzati e che avvenga l'inizializzazione per ogni thread che utilizza la variabile. Il compilatore garantisce inoltre che l'avvio sarà thread-safe.

Le garanzie di thread safety significano che ci può essere un bel po 'di codice dietro le quinte per far sì che la variabile si comporti come ti aspetti, specialmente considerando che il compilatore non ha modo di sapere in anticipo esattamente quanti thread saranno esistono nel tuo programma e quanti di questi toccheranno la variabile locale del thread.