WaitGroup.Wait() agit-il comme une barrière de mémoire dans Go ?

WaitGroup.Wait() garantit-il une barrière mémoire ?

Considérez l'extrait de code suivant :

var condition bool
var wg sync.WaitGroup
for _, item := range items {
    wg.Add(1)
    go func(item) {
        if meetsCondition(item) {
            condition = true
        }
        wg.Done()
    }(item)
}
wg.Wait()
// is it safe to check condition here?

Le la question se pose de savoir s'il est sûr de vérifier la variable de condition après le retour de wg.Wait(). La documentation officielle de Go ne mentionne explicitement aucune implication de barrière de mémoire, mais la documentation WaitGroup indique que Wait se bloque jusqu'à ce que le compteur du groupe d'attente atteigne zéro.

Solution

Oui, il est prudent de vérifier la variable de condition après le retour de wg.Wait(). Il existe une relation implicite qui se produit avant entre wg.Wait() et wg.Done(). Lorsqu'une goroutine appelle wg.Done(), elle garantit que toutes ses opérations terminées deviennent visibles pour les autres goroutines qui ont déjà appelé wg.Wait(). Par conséquent, wg.Wait() agit efficacement comme une barrière de mémoire, garantissant que la variable de condition est mise à jour avant la vérification après le retour de wg.Wait().

Cette relation qui se produit avant n'est pas explicitement documentée mais a été confirmé par les développeurs de Go. Reportez-vous au fil de discussion du forum Go ici pour plus de détails.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!