Filo-sicurezza di scrittura di un array std :: vector vs plain

Question

Ho letto on Stackoverflow che nessuno dei contenitori STL è thread-safe per scrivere. Ma cosa significa in pratica? Significa che dovrei archiviare dati scrivibili in semplici array?

Mi aspetto che le chiamate simultanee a std::vector::push_back(element) possano portare a strutture di dati incoerenti perché potrebbero comportare il ridimensionamento del vettore. Ma che dire di un caso come questo, in cui non è coinvolto il ridimensionamento:

1) utilizzando una matrice:

int data[n]; 
// initialize values here... 

#pragma omp parallel for 
for (int i = 0; i < n; ++i) { 
    data[i] += func(i); 
} 

2) utilizzando un `std :: vector``:

std::vector<int> data; 
data.resize(n); 
// initialize values here... 

#pragma omp parallel for 
for (int i = 0; i < n; ++i) { 
    data[i] += func(i); 
} 

La prima implementazione è davvero migliore della seconda a) in termini di sicurezza dei thread eb) in termini di prestazioni? Preferirei usare un vettore std ::, dal momento che mi sento meno a mio agio con gli array in stile C.

MODIFICA: Ho rimosso un #pragma omp atomic update proteggendo la scrittura.

Answer 1

I due sono ugualmente sicuri. A condizione che nessun elemento sia accessibile da più thread sei OK. Il tuo ciclo parallelo accederà a ciascun elemento solo una volta e quindi solo da un thread.

C'è spazio nello standard per le funzioni membro dei contenitori non a prova di thread. In questo caso si utilizza vector<int>::operator[], quindi si desidera una garanzia esplicita di sicurezza del thread per quel membro, il che sembra ragionevole poiché chiamarlo anche su un vettore non const non modifica il vettore stesso. Quindi dubito che ci sia un problema in questo caso, ma non ho cercato la garanzia [modifica: rici l'ha trovato]. Anche se potenzialmente non sicuro, è possibile eseguire int *dataptr = &data.front() prima del ciclo e quindi indicizzare dataptr anziché data.

Per inciso, questo codice è non garantita sicuro per vector<bool>, poiché è uno speciale caso per cui più elementi coesistono dentro un oggetto. Sarebbe sicuro per un array di bool, poiché i diversi elementi di questo sono "posizioni di memoria" differenti (1.7 in C++ 11).

Answer 2

L'elemento principale è che se si dispone di più thread che accedono al vettore, non è possibile dipendere da C++ per evitare di danneggiare la struttura dei dati con più scritture simultanee. Quindi devi usare una specie di guardia. D'altra parte, se il tuo programma non usa più thread, come non sembrano i tuoi esempi, stai perfettamente bene.

Answer 3

In questo caso, è sufficiente costruire il vettore con il numero necessario di valori? e tutto andrà bene.

resize() funziona bene. La performance sarà uguale. Il motivo per cui l'accesso multithread non corromperà il vettore è: i tuoi dati si trovano nella sua posizione e non si sposteranno da lì. I thread OMP non accedono allo stesso elemento alla volta.

Answer 4

Per C++ 11, che specifica le regole per le corse dati, viene descritta la sicurezza del thread dei contenitori. Una sezione dedicata del standard è § 23.2.2, paragrafo 2:

Nonostante (17.6.5.9), le implementazioni sono tenuti ad evitare corse di dati quando il contenuto dell'oggetto contenuto in elementi diversi nella stessa sequenza, eccetto vettore <bool>, vengono modificate contemporaneamente.

[Nota: per un vettore <int> x con una dimensione maggiore di uno, x [1] = 5 e * x.begin() = 10 possono essere eseguiti contemporaneamente senza una corsa di dati, ma x [0] = 5 e * x.begin() = 10 eseguiti simultaneamente possono causare una corsa di dati. Come eccezione alla regola generale, per un vettore <bool> y, y [0] = true può correre con y [1] = vero. Nota -end]

Il citato § 17.6.5.9 vieta in sostanza qualsiasi modifica simultanea da qualsiasi interfaccia libreria standard se non specificatamente consentito, quindi la sezione cito ti dice esattamente ciò che è permesso (e che comprende l'uso).

Poiché la questione è stata sollevata da Steve Jessop, paragrafo 1 del § 23.2.2 consente esplicitamente l'uso concomitante di [] in container sequenziali:

A scopo di evitare corse di dati (17.6.5.9), implementazioni considera le seguenti funzioni come const: begin, end, rbegin, rend, front, back, data, find, lower_bound, upper_bound, equal_range, at e, tranne che in contenitori associativi o non ordinati, operator [].