Warum führen verkettete Kanaloperationen im „select'-Fall von Go zu Deadlocks?

Verkettete Kanaloperationen in einem Single-Select-Fall: Dekodierung des Verhaltens

Beim Streben nach dem Entwerfen gleichzeitiger und asynchroner Programme bietet das Select-Konstrukt von Go ein leistungsstarkes Tool zum Multiplexen von Kanälen. Allerdings stößt man häufig auf unerwartete Ergebnisse, wenn man mehrere Vorgänge in einem einzelnen Auswahlfall kombiniert.

Stellen Sie sich das folgende Szenario vor: Zwei Kanäle, A und B, senden Nachrichten in unterschiedlichen Zeitintervallen (10 Millisekunden für A und 1 Sekunde für B). Wir verwenden Select, um beide Kanäle abzuhören und die empfangenen Werte an einen Fan-In-Kanal weiterzuleiten.

func main() {
    ch := fanIn(talk("A", 10), talk("B", 1000))

    for i := 0; i < 10; i++ {
        fmt.Printf("%q\n", <-ch)
    }
    fmt.Printf("Done\n")
}

Das erwartete Ergebnis ist:

"A 0"
"B 0"
"A 1"
"A 2"
"A 3"
"A 4"
"B 1"
"B 2"
"B 3"
"B 4"
Done

Wenn wir jedoch das Select ändern Fall, um verkettete Kanaloperationen zu verwenden:

select {
    case ch <- <-input1:
    case ch <- <-input2:
}

Wir beobachten eine Besonderheit Verhalten:

"B 0"
"A 1"
"B 2"
"A 3"
"A 4"
fatal error: all goroutines are asleep - deadlock!

Hinter den Kulissen

Der Schlüssel zum Verständnis dieses Verhaltens liegt in der nicht blockierenden Natur der Kanaloperationen in einem ausgewählten Fall. In einem typischen Auswahlfall kann nur eine Kanaloperation (entweder Lesen oder Schreiben) nicht blockierend sein.

Wenn wir verkettete Kanaloperationen verwenden, versuchen wir effektiv mehrere Kanaloperationen in einem einzigen Fall. Die erste Operation ist immer blockierend, während die nachfolgenden Operationen nicht blockierend sind.

In unserem modifizierten Code blockiert die erste Operation, um einen Wert von Eingang1 zu empfangen. Nach dem Empfang des Werts wird versucht, ihn blockierungsfrei in den Kanal ch zu schreiben. Wenn der Empfänger des Kanals ch jedoch nicht bereit ist, den Wert zu akzeptieren, schlägt der Schreibvorgang fehl.

Die Kettenreaktion

Der fehlgeschlagene Schreibvorgang schlägt fehl Stoppen Sie den Auswahlfall. Stattdessen geht es zum zweiten Fall über, der nun der einzig realisierbare Fall ist. Dies führt zu einem potenziellen Deadlock-Szenario.

Im Laufe der Zeit werden mehrere Werte von beiden Kanälen empfangen, aber aufgrund der fehlgeschlagenen Schreibvorgänge nicht an den Fan-In-Kanal weitergeleitet. Infolgedessen wird der Fan-In-Kanal irgendwann leer, was zu einem Deadlock führt, da keine Werte mehr empfangen werden können.

Problem lösen

Um dieses Problem zu vermeiden, verwenden Sie es ist von entscheidender Bedeutung, um sicherzustellen, dass die Kanaloperationen innerhalb eines ausgewählten Falls seriell ausgeführt werden. Dies kann erreicht werden, indem eine temporäre Variable verwendet wird, um den empfangenen Wert zu speichern, und dann der Schreibvorgang als separate Anweisung außerhalb des Select-Falls ausgeführt wird.

var msg string
select {
    case msg = <-input1:
    case msg = <-input2:
}

ch <- msg

Das obige ist der detaillierte Inhalt vonWarum führen verkettete Kanaloperationen im „select'-Fall von Go zu Deadlocks?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!