Threads vs. Async
J'ai lu sur le modèle fileté de la programmation par rapport au modèle asynchrone de ce très bon article. http://krondo.com/blog/?p=1209
Cependant, l'article mentionne les points suivants.
- Un programme asynchrone surperformera simplement un programme de synchronisation en passant d’une tâche à l’autre en présence d’une E/S.
- 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 se déplaçant entre les TCB entre Ready-Queue et Waiting-Queue (parmi d'autres files d'attente). Dans ce cas, les threads ne perdent pas de temps à attendre, 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?
- Il est très difficile d’écrire du code thread-safe. Avec du code asynchrone, vous savez exactement où le code passera d'une tâche à l'autre et les conditions de course sont donc beaucoup plus difficiles à trouver.
- Les threads consomment pas mal de données car chaque thread doit avoir sa propre pile. Avec le code async, tout le code partage la même pile et la pile est réduite en raison du déroulement continu de la pile entre les tâches.
- Les threads sont des structures de système d'exploitation et représentent donc davantage de mémoire pour la plate-forme. Ce problème n'existe pas avec les tâches asynchrones.
Il existe deux manières de créer des threads:
thread synchrone - le parent crée un (ou plusieurs) thread enfant et doit ensuite attendre que chaque enfant se termine. Le threading synchrone est souvent appelé le modèle fork-join .
thread asynchrone - le parent et l'enfant s'exécutent simultanément/indépendamment l'un de l'autre. Les serveurs multithread suivent généralement ce modèle.
ressource - http://www.Amazon.com/Operating-System-Concepts-Abraham-Silberschatz/dp/0470128720
Tout d’abord, notez que beaucoup de détails sur la façon dont les threads sont implémentés et planifiés sont très spécifiques au système d’exploitation. En général, vous ne devriez pas avoir à vous soucier des threads en attente les uns des autres, car le système d'exploitation et le matériel essaieront de leur permettre de fonctionner efficacement, de manière asynchrone sur un système à processeur unique ou en parallèle sur des processeurs multiples.
Une fois qu'un thread a fini d'attendre quelque chose, par exemple I/O, il peut être considéré comme exécutable. Les threads qui peuvent être exécutés seront prochainement programmés pour une exécution. Qu'il s'agisse d'une simple file d'attente ou de quelque chose de plus sophistiqué, cela dépend des systèmes d'exploitation et du matériel. Vous pouvez considérer l'ensemble des threads bloqués comme un ensemble plutôt que comme une file d'attente strictement ordonnée.
Notez que sur un système à processeur unique, les programmes asynchrones tels que définis ici sont équivalents aux programmes threadés.
Supposons que vous avez 2 tâches, qui n'impliquent aucun IO (sur une machine multiprocesseur) . Dans ce cas, les threads surpassent Async. Parce qu'Async ressemble à un programme à thread unique .__ exécute vos tâches dans l'ordre. Mais les threads peuvent exécuter les deux tâches simultanément.
Supposons que vous ayez 2 tâches, impliquant IO (sur une machine multiprocesseur) . Dans ce cas, les tâches Async et Threads fonctionnent plus ou moins de la même manière beaucoup de processus la tâche, etc.). De plus, Async nécessite moins de ressources, moins de frais généraux et moins complexe à programmer sur des programmes multithreads.
Comment ça marche? Le fil 1 exécute la tâche 1, car il attend l'IO, il est déplacé vers IO file d'attente. De même, le thread 2 exécute la tâche 2, car il implique également IO, il est déplacé vers la file d'attente IO en attente. Dès que la demande IO est résolue il est déplacé vers la file d'attente Ready afin que le planificateur puisse planifier le thread pour exécution.
Async exécute la tâche 1 sans attendre que IO l'achève continue avec la tâche 2 puis attend IO de la tâche à compléter. Il termine les tâches dans l’ordre d’achèvement de IO.
Async mieux adapté aux tâches impliquant des appels de service Web, Requête base de données appels etc., Discussions pour les tâches intensives en processus.
La vidéo ci-dessous explique environAsync vs Threaded model et indique également quand utiliser etc., https://www.youtube.com/watch?v=kdzL3r-yJZY
J'espère que c'est utile.
voir http://fr.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 du noyau) ou dans les fibres peut être problématique. Si un thread utilisateur ou une fibre effectue un appel système bloquant, les autres threads et fibres du processus ne peuvent pas être exécutés tant que l'appel système n'est pas revenu. 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 revient que lorsque l'opération d'E/S est terminée. Dans l'intervalle, l'ensemble du processus est "bloqué" par le noyau et ne peut pas s'exécuter, ce qui empêche d'autres threads et fibres utilisateur de s'exécuter.
Dans ce cas, tout votre processus pourrait être bloqué et aucun thread ne sera planifié lorsqu'un seul thread est bloqué dans IO. Je pense que cela est spécifique au système d'exploitation et ne sera pas toujours valable.
E/S async signifie qu'un thread dans le pilote est déjà en train de faire le travail, vous dupliquez donc des fonctionnalités et vous induisez des frais supplémentaires. D'un autre côté, souvent, le comportement exact du thread de pilote n'est pas documenté. Dans des scénarios complexes, lorsque vous souhaitez contrôler le comportement de délai d'attente/annulation/démarrage/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 de synchronisation.