Objets du minuteur du noyau et synchronisation

Question

Je me demandais si quelqu'un pouvait me dire simplement (je sais que ce n'est pas un sujet simple) comment les objets du minuteur du noyau sont utilisés pour synchroniser l'accès aux structures de données dans le noyau?

EDIT:

Un objet de la minuterie du noyau fait partie des objets répartiteur du noyau, qui sont le groupe le noyau des objets de synchronisation. Je voulais aussi savoir si l'objet timer est la chose qu'un thread doit attendre avant d'être en mesure de continuer, ou est-ce le callback qui est déclenché quand le timer expire qu'un thread attend d'avoir un handle ?

J'espère que cela a du sens. Les grains sont un nouveau sujet pour moi.

Answer 1

Réponse courte: objets de minuterie sont pas utilisé pour synchroniser l'accès aux structures de données dans le noyau. Pour cela, le noyau NT a des choses comme le mutex rapide, le mutex gardé, le verrou push, l'objet mutex, etc. Je ne comprends pas très bien votre question - de quelles structures de données parlez-vous? Néanmoins, je continuerai en supposant que vous voulez savoir comment les objets minuterie peuvent être utilisés.

Vous pouvez utiliser des objets de minuterie de deux manières. Le premier est qu'ils sont signalés après un délai spécifié . Ainsi, un thread peut attendre sur un objet timer en utilisant KeWaitForSingleObject, et il ne se réveillera que lorsque l'heure normale sera arrivée. Vous pouvez également utiliser une signalisation périodique pour la minuterie - vous pourriez vouloir la réinitialiser à un état non signalé chaque fois qu'un thread est réveillé par elle, et être signalé toutes les quelques secondes.

La deuxième utilisation (moins fréquente) est que les objets de minuterie peuvent insérer des APC dans le thread qui définit le minuteur. Dans le cas où vous ne savez pas ce qu'est un APC - c'est un appel de procédure asynchrone. Si un thread exécute un alertable wait, un APC inséré interrompt l'attente et commence l'exécution. Bien sûr, les APC sont difficiles à utiliser, c'est pourquoi les gens aiment enregistrer les objets timer avec le pool de threads et il prend soin de gérer les callbacks (mais c'est un autre sujet).

Answer 2

C'est une méthode pour synchroniser en évitant l'accès simultané. L'accès est contrôlé essentiellement par la sérialisation qui se produit dans une fonction de gestionnaire unique appelée par un rappel, dans ce cas un rappel par minuterie. Voir this.

Le point de gestion de l'accès est d'empêcher deux threads d'accéder simultanément (en lecture ou en écriture) à un objet en même temps. Il existe plusieurs mécanismes pour accomplir ceci:

• Un seul thread: la contention n'est pas possible car il n'y a qu'un seul acteur.
• Mutex: un mécanisme de système d'exploitation est combiné avec des techniques de codage pour formaliser l'accès de sorte que chaque fois qu'un thread dit je veux contrôler du mutex. Lorsque le contrôle est accordé, cela signifie que personne d'autre ne peut accéder à l'objet associé tant que le propriétaire du mutex ne le libère pas.
• Sérialisation: similaire à un seul thread. Un schéma typique permet aux demandes d'être mises en file d'attente. Une fois les demandes plus prioritaires terminées, votre demande est traitée. Aucune autre demande pour l'objet n'est traitée tant que la vôtre n'est pas terminée.

Answer 3

Vous devez l'afficher de cette manière: lorsque vous attendez une minuterie, vous devez synchroniser à l'expiration de la minuterie.Votre thread ne s'exécutera pas jusqu'à ce que la temporisation spécifiée du temporisateur se soit écoulée (sous réserve de la granularité du temps système, qui est généralement de 15,6 ms). En général, appeler le temporisateur un "objet de synchronisation" a plus à voir avec la famille d'API que vous utilisez pour connaître son délai sur un thread que la fonction réelle de l'objet lui-même.

Plus souvent qu'autrement en mode noyau, l'expiration du minuteur est réellement consommée en utilisant un rappel DPC (voir le paramètre DPC à KeSetTimer). C'est juste un appel asynchrone qui se produit dans un contexte de thread arbitraire dans le noyau où vous pouvez faire fonctionner votre code (mais il ne peut pas bloquer, prendre des verrous, accéder à la mémoire paginable, etc.). Ces dernières restrictions ne sont pas vraiment un problème pour les pilotes de périphériques, qui veulent généralement simplement toucher leurs appareils périodiquement.