Le programmateur est programmé par
- un événement (externe) comme une interruption, (disque fait, clic de souris, graduation de minuterie)
- ou un événement interne (telles que la réalisation d'un fil , la signalisation par un thread qu'il doit attendre quelque chose, ou la signalisation d'un thread qu'il a libéré une ressource, ou un piège causé par un thread faisant quelque chose d'illégal comme la division par zéro)
En bref , il est déclenché par tout événement qui pourrait exiger que L'ensemble des tâches à exécuter et/ou les priorités de ces tâches à réévaluer. Le planificateur décide quelle (s) tâche (s) exécutera ensuite et passe le contrôle à la tâche suivante.
En règle générale, cette « programmation » du planificateur est causé par le code associé à une interruption matérielle ou le code associé à un appel système.
Alors que vous pouvez penser à l'ordonnanceur comme étant un vrai fil, dans la pratique, il n'a pas besoin d'être mis en œuvre de cette façon ... parce qu'il est exécuté avec une priorité plus élevée que toute autre tâche. Systèmes d'exploitation sophistiqués peuvent en effet mettre de côté un fil spécial qui est le planificateur et le marquer occupé lorsque le planificateur prend le contrôle. Cela rend la tâche intéressante, mais le thread fictif n'est pas planifié par le planificateur
On peut avoir plusieurs planificateurs: le plus prioritaire (par exemple, celui que nous venons de décrire), et d'autres planificateurs qui sont vraiment des threads, et sont exécuter comme les autres tâches de l'utilisateur. De tels ordonnanceurs de priorité inférieure ont tendance à être utilisés pour gérer des actions qui se produisent à des intervalles beaucoup plus longs, tels que des tâches d'arrière-plan.
Il n'y a pas vraiment de réponse générique. Vous auriez besoin de regarder une implémentation spécifique du système d'exploitation. Cependant, la réponse de @ Ira est probablement applicable à la plupart des systèmes d'exploitation. – Benoit