API de pool de threads
L’interface de programmation d’application (API) du pool de threads utilise une conception basée sur des objets. Chacun des objets suivants est représenté par une structure de données en mode utilisateur :
- Un objet de pool est un ensemble de threads de travail qui peuvent être utilisés pour effectuer un travail. Chaque processus peut créer plusieurs pools isolés avec des caractéristiques différentes si nécessaire. Il existe également un pool par défaut pour chaque processus.
- Un groupe propre est associé à un ensemble d’objets générateurs de rappel. Des fonctions existent pour attendre et libérer tous les objets membres de chaque groupe propre. Cela permet à l’application de garder le suivi de tous les objets qu’elle a créés.
- Un objet de travail est affecté à un pool et éventuellement à un groupe propre. Il peut être publié, ce qui entraîne l’exécution d’un thread worker à partir du pool. Un objet de travail peut avoir plusieurs billets en attente ; chacun génère un rappel. L’opération de post-publication ne peut pas échouer en raison d’un manque de ressources.
- Un objet minuteur contrôle la planification des rappels. Chaque fois qu’un minuteur expire, son rappel est publié dans son pool de workers. La définition d’un minuteur ne peut pas échouer en raison d’un manque de ressources.
- Un objet wait entraîne l’attente d’un thread serveur sur un handle d’attente. Une fois que l’attente est satisfaite ou que le délai d’expiration expire, le thread du serveur publie le rappel des objets d’attente vers le pool worker de l’attente. La définition d’une attente ne peut pas échouer en raison d’un manque de ressources.
- Un objet d’E/S associe un handle de fichier au port d’achèvement des E/S pour le pool de threads. Lorsqu’une opération d’E/S asynchrone se termine, un thread de travail récupère le status de l’opération et appelle le rappel de l’objet E/S.
Le tableau suivant décrit les fonctionnalités des API de pool de threads d’origine et actuelles.
Rubriques connexes