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

1. Il est très difficile d'écrire du code qui est thread safe. Avec du code asynchrone, vous savez exactement où le code va passer d'une tâche à l'autre et les conditions de course sont donc beaucoup plus difficiles à rencontrer.
2. Les threads consomment une quantité importante de données car chaque thread doit avoir sa propre pile. Avec du code asynchrone, tout le code partage la même pile et la pile est maintenue petite grâce au déroulement continu de la pile entre les tâches.
3. Les threads sont des structures OS et nécessitent donc plus de mémoire pour la plateforme. Il n'y a pas de tel problème avec les tâches asynchrones.

Mise à jour 2022:

De nombreux langages prennent désormais en charge les co-routines sans pile (async/await). Cela nous permet d'écrire une tâche de manière presque synchrone tout en cédant à d'autres tâches (await) à des endroits définis (en attente ou en attente de réseautage ou d'autres threads)

Answer 2

Il existe deux façons de créer des threads :

threading synchrone - le parent crée un (ou plusieurs) threads enfants et doit ensuite attendre que chaque enfant se termine. Le threading synchrone est souvent désigné sous le nom de modèle fork-join.

threading asynchrone - le parent et l'enfant s'exécutent simultanément/indépendamment l'un de l'autre. Les serveurs multithreadés suivent généralement ce modèle.

source - http://www.amazon.com/Operating-System-Concepts-Abraham-Silberschatz/dp/0470128720

Answer 3

1. Supposons que vous ayez 2 tâches, qui n'impliquent pas d'E/S (sur une machine multiprocesseur). Dans ce cas, les threads surclassent les Async. Parce qu'Async, comme un programme à thread unique, exécute vos tâches dans l'ordre. Mais les threads peuvent exécuter les deux tâches simultanément.

2. Supposons que vous ayez 2 tâches, qui impliquent de l'E/S (sur une machine multiprocesseur). Dans ce cas, à la fois Async et les threads offrent à peu près les mêmes performances (cela peut varier en fonction du nombre de cœurs, de l'ordonnancement, de l'intensité du traitement de la tâche, etc.). De plus, Async utilise moins de ressources, a moins de surcharge et est moins complexe à programmer qu'un programme multi-thread.

Comment cela fonctionne ? Le thread 1 exécute la tâche 1, comme il est en attente d'E/S, il est déplacé dans la file d'attente d'attente d'E/S. De même, le thread 2 exécute la tâche 2, comme elle implique également de l'E/S, elle est déplacée dans la file d'attente d'attente d'E/S. Dès que sa demande d'E/S est résolue, elle est déplacée dans la file d'attente prête afin que l'ordonnanceur puisse planifier le thread pour l'exécution.

Async exécute la tâche 1 et, sans attendre que son E/S soit terminée, il continue avec la tâche 2, puis il attend que l'E/S des deux tâches soit terminée. Il termine les tâches dans l'ordre de l'achèvement de l'E/S.

Async convient mieux pour les tâches impliquant des appels de services Web, des requêtes de base de données, etc., Les threads pour les tâches intensives en traitement.

La vidéo ci-dessous explique lemodèle Async vs Threaded et aussi quand l'utiliser, etc., https://www.youtube.com/watch?v=kdzL3r-yJZY

J'espère que cela vous sera utile.

Answer 4

Tout d'abord, notez qu'une grande partie des détails sur la manière dont les threads sont implémentés et planifiés sont très spécifiques à l'OS. En général, vous ne devriez pas avoir à vous soucier des threads qui attendent les uns les autres, car l'OS et le matériel essayeront de les faire fonctionner de manière efficace, que ce soit de manière asynchrone sur un système monoprocesseur ou en parallèle sur des processeurs multiples.

Une fois qu'un thread a fini d'attendre quelque chose, par exemple l'E/S, il peut être considéré comme prêt à s'exécuter. Les threads prêts à être exécutés seront planifiés pour être exécutés prochainement. Que cela soit implémenté sous forme de file d'attente simple ou quelque chose de plus sophistiqué est, une fois de plus, spécifique à l'OS et au matériel. Vous pouvez considérer l'ensemble des threads bloqués comme un ensemble plutôt que comme une file strictement ordonnée.

Notez que sur un système monoprocesseur, les programmes asynchrones tels que définis ici sont équivalents aux programmes threadés.

Answer 5

Voir http://en.wikipedia.org/wiki/Thread_(computing)#I.2FO_and_scheduling

Cependant, l'utilisation d'appels système bloquants dans les threads utilisateur (par opposition aux threads noyau) ou aux fibres peut poser problème. Si un thread utilisateur ou une fibre effectue un appel système qui bloque, les autres threads utilisateur et les fibres du processus ne peuvent pas s'exécuter tant que l'appel système n'est pas renvoyé. Un exemple typique de ce problème est lors de l'exécution d'E/S : la plupart des programmes sont écrits pour effectuer des E/S de manière synchrone. Lorsqu'une opération d'E/S est lancée, un appel système est effectué, et ne renvoie pas tant que l'opération d'E/S n'est pas terminée. Pendant cette période, l'ensemble du processus est "bloqué" par le noyau et ne peut pas s'exécuter, privant ainsi les autres threads utilisateur et les fibres du même processus de s'exécuter.

En conséquence, l'ensemble de votre processus peut être bloqué, et aucun thread ne sera planifié lorsqu'un thread est bloqué en E/S. Je pense que ceci est spécifique à l'OS et ne sera pas toujours vrai.