Come i compilatori C++ supportano C++ 11 atomico, ma non supportano il modello di memoria C++ 11

Question

Mentre guardavo lo stato di implementazione di Clang e g ++ C++ 11 ho notato qualcosa di strano:
supportano gli atomici C++ 11, ma non supportano il modello di memoria C++ 11.
Ho avuto l'impressione che sia necessario il modello di memoria C++ 11 per utilizzare l'atomica. Quindi, qual è esattamente la differenza tra il supporto per l'atomica e il modello di memoria?
La mancanza di supporto del modello di memoria significa che i programmi legali C++ 11 che utilizzano std::atomic<T> non sono coerenti?

riferimenti:
http://clang.llvm.org/cxx_status.html
http://gcc.gnu.org/gcc-4.7/cxx0x_status.html

Answer 1

Uno dei problemi è la definizione di "posizione di memoria", che consente (e obbliga il compilatore di supportare) il blocco di diversi membri della struttura da blocchi diversi. C'è un discussion about a RL problem caused by this.

In sostanza il problema è che avendo un struct definita in questo modo:

struct x { 
    long a; 
    unsigned int b1; 
    unsigned int b2:1; 
}; 

il compilatore è libero di implementare la scrittura b2 sovrascrivendo b1 troppo (ea quanto pare, a giudicare dal rapporto, lo fa). Pertanto, i due campi devono essere bloccati come uno. Tuttavia, come conseguenza del modello di memoria C++ 11, questo è vietato (beh, non proprio proibito, ma il compilatore deve garantire aggiornamenti simultanei a b1 e b2 non interferire, potrebbe farlo bloccando o CAS-in ogni tale aggiornamento, beh, la vita è difficile su alcune architetture). Citando dal rapporto:

ho sollevato la questione con i nostri ragazzi del CCG e hanno detto a me che: "C non non fornisce tale garanzia, né è possibile bloccare in modo affidabile diversi campi della struttura con diverse serrature, se condividono regioni di memoria word-size allineate in modo naturale.Il modello di memoria C++ 11 garantisce questo, ma non è implementato né si costruisce il kernel con un compilatore C++ 11 ".

Belle informazioni possono anche essere trovate nel wiki.

Answer 2

non è così tanto che non supportano il modello di memoria, ma che non lo fanno (ancora) supportano l'API in standard per l'interazione con la memoria modello. Quell'API include un numero di mutex.

Tuttavia, sia Clang che GCC sono stati il ​​più consapevoli dei thread possibili senza uno standard formale per qualche tempo. Non devi preoccuparti delle ottimizzazioni che spostano le cose dal lato sbagliato delle operazioni atomiche.

Answer 3

Suppongo che in questi casi la "Mancanza del modello di memoria" significhi solo che gli ottimizzatori sono stati scritti prima che il modello di memoria C++ 11 sia stato pubblicato e potrebbero ora eseguire ottimizzazioni non valide. È molto difficile e richiede molto tempo per convalidare le ottimizzazioni rispetto al modello di memoria, quindi non è una sorpresa che i team clang/gcc non abbiano ancora finito.

Una mancanza di supporto del modello di memoria significa che i programmi legali C++ 11 che utilizzano std :: atomic arent seq sono coerenti?

Sì, questa è una possibilità. È anche peggio: il compilatore potrebbe introdurre le corse di dati in (secondo lo standard C++ 11) senza gara, ad es. introducendo scritture speculative.

Ad esempio, diversi compilatori C++ utilizzati per eseguire questa ottimizzazione:

for (p = q; p = p -> next; ++p) { 
    if (p -> data > 0) ++count; 
} 

Potrebbe ottenere ottimizzato in:

register int r1 = count; 
for (p = q; p = p -> next; ++p) { 
    if (p -> data > 0) ++r1; 
} 
count = r1; 

Se tutto p->data sono non-negativo, il codice sorgente originale non ha scritto a count, ma il codice ottimizzato lo fa. Questo può introdurre una corsa di dati in un programma altrimenti senza gara, quindi la specifica C++ 11 non consente tali ottimizzazioni. I compilatori esistenti ora devono verificare (e correggere se necessario) tutte le ottimizzazioni.

Vedere Concurrency memory model compiler consequences per dettagli.