Maison > Article > développement back-end > Quand utiliser sync.Cond par rapport au verrouillage simple : un problème avec sync.Cond et une solution alternative
Aperçu initial du problème :
Une tentative d'utilisation de sync.Cond entraîne un condition de concurrence, provoquant une panique immédiate en raison d'une impasse. Le développeur soupçonne un problème entre le verrouillage du Mutex et l'appel de la méthode Wait de la condition.
Clarification du cas d'utilisation prévu :
Outre la condition de concurrence critique, l'objectif principal consiste à créer un mécanisme de synchronisation dans lequel plusieurs goroutines attendent que les en-têtes HTTP deviennent disponibles à partir d'une goroutine de téléchargement de longue durée.
Résolution :
Exemple avec plusieurs lecteurs et un seul écrivain :
var sharedRsc = make(map[string]interface{}) func main() { var wg sync.WaitGroup wg.Add(2) m := sync.Mutex{} c := sync.NewCond(&m) go func() { c.L.Lock() for len(sharedRsc) == 0 { c.Wait() } fmt.Println(sharedRsc["rsc1"]) c.L.Unlock() wg.Done() }() go func() { c.L.Lock() for len(sharedRsc) == 0 { c.Wait() } fmt.Println(sharedRsc["rsc2"]) c.L.Unlock() wg.Done() }() c.L.Lock() sharedRsc["rsc1"] = "foo" sharedRsc["rsc2"] = "bar" c.Broadcast() c.L.Unlock() wg.Wait() }
Solution alternative :
Si l'utilisation de canaux est réalisable dans cette situation, c'est toujours la méthode privilégiée pour transmettre des données.
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!