La generazione di un thread fornisce garanzie di ordine di memoria per conto proprio?

Voglio fare più o meno questo:

Discussione iniziale:

• scrivere alcuni valori su var globali (non verranno mai più scritti)
  • Potrebbe trattarsi di dati moderatamente grandi (array, stringhe, ecc.). Non può essere semplicemente creato std::atomic<>.
• spawn altri thread

Altre discussioni:

• leggi lo stato globale
• lavorare, ecc.

Ora so di poter passare argomenti a std::thread, ma sto cercando di capire le garanzie di memoria del C ++ attraverso questo esempio.

Inoltre, sono abbastanza fiducioso che su qualsiasi implementazione nel mondo reale, la creazione di un thread causerà una barriera di memoria garantendo che il thread possa "vedere" tutto ciò che il thread padre ha scritto fino a quel momento.

Ma la mia domanda è: questo è garantito dallo standard?

A parte: suppongo che potrei aggiungere un po 'di manichino std::atomic<int>e scrivere a quello prima di iniziare gli altri thread, quindi sugli altri thread, leggilo una volta all'avvio. Credo che tutte le macchine che accadono prima garantirebbero quindi che lo stato globale precedentemente scritto sia ben visibile.

Ma la mia domanda è se qualcosa di simile è tecnicamente necessario o è sufficiente la creazione di thread?

La creazione del thread è sufficiente. Esiste un punto di sincronizzazione tra il costruttore del thread e l'inizio del nuovo thread per [thread.thread.constr] / 7

Sincronizzazione: il completamento dell'invocazione del costruttore si sincronizza con l'inizio dell'invocazione della copia di f.

Ciò significa che tutto lo stato nel thread prima della generazione del nuovo thread è visibile al thread generato.