Les Goroutines fonctionnant en continu peuvent-elles affamer les autres Goroutines dans Go ?

Planification coopérative des Goroutines et famine potentielle d'exécution

Les Goroutines sont planifiées de manière coopérative, ce qui signifie qu'elles cèdent volontairement l'exécution à d'autres goroutines. Bien que cette approche garantisse généralement l'équité, elle soulève la question de savoir si les goroutines qui s'abstiennent de céder peuvent potentiellement affamer d'autres goroutines.

Selon le billet de blog référencé (http://blog.nindalf.com/how-goroutines -work/), les goroutines qui bouclent continuellement sans céder peuvent en effet affamer d'autres goroutines sur le même thread. Les goroutines sur un thread spécifique sont multiplexées, ce qui signifie qu'elles ne bloquent pas le thread même lorsqu'elles rencontrent des opérations de blocage telles que des opérations d'entrée réseau, de mise en veille ou de canal.

À titre d'exemple, la fonction "somme" dans le code donné à plusieurs reprises boucle un nombre aléatoire de fois, ajoutant des nombres à une somme et imprimant le résultat final. Si plusieurs de ces goroutines sont générées à l'aide du mot-clé "go" (comme indiqué dans l'exemple), leur exécution une par une dépend des facteurs suivants :

• Nombre de threads disponibles (GOMAXPROCS ): Si GOMAXPROCS est défini sur 1, toutes les goroutines s'exécuteront séquentiellement sur un seul thread, ce qui entraînera famine.
• Points de cession : Dans la fonction somme, il n'y a pas d'appels de fonction ni de primitives de synchronisation qui permettraient aux goroutines de céder. Par conséquent, la goroutine conservera le fil de discussion jusqu'à ce qu'il soit terminé.
• Modifications récentes du runtime : Le billet de blog cité est légèrement obsolète. Les versions plus récentes du runtime Go peuvent planifier le changement de goroutine même pour les fonctions sans seuil d'élasticité explicite, telles que "fmt.Println". Ceci est fait pour éviter une famine potentielle.

Par conséquent, en l'absence de rendement explicite ou d'appels de fonction qui déclenchent la planification, les goroutines qui exécutent des boucles infinies peuvent potentiellement affamer d'autres goroutines sur le même thread. Cependant, il est important de noter que le runtime Go tente activement d'équilibrer l'exécution des goroutines et d'éviter la famine.

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!