Share via


Service de classement des threads

Le service de classement des threads contrôle l’exécution d’un ou plusieurs threads clients. Il garantit que chaque thread client s’exécute une fois pendant la période spécifiée et dans l’ordre relatif.

Windows Server 2003 et Windows XP : Le service de classement des threads est disponible à partir de Windows Vista et Windows Server 2008.

Le service de classement des threads est désactivé par défaut et doit être démarré par l’utilisateur. Pendant l’exécution du service de classement des threads, il est activé toutes les 5 secondes pour case activée s’il existe une nouvelle requête, même si le système est inactif. Cela empêche le système de se mettre en veille pendant plus de 5 secondes, ce qui entraîne la consommation d’énergie du système. Si l’efficacité énergétique est essentielle pour l’application, il est préférable de ne pas utiliser le service de classement des threads et de laisser plutôt le planificateur système gérer l’exécution des threads.

Chaque thread client appartient à un groupe de classement de threads. Le thread parent crée un ou plusieurs groupes de classement de threads en appelant la fonction AvRtCreateThreadOrderingGroup . Le thread parent utilise cette fonction pour spécifier la période du groupe de classement des threads et un intervalle de délai d’attente.

D’autres threads clients appellent la fonction AvRtJoinThreadOrderingGroup pour rejoindre un groupe de classement de threads existant. Ces threads indiquent s’ils doivent être un prédécesseur ou un successeur du thread parent dans l’ordre d’exécution. Chaque thread client est censé effectuer une certaine quantité de traitement chaque période. Tous les threads au sein du groupe doivent terminer leur exécution dans la période plus l’intervalle de délai d’attente.

Les threads d’un groupe de tri des threads enferment leur code de traitement dans une boucle contrôlée par la fonction AvRtWaitOnThreadOrderingGroup . Tout d’abord, les threads prédécesseurs sont exécutés un par un dans l’ordre dans lequel ils ont rejoint le groupe, tandis que les threads parent et successeur sont bloqués lors de leurs appels à AvRtWaitOnThreadOrderingGroup. Lorsque chaque thread prédécesseur a terminé son traitement, le contrôle de l’exécution revient en haut de sa boucle de traitement et le thread appelle à nouveau AvRtWaitOnThreadOrderingGroup pour le bloquer jusqu’à son tour suivant. Une fois que tous les threads prédécesseurs ont appelé cette fonction, le service de classement des threads peut planifier le thread parent. Enfin, lorsque le thread parent termine son traitement et appelle à nouveau AvRtWaitOnThreadOrderingGroup , le service de classement des threads peut planifier les threads successeurs un par un dans l’ordre dans lequel ils ont rejoint le groupe. Si tous les threads terminent leur exécution avant la fin d’un point, tous les threads attendent que le reste de la période s’écoule avant d’être réexécutés.

Lorsque le client n’a plus besoin de s’exécuter dans le cadre du groupe de tri des threads, il appelle la fonction AvRtLeaveThreadOrderingGroup pour se supprimer du groupe. Notez que le thread parent ne doit pas se supprimer d’un groupe de classement de threads. Si un thread ne termine pas son exécution avant l’expiration de la période plus l’intervalle de délai d’attente, il est supprimé du groupe.

Le thread parent appelle la fonction AvRtDeleteThreadOrderingGroup pour supprimer le groupe d’ordre des threads. Le groupe de classement des threads est également détruit si le thread parent ne termine pas son exécution avant l’expiration de la période plus l’intervalle de délai d’attente. Lorsque le groupe d’ordre de threads est détruit, tous les appels à AvRtWaitOnThreadOrderingGroup à partir de threads de ce groupe échouent ou expirent.