Threads vs. Async

Question

J'ai lu un article très intéressant sur le modèle de programmation threadé par rapport au modèle asynchrone. http://krondo.com/blog/?p=1209

Cependant, l'article mentionne les points suivants.

1. Un programme asynchrone surpassera simplement un programme synchrone en passant d'une tâche à l'autre dès qu'il y a une E/S.
2. Les threads sont gérés par le système d'exploitation.

Je me souviens avoir lu que les threads sont gérés par le système d'exploitation en déplaçant les TCB entre la file d'attente prête et la file d'attente d'attente (parmi d'autres files). Dans ce cas, les threads ne perdent pas de temps en attente, n'est-ce pas?

À la lumière de ce qui précède, quels sont les avantages des programmes asynchrones par rapport aux programmes threadés?

Answer 1

Pour être juste, soulignons les avantages des Threads sous CPython GIL par rapport à l'approche asynchrone :

1. il est plus facile d'abord d'écrire du code typique qui a un seul flux d'événements (pas d'exécution parallèle) puis d'exécuter plusieurs copies de celui-ci dans des threads séparés : cela maintiendra chaque copie réactive, tandis que l'avantage d'exécuter toutes les opérations d'entrée/sortie en parallèle sera automatiquement atteint ;
2. de nombreuses bibliothèques éprouvées sont synchrones et donc faciles à inclure dans la version threadée, mais pas dans la version asynchrone ;
3. certaines bibliothèques synchrones laissent en réalité le GIL passer au niveau C, ce qui permet une exécution parallèle pour les tâches autres que celles liées à l'entrée/sortie : par exemple NumPy ;
4. il est plus difficile d'écrire du code asynchrone en général : l'inclusion d'une section intensive en CPU rendra les tâches concurrentes non réactives, ou bien on peut oublier d'attendre le résultat et terminer l'exécution plus tôt.

Donc, s'il n'y a pas de plans immédiats pour faire évoluer vos services au-delà d'environ ~100 connexions simultanées, il peut être plus simple de commencer par une version threadée puis de la réécrire... en utilisant un autre langage plus performant comme Go.

Answer 2

Async I/O signifie qu'il y a déjà un thread dans le pilote qui fait le travail, donc vous dupliquez la fonctionnalité et vous subissez des frais généraux. D'un autre côté, il n'est souvent pas documenté comment exactement le thread du pilote se comporte, et dans des scénarios complexes, lorsque vous souhaitez contrôler le timeout/l'annulation/le démarrage/l'arrêt, la synchronisation avec d'autres threads, il est logique d'implémenter votre propre thread. Il est aussi parfois plus facile de raisonner en termes synchrones.