Mécanismes de répartition des files d’attente de travail

RDBSS utilise des files d’attente de travail du noyau Windows pour distribuer des opérations sur plusieurs threads pour une exécution ultérieure. Les pilotes de mini-redirecteur réseau peuvent utiliser les files d’attente de travail gérées par RDBSS pour distribuer des opérations pour une exécution ultérieure.

RDBSS fournit plusieurs routines qui implémentent le mécanisme de répartition utilisé dans RDBSS. Ces routines peuvent également être utilisées par les pilotes de mini-redirecteur réseau.

RDBSS effectue le suivi des éléments de travail sur une base par appareil. Cela permet à RDBSS de gérer les conditions de concurrence associées au chargement et au déchargement des mini-redirecteurs réseau. Cela fournit également un mécanisme dans RDBSS pour empêcher un mini-redirecteur réseau unique d’utiliser injustement toutes les ressources.

Il existe certains scénarios dans lesquels la répartition des éléments de travail est inévitable. Pour éviter l’allocation fréquente de mémoire et pour libérer des opérations dans ces scénarios, la WORK_QUEUE_ITEM est allouée dans le cadre d’une autre donnée. Dans d’autres scénarios où la répartition est rare, elle permet d’éviter l’allocation de mémoire tant qu’elle n’est pas nécessaire. L’implémentation de la file d’attente de travail RDBSS fournit ces deux scénarios sous la forme de la répartition et de la publication des demandes de file d’attente de travail. Dans le cas de la répartition à l’aide de la routine RxDispatchToWorkerThread , aucune mémoire pour l’WORK_QUEUE_ITEM ne doit être allouée par l’appelant. Pour la publication à l’aide de la routine RxPostToWorkerThread , la mémoire de l’WORK_QUEUE_ITEM doit être allouée par l’appelant.

Il existe deux cas courants de répartition d’opérations vers des threads de travail :

• Pour une opération très peu fréquente, utilisez la routine RxDispatchToWorkerThread pour conserver l’utilisation de la mémoire en allouant et en libérant de la mémoire de manière dynamique pour l’élément de file d’attente de travail lorsqu’il est nécessaire.

• Lorsqu’une opération sera distribuée à plusieurs reprises, utilisez la routine RxPostToWorkerThread pour conserver le temps en allouant à l’avance le WORK_QUEUE_ITEM dans le cadre de la structure de données à distribuer.

Le compromis entre les deux opérations de répartition est le temps et l’espace (utilisation de la mémoire).

Le mécanisme de répartition dans RDBSS fournit plusieurs niveaux de files d’attente de travail par processeur. Les niveaux suivants de files d’attente de travail actuellement pris en charge :

• Critique

• Retardé

• Hypercritique

La distinction entre Critique et Retard est l’une des priorités. Le niveau HyperCritical est différent des deux autres dans le sens où les routines ne doivent pas bloquer (attendre une ressource). Cette exigence ne peut pas être appliquée, de sorte que l’efficacité du mécanisme de répartition repose sur la coopération implicite des clients.

L’implémentation de file d’attente de travail dans RDBSS est conçue autour d’une implémentation KQUEUE. La prise en charge supplémentaire implique la réglementation d’un certain nombre de threads qui attendent activement les éléments de travail. Chaque structure de données de file d’attente de travail est allouée à partir de la mémoire du pool non paginé et possède son propre mécanisme de synchronisation (un verrouillage de spinlock).

En plus des informations de comptabilité (état et type de file d’attente, par exemple), RDBSS gère également les statistiques collectées au cours de la durée de vie de la file d’attente de travail. Cela peut fournir des informations précieuses dans le réglage d’une file d’attente de travail. Nombre d’éléments qui ont été traités, le nombre d’éléments devant être traités et la longueur de file d’attente cumulative est structurée. La longueur de file d’attente cumulative est une métrique importante et représente la somme du nombre d’éléments en attente de traitement chaque fois qu’un élément de travail supplémentaire a été mis en file d’attente. La longueur de file d’attente cumulative divisée par la somme du nombre total d’éléments traités et le nombre d’éléments à traiter indique la longueur moyenne de la file d’attente. Une valeur beaucoup supérieure à une signifie que le nombre minimal de threads de travail associés à la file d’attente de travail peut être augmenté. Une valeur beaucoup moins qu’une signifie que le nombre maximal de threads de travail associés à la file d’attente peut être réduit.

La file d’attente de travail démarre généralement dans un état actif et continue jusqu’à ce qu’une situation non récupérable soit rencontrée (absence de ressources système, par exemple) ou lorsqu’elle passe à l’état inactif. Lorsqu’un rundown est lancé, il passe à l’état d’exécution en cours.

L’exécution des files d’attente de travail n’est pas terminée lorsque les threads ont été mis hors service. L’arrêt des threads doit être assuré avant que les structures de données puissent être détruites. L’implémentation de file d’attente de travail dans RDBSS suit un protocole dans lequel chacun des threads en cours d’exécution enregistre une référence à l’objet thread dans le contexte d’exécution. Le thread d’émission de rundown (qui n’appartient pas à la file d’attente de travail) attend l’achèvement de tous les threads spun down avant de supprimer les structures de données.

L’implémentation actuelle des files d’attente RxDispatchToWorkerThread et RxPostToWorkerThread fonctionne sur le même processeur à partir duquel l’appel provient.

Les routines RDBSS suivantes pour la répartition des files d’attente de travail incluent.