2. Rôle, événements et objectifs de l’ordonnanceur
2.1 Choisir parmi les tâches prêtes
L’ordonnanceur choisit quelle unité d’exécution prête recevra le CPU. Le cours parle suivant les exemples de processus, thread noyau, tâche ou job. Une tâche bloquée sur une E/S ou une synchronisation n’est pas candidate simplement parce qu’elle existe : il faut distinguer les états prêt, exécuté et bloqué.
La politique détermine l’ordre de service et parfois sa quantité. Elle influe sur la réponse ressentie par l’utilisateur et sur le débit de travail utile. Répondre rapidement à une tâche et finir beaucoup de travail par unité de temps sont deux objectifs différents; améliorer l’un peut dégrader l’autre.
Changer de processus coûte du temps : passage en mode noyau, sauvegarde du contexte, changement de l’espace d’adressage géré par la MMU, décision de l’ordonnanceur, restauration puis retour utilisateur. Le CPU effectue ces opérations au lieu d’avancer le programme. Une commutation entre threads d’un même processus garde l’espace d’adressage, mais possède quand même un état d’exécution à changer; elle n’est pas une absence totale de coût.
2.2 Quand un nouveau choix intervient
Un choix peut suivre la création (fork), la fin (exit), un blocage sur E/S/mutex/condition, un réveil, ou une cession volontaire (yield). Les interruptions d’E/S rendent éventuellement une tâche prête. L’horloge permet au noyau de reprendre le contrôle après une tranche et, si la politique le prévoit, de retirer le CPU à une tâche encore exécutable.
La préemption est ce retrait sans attendre une fin, un blocage ou une cession volontaire. Elle empêche notamment une boucle infinie en mode utilisateur de conserver à elle seule le CPU. Une politique non préemptive peut changer de tâche à un blocage ou une fin : « non préemptif » ne veut pas dire que la même tâche reste toujours exécutée.
Le support appelle quantum l’intervalle d’horloge du modèle simplifié puis la tranche maximale de RR. Il donne 5–20 ms comme ordre de grandeur PC. Ces nombres illustrent le cours; ils ne définissent pas le réglage universel des systèmes actuels. La règle exacte d’une simulation vient de l’énoncé.
2.3 Quel résultat cherche-t-on?
| Contexte | Orientation du support | Pourquoi |
|---|---|---|
| Lots | Non-préemptif ou long quantum | Réduire la gestion et favoriser le débit |
| Interactif | Préemptif, possibilités fréquentes de prendre le CPU | Limiter la latence ressentie |
| Temps réel | Réponse maîtrisée, comportement prévisible | Respecter les contraintes temporelles |
Les illustrations sont environ 200 ms pour un exemple Windows Server, 5–20 ms pour Windows interactif et jusqu’à 40 µs ajustables pour QNX. Elles caractérisent les exemples pédagogiques, sans imposer ces constantes à une expérience actuelle.
Il faut considérer CPU et autres composants. Une tâche E/S peut utiliser brièvement le CPU pour lancer sa prochaine requête, puis laisser CPU et disque travailler en parallèle avec d’autres tâches. La retarder longtemps peut empêcher ce recouvrement; maximiser la tranche d’un calcul ne maximise pas forcément l’utilisation de toute la machine.
L’équité cherche une possibilité de progrès ou une part de ressource appropriée. La famine apparaît lorsqu’une tâche reste prête mais que les choix favorisent indéfiniment les autres. Une bonne moyenne n’exclut pas une attente individuelle très mauvaise. Les priorités, les quanta et les poids répondent à des critères différents, qu’il faut nommer avant de comparer les résultats.