Regroupement des threads

  • Article

Il existe de nombreuses applications qui créent des threads qui passent beaucoup de temps dans l’état de veille à attendre qu’un événement se produise. D’autres threads peuvent entrer dans un état de veille uniquement pour être réveillés régulièrement pour rechercher une modification ou mettre à jour des informations status. Le regroupement de threads vous permet d’utiliser les threads plus efficacement en fournissant à votre application un pool de threads de travail gérés par le système. Au moins un thread surveille la status de toutes les opérations d’attente mises en file d’attente dans le pool de threads. Lorsqu’une opération d’attente est terminée, un thread de travail du pool de threads exécute la fonction de rappel correspondante.

Cette rubrique décrit l’API du pool de threads d’origine. L’API de pool de threads introduite dans Windows Vista est plus simple, plus fiable, offre de meilleures performances et offre plus de flexibilité aux développeurs. Pour plus d’informations sur l’API de pool de threads actuelle, consultez Pools de threads.

Vous pouvez également mettre en file d’attente des éléments de travail qui ne sont pas liés à une opération d’attente dans le pool de threads. Pour demander qu’un élément de travail soit géré par un thread dans le pool de threads, appelez la fonction QueueUserWorkItem . Cette fonction prend un paramètre à la fonction qui sera appelée par le thread sélectionné dans le pool de threads. Il n’existe aucun moyen d’annuler un élément de travail une fois qu’il a été mis en file d’attente.

Les minuteurs de file d’attente du minuteur et lesopérations d’attente inscrites utilisent également le pool de threads. Leurs fonctions de rappel sont mises en file d’attente dans le pool de threads. Vous pouvez également utiliser la fonction BindIoCompletionCallback pour publier des opérations d’E/S asynchrones. À l’achèvement de l’E/S , le rappel est exécuté par un thread de pool de threads.

Le pool de threads est créé la première fois que vous appelez QueueUserWorkItem ou BindIoCompletionCallback, ou lorsqu’un minuteur de file d’attente ou une opération d’attente inscrite met en file d’attente une fonction de rappel. Par défaut, le nombre de threads qui peuvent être créés dans le pool de threads est d’environ 500. Chaque thread utilise la taille de pile par défaut et s’exécute à la priorité par défaut.

Il existe deux types de threads de travail dans le pool de threads : les E/S et les autres. Un thread de travail d’E/S est un thread qui attend dans un état d’attente pouvant être alerté. Les éléments de travail sont mis en file d’attente vers des threads de travail d’E/S en tant qu’appels de procédure asynchrone (APC). Vous devez mettre en file d’attente un élément de travail vers un thread de travail d’E/S s’il doit être exécuté dans un thread qui attend dans un état d’alerte.

Un thread de travail non-E/S attend sur les ports d’achèvement des E/S. L’utilisation de threads de travail non-E/S est plus efficace que l’utilisation de threads de travail d’E/S. Par conséquent, vous devez utiliser des threads de travail non-E/S dans la mesure du possible. Les threads de travail d’E/S et non-E/S ne se quittent pas s’il y a des demandes d’E/S asynchrones en attente. Les deux types de threads peuvent être utilisés par les éléments de travail qui lancent des demandes d’achèvement d’E/S asynchrones. Toutefois, évitez de publier des demandes d’achèvement d’E/S asynchrones dans des threads de travail non-E/S si elles peuvent prendre beaucoup de temps.

Pour utiliser le regroupement de threads, les éléments de travail et toutes les fonctions qu’ils appellent doivent être sécurisés pour le pool de threads. Une fonction sécurisée ne suppose pas que le thread qui l’exécute est un thread dédié ou persistant. En général, vous devez éviter d’utiliser le stockage local de thread ou d’effectuer un appel asynchrone qui nécessite un thread persistant, tel que la fonction RegNotifyChangeKeyValue . Toutefois, ces fonctions peuvent être appelées sur un thread dédié (créé par l’application) ou mises en file d’attente vers un thread de travail persistant (à l’aide de QueueUserWorkItem avec l’option WT_EXECUTEINPERSISTENTTHREAD).

E/S pouvant être alertables

Appels de procédure asynchrone

Ports d’achèvement des E/S

Pools de threads