Ordre de la mémoire atomique en synchronisation.Une fois

En explorant le code source de la synchronisation.Une fois, nous tombons sur le raisonnement derrière l'utilisation d'atomique. StoreUint32 au lieu d'une affectation standard comme o.done = 1.

Ordre de la mémoire dans Go

Un concept fondamental dans la programmation simultanée est l'ordre de la mémoire, qui garantit que la mémoire partagée les accès sont observés de manière cohérente sur tous les processeurs. Cependant, différentes architectures implémentent différemment l'ordre de la mémoire, ce qui pose des défis aux programmeurs.

Go résout ce problème en fournissant un modèle de mémoire uniforme, imposant un ordre de mémoire détendu mais cohérent. Tous les accès à la mémoire sont supposés être asynchrones, sans aucune garantie d'atomicité ou d'ordre.

Opérations atomiques synchronisées.Une fois

Malgré le modèle de mémoire détendu, Go impose le utilisation d'opérations atomiques pour les accès à la mémoire partagée afin de garantir l'exactitude sur toutes les architectures prises en charge. Dans sync.Once, atomic.StoreUint32 est utilisé pour mettre à jour en toute sécurité l'indicateur terminé, garantissant que d'autres goroutines peuvent observer l'effet de f() avant que l'indicateur ne soit défini sur 1.

Optimisation du chemin rapide

atomic.StoreUint32 est utilisé dans le chemin rapide de synchronisation.Once pour optimiser les performances tout en maintenant la sécurité. L'indicateur terminé est d'abord vérifié avec atomic.LoadUint32, puis écrit avec atomic.StoreUint32 car la lecture de l'indicateur en même temps que les écritures est une course aux données.

Protection mutex

Le le mutex utilisé dans doSlow sert à protéger l'indicateur terminé des écritures simultanées. L'indicateur peut toujours être lu sans le mutex car il s'agit d'une opération de lecture, mais les écritures simultanées doivent être synchronisées pour éviter la corruption des données.

En résumé, l'utilisation d'atomic.StoreUint32 en synchronisation.Once est une conséquence de Le modèle de mémoire détendu de Go et la nécessité de garantir la sécurité des threads sur toutes les architectures prises en charge. En employant des opérations atomiques, sync.Once peut coordonner en toute sécurité l'accès simultané à la mémoire partagée tout en optimisant les performances de manière rapide.