Avantages et inconvénients du port d'achèvement d'E / S
Pourquoi beaucoup de gens disent que le port d'achèvement des E/S est un modèle rapide et agréable?
Quels sont les avantages et les inconvénients du port d'achèvement d'E/S?
Je veux connaître certains points qui rendent l'IOCP plus rapide que les autres modèles.
Si vous pouvez l'expliquer en comparant d'autres modèles (select, epoll, multi thread/process traditionnel), ce serait mieux.
Les ports d'achèvement des E/S sont impressionnants. Il n'y a pas de meilleur mot pour les décrire. Si quelque chose dans Windows a été fait correctement, ce sont les ports d'achèvement.
Vous pouvez créer un certain nombre de threads (peu importe le nombre) et les faire tous bloquer sur un port d'achèvement jusqu'à ce qu'un événement (soit celui que vous publiez manuellement, soit un événement de ne minuterie ou E/S asynchrones, ou autre) arrive. Ensuite, le port d'achèvement réveillera un thread pour gérer l'événement, jusqu'à la limite que vous avez spécifiée. Si vous n'avez rien spécifié, cela supposera "jusqu'à nombre de cœurs de processeur", ce qui est vraiment sympa.
S'il y a déjà plus de threads actifs que la limite maximale, il attendra que l'un d'eux soit terminé, puis remettra l'événement au thread dès qu'il passera à l'état d'attente. De plus, il réveillera toujours les threads dans un ordre LIFO, donc les chances sont que les caches soient encore chauds.
En d'autres termes, les ports d'achèvement sont une "interrogation des événements" simple et une solution "remplissez le CPU autant que vous le pouvez".
Vous pouvez lancer des lectures et des écritures de fichiers sur un port d'achèvement, des sockets ou tout autre élément pouvant être attendu. Et, vous pouvez publier vos propres événements si vous le souhaitez. Chaque événement personnalisé a au moins un entier et un pointeur de données (si vous utilisez la structure par défaut), mais vous n'êtes pas vraiment limité à cela car le système acceptera volontiers toute autre structure également.
De plus, les ports d'achèvement sont rapides, vraiment très rapides. Il était une fois, je devais notifier un fil d'un autre. En l'occurrence, ce thread avait déjà un port d'achèvement pour les E/S de fichiers, mais il n'a pas pompé de messages. Donc, je me suis demandé si je devais juste mordre la balle et utiliser le port de complétion pour plus de simplicité, même si publier un message de discussion serait évidemment beaucoup plus efficace. J'étais indécis, j'ai donc mesuré. Surprise, il s'est avéré que les ports d'achèvement étaient environ 3 fois plus rapides. Alors ... plus rapide et plus flexible, la décision n'a pas été difficile.
en utilisant IOCP, nous pouvons surmonter le problème "un thread par client". Il est communément admis que les performances diminuent fortement si le logiciel ne fonctionne pas sur une véritable machine multiprocesseur. Les threads sont des ressources système qui ne sont ni illimitées ni bon marché.
IOCP fournit un moyen pour que quelques threads (travailleur d'E/S) gèrent les entrées/sorties de plusieurs clients de manière "équitable". Les threads sont suspendus et n'utilisent pas les cycles CPU tant qu'il n'y a rien à faire.
Vous pouvez également lire quelques informations dans ce livre de Nice http://www.Amazon.com/Windows-System-Programming-Johnson-Hart/dp/032125619