Pourquoi les opérations de canal chaînées dans le cas « select » de Go provoquent-elles des blocages ?

Opérations de canal chaînées dans un cas de sélection unique : décodage du comportement

Dans la poursuite de la conception de programmes simultanés et asynchrones, la construction de sélection de Go fournit un outil puissant pour multiplexer les canaux. Cependant, on rencontre souvent des résultats inattendus lorsqu'on combine plusieurs opérations dans un seul cas de sélection.

Considérons le scénario suivant : deux canaux, A et B, envoient des messages à des intervalles de temps différents (10 millisecondes pour A et 1 seconde pour B). Nous utilisons select pour écouter les deux chaînes et transmettre les valeurs reçues à une chaîne fan-in.

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")
}

Le résultat attendu est :

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

Cependant, lorsque nous modifions la sélection cas d'utilisation d'opérations de canal chaînées :

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

on observe un phénomène particulier behavior :

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

Dans les coulisses

La clé pour comprendre ce comportement réside dans la nature non bloquante des opérations de canal dans un cas sélectionné. Dans un cas de sélection typique, une seule opération de canal (lecture ou écriture) peut être non bloquante.

Lorsque nous utilisons des opérations de canal chaînées, nous tentons en fait plusieurs opérations de canal dans un seul cas. La première opération est toujours bloquante, tandis que les opérations suivantes sont non bloquantes.

Dans notre code modifié, la première opération bloque pour recevoir une valeur de input1. Après avoir reçu la valeur, il tente de l'écrire sur le canal ch de manière non bloquante. Cependant, si le récepteur du canal ch n'est pas prêt à accepter la valeur, l'opération d'écriture échouera.

La réaction en chaîne

L'opération d'écriture échouée ne arrêter le cas de sélection. Au lieu de cela, il passe au deuxième cas, qui est désormais le seul cas viable. Cela entraîne un scénario de blocage potentiel.

Au fil du temps, plusieurs valeurs des deux canaux sont reçues mais ne sont pas transmises au canal fan-in en raison de l'échec des écritures. Par conséquent, le canal de fan-in finit par se vider, entraînant un blocage car plus aucune valeur ne peut être reçue.

Résoudre le problème

Pour éviter ce problème, il est crucial pour garantir que les opérations de canal dans un cas sélectionné sont exécutées en série. Ceci peut être réalisé en utilisant une variable temporaire pour stocker la valeur reçue, puis en exécutant l'opération d'écriture en tant qu'instruction distincte en dehors du cas de sélection.

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

ch <- msg

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!