La génération d'un thread fournit-elle à elle seule des garanties d'ordre de mémoire?

Je veux faire grosso modo ceci:

Fil initial:

• écrire des valeurs dans les variables globales (elles ne seront plus jamais écrites)
  • Il peut s'agir de données moyennement volumineuses (tableaux, chaînes, etc.). Ne peut pas être simplement fait std::atomic<>.
• engendrer d'autres threads

Autres fils:

• lire l'état global
• faire du travail, etc.

Maintenant, je sais que je peux passer des arguments à std::thread, mais j'essaie de comprendre les garanties de mémoire de C ++ à travers cet exemple.

En outre, je suis assez convaincu que sur toute implémentation du monde réel, la création d'un thread provoquera une barrière de mémoire garantissant que le thread peut "voir" tout ce que le thread parent a écrit jusqu'à ce point.

Mais ma question est: est-ce garanti par la norme?

En plus: Je suppose que je pourrais ajouter un peu de mannequin std::atomic<int>et ainsi, et y écrire avant de démarrer les autres threads, puis sur les autres threads, lire cela une fois au démarrage. Je crois que tout ce qui se passe avant que les machines garantissent alors que l'état global précédemment écrit est correctement visible.

Mais ma question est de savoir si quelque chose comme ça est techniquement requis, ou si la création de threads est suffisante?

La création de threads suffit. Il existe un point de synchronisation entre le constructeur de threads et le début du nouveau thread par [thread.thread.constr] / 7

Synchronisation: la fin de l'invocation du constructeur se synchronise avec le début de l'invocation de la copie de f.

Cela signifie que tout état dans le thread avant que le nouveau thread ne soit généré est visible pour le thread généré.