L'asynchrone

Cinquante équipements à interroger

Un outil de supervision relève l'état de cinquante équipements d'un réseau industriel : commutateurs, automates, passerelles. Chaque interrogation demande d'envoyer une requête et d'attendre la réponse, soit deux cents millisecondes, dont le programme ne passe à peu près rien à calculer. Il attend.

En séquentiel, cinquante fois deux cents millisecondes font dix secondes, pour un travail effectif de quelques millisecondes. Le réflexe est alors de lancer cinquante fils d'exécution. Il fonctionne, et il coûte.

Les chiffres sont des ordres de grandeur, et la réservation d'un fil n'est pas de la mémoire réellement consommée. Le rapport, lui, est le bon : environ deux mille sept cents. À cela s'ajoute le coût des changements de contexte, que le système opère cinquante fois pour des traitements qui, pour l'essentiel, ne font rien.

Le constat qui commande tout le chapitre : ces cinquante traitements ne se disputent pas le processeur, ils attendent le réseau. Un seul fil suffirait, à condition qu'il sache passer d'une attente à l'autre.

Rendre la main plutôt que se la faire prendre

Voici le programme du stock, tel que les chapitres précédents l'ont traité. Deux relevés à comptabiliser, trois instructions chacun, et le système qui interrompt où bon lui semble.

Vingt entrelacements, dix-huit laissent le compteur à 1 au lieu de 2. C'est le modèle préemptif : l'interruption est décidée par le système, à tout moment, sans que le programme en sache rien.

Le modèle coopératif inverse la décision. Un seul fil existe, et il exécute les tâches l'une après l'autre ; une tâche garde le processeur jusqu'à ce qu'elle rende la main d'elle-même, ce qu'elle fait aux endroits marqués, et nulle part ailleurs. Dans la figure ci-dessous, le verrou nommé main représente cette possession : il n'est écrit dans aucun programme réel, il est tenu par la tâche qui s'exécute, et libérer main est le point où la tâche rend la main.

Deux entrelacements, un seul résultat, et aucun verrou écrit par le programmeur : le seul qui apparaisse est la main elle-même, que la tâche ne rend qu'à la fin de son traitement. La coupure entre la lecture et l'écriture est devenue impossible à provoquer, non pas improbable.

async et await

Python marque les deux choses d'un mot chacune. Une fonction déclarée par async def est une coroutine : un traitement qui a le droit de rendre la main. L'opérateur await marque l'endroit où il la rend, et il indique ce qu'il attend.

Le programme ci-dessous s'exécute dans cette page. Une boucle d'événements y tourne déjà, donc await s'écrit directement au premier niveau, sans l'envelopper dans une fonction. Hors du navigateur, dans un fichier lancé par python releve.py, c'est asyncio.run(principal()) qui démarre la boucle.

Trois points de lecture. asyncio.sleep tient ici la place d'une requête réseau, et c'est la seule ligne où la tâche rend la main. asyncio.gather lance les cinquante coroutines et attend qu'elles soient toutes terminées. await, au premier niveau, confie le tout à la boucle déjà en place : c'est le seul endroit du programme où quoi que ce soit se met en attente.

La durée mesurée le dit mieux qu'un raisonnement : la durée totale n'est pas cinquante fois deux cents millisecondes, mais deux cents millisecondes, le temps de la plus longue attente. Pendant que la première tâche attend sa réponse, les quarante-neuf autres envoient la leur.

Le libérer main du milieu est le await : la tâche a envoyé sa requête et rend la main pendant l'attente. Quatre-vingt-dix entrelacements sont possibles, ce qui veut dire que l'ordre des réponses est tout aussi imprévisible qu'avec des fils, et le compteur finit pourtant à 3 dans les quatre-vingt-dix cas. L'incrément du compteur, lui, n'a jamais été coupé.

Ce que le modèle ne supprime pas

La garantie porte sur les fragments sans await. Un await placé au milieu d'un traitement rouvre exactement la porte que le modèle avait fermée, et la course revient à l'identique. C'est le cas d'une tâche qui lit un compteur, interroge le réseau pour obtenir la valeur à ajouter, puis écrit.

Six entrelacements, dont quatre laissent le compteur à 1. Le programme n'a qu'un seul fil d'exécution, et il perd quand même une mise à jour.

Le même défaut s'écrit en Python, et se lance ici. Cinquante tâches incrémentent le même compteur, avec un point d'attente entre la lecture et l'écriture.

Un seul fil, cinquante mises à jour, et un compteur qui finit à 1. Déplacer l'attente hors de la mise à jour, ou entourer celle-ci d'un verrou, rétablit les cinquante relevés.

Les deux erreurs qui reviennent toujours

La première est l'oubli du await. Une coroutine appelée sans await ne s'exécute pas : l'appel construit un objet et le rend, ce que le programme ci-dessous montre sans avoir besoin d'une boucle d'événements.

Le résultat n'est pas un couple, c'est une coroutine qui n'a jamais tourné. Aucune erreur n'est levée sur le moment : l'erreur se manifeste plus loin, quand le programme essaie de lire le premier élément de ce qu'il croit être un couple, ou pire, quand il n'essaie rien du tout et qu'un relevé manque sans que personne ne s'en aperçoive. C'est l'erreur la plus fréquente du modèle, et elle se reconnaît à un message caractéristique, coroutine ... was never awaited.

La seconde erreur est l'appel bloquant. Une tâche qui exécute un traitement long sans jamais rendre la main fige la boucle entière, et donc toutes les autres tâches.

Les deux équipements attendent la fin des trois étapes du tri, alors que leurs réponses, elles, sont déjà arrivées. Un calcul long, une lecture de fichier avec la fonction ordinaire open, un appel à une bibliothèque qui n'a pas été écrite pour l'asynchrone : tous ont le même effet, et aucun ne provoque d'erreur. Le symptôme est un outil de supervision qui devient subitement lent, sans raison visible.

Le remède tient en une phrase : un traitement qui calcule longtemps ou qui appelle une bibliothèque bloquante se confie à un fil séparé, par asyncio.to_thread, et la boucle reste libre pour ce qu'elle sait faire.

import asyncio

async def principal():
    # Le tri s'exécute dans un fil séparé : la boucle continue de servir les réponses.
    lignes = await asyncio.to_thread(trier_le_journal, "journal.txt")
    print(len(lignes), "lignes triées")

asyncio.run(principal())

Ce programme-ci ne s'exécute pas dans cette page, mais pour une autre raison : asyncio.to_thread demande un fil d'exécution séparé, et l'interpréteur du navigateur ne sait pas en démarrer un. La fonction de tri, elle, resterait à écrire.

Exercices type

resultats = await asyncio.gather(
    *(asyncio.wait_for(relever(a), timeout=2) for a in adresses),
    return_exceptions=True,
)

Vérification

La méthode

1. Reconnaître le type de charge avant de choisir un modèle : un traitement qui attend le réseau, le disque ou un équipement relève de l'asynchrone ; un traitement qui calcule vraiment relève des fils ou des processus.
2. Marquer les attentes, et elles seules, par await : chaque await est un endroit où le programme accepte d'être interrompu, et cela se lit.
3. Lancer les tâches ensemble par asyncio.gather plutôt que de les attendre une par une, sans quoi la durée totale redevient la somme des attentes.
4. Chercher un await dans chaque section critique : s'il n'y en a pas, aucun verrou ; s'il y en a un, le déplacer hors de la section, et à défaut poser un asyncio.Lock employé par async with.
5. Traquer les appels bloquants dans les coroutines, calculs longs, lectures de fichiers, bibliothèques non asynchrones, et les confier à asyncio.to_thread.
6. Poser un délai d'expiration sur toute attente réseau, par asyncio.wait_for, et décider ce que le programme rend quand un équipement ne répond pas.
7. Relire à la recherche des await manquants devant chaque appel de coroutine, et traiter le message coroutine ... was never awaited comme une erreur, jamais comme un avertissement.

Synthèse

• Le multitâche préemptif laisse le système interrompre un fil n'importe où ; le multitâche coopératif confie cette décision à la tâche, qui rend la main aux points marqués.
• Une boucle d'événements est un fil unique qui exécute les tâches prêtes, met de côté celles qui attendent, et les reprend quand leur attente est satisfaite.
• async def déclare une coroutine, await marque le point où elle rend la main et ce qu'elle attend, asyncio.gather lance un ensemble de coroutines, asyncio.run démarre la boucle.
• Rien ne s'interrompt au milieu d'un fragment sans await : la plupart des verrous du modèle préemptif disparaissent, et c'est ce qui explique le succès de ce modèle pour les architectures réseau.
• Un await dans une section critique rouvre la course à l'identique : quatre entrelacements sur six perdent alors une mise à jour, avec un seul fil d'exécution.
• Les deux erreurs qui reviennent sont le await oublié, qui rend un objet coroutine au lieu d'un résultat sans rien signaler, et l'appel bloquant, qui fige la boucle entière et toutes les autres tâches.
• Cinquante attentes réseau coûtent cinquante tâches plutôt que cinquante fils, pour un rapport de mémoire de l'ordre de deux mille sept cents et une durée totale égale à la plus longue attente.

Ce chapitre referme le parcours. Il a commencé sur trois pièces, des registres, de la mémoire et un compteur ordinal, et il se termine sur une machine qui paraît en mener plusieurs de front sans jamais cesser de n'exécuter qu'une instruction à la fois. Deux prolongements naturels : les structures de données du parcours Python, pour ranger proprement les cinquante relevés qu'un programme concurrent rapporte, et le chapitre sur le transport et la résolution de noms, qui dit ce qui se passe réellement pendant les deux cents millisecondes d'une attente réseau, et pourquoi elle dure ce qu'elle dure.