Erste Problemübersicht:
Ein Versuch, sync.Cond zu verwenden, führt zu einem Es kommt zu einer Race-Bedingung, die aufgrund eines Deadlocks sofort Panik auslöst. Der Entwickler vermutet ein Problem zwischen dem Sperren des Mutex und dem Aufrufen der Wait-Methode der Bedingung.
Klärung des beabsichtigten Anwendungsfalls:
Abgesehen von der Race-Bedingung das primäre Ziel besteht darin, einen Synchronisierungsmechanismus zu erstellen, bei dem mehrere Goroutinen darauf warten, dass HTTP-Header von einer Goroutine mit langer Laufzeit verfügbar werden.
Lösung:
Beispiel mit mehreren Lesern und einem Autor:
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() }
Alternative Lösung:
Wenn die Verwendung von Kanälen möglich ist In dieser Situation ist es immer noch die bevorzugte Methode zur Weitergabe von Daten.
Das obige ist der detaillierte Inhalt vonWann sollte sync.Cond vs. Simple Locking verwendet werden: Ein Problem mit sync.Cond und eine alternative Lösung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!