Mécanisme de commutation de contexte

Le basculement de l'activité, entre deux processus, s'opère par commutation de contexte.Imaginons, pour simplifier, un système d'exploitation très rudimentaire qui se limiterait à un  programme unique qui gérerait à la fois le fonctionnement de l'ordinateur et les processus de l'utilisateur.  Cette image est celle d'un   programme où   les processus de l'utilisateur  seraient   un ensemble de fonctions appelées successivement par le programme principal qui représente le système d'exploitation. Le fonctionnement du système d'exploitation serait très délicat à réaliser car il faudrait le modifier chaque fois que l'on désirerait exécuter de nouveaux programmes utilisateurs. Il serait mal aisé de les substituer les uns aux autres dynamiquement.   Pensez aux précautions qu'il faut prendre lorsqu'on veut remplacer une simple fonction dans un programme ! Tout changement risquerait de perturber le déroulement des activités indispensables à la bonne marche de l'ordinateur. Par exemple, il deviendrait impossible de garantir que l'horloge puisse donner l'heure exacte.  Si une procédure de l'utilisateur demandait trop de calcul au processeur, la procédure du système en charge de compter les secondes ne pourrait plus faire son travail à temps. Il faut donc  prévoir un moyen plus souple pour pouvoir gérer plusieurs processus simultanément c'est à dire décomposer son fonctionnement en un ensemble de rpocessus indépendants. On les active ou désactive en fonction de critères qui seront décrits progressivement dans la suite de ce cours.

L'opération de commutation de contexte, préalable au changement de processus actif, est l'enchaînement indivisible des deux opérations suivantes:

1. rangement du mot d'état du processus actif à un emplacement particulier de la mémoire et copie du contexte du processeur.
2. chargement du mot d'état d'un autre processus, depuis un emplacement spécifique de la mémoire, vers le processeur et récupération du contexte du processeur correspondant.

Le nouveau processus peut alors être exécuté à partir de l'état où il se trouvait lorsqu'il a été lui-même interrompu. Insistons sur le fait que cette commutation de contexte ne peut être effectuée que lorsque le processeur se trouve dans un état observable, c'est à dire entre deux instructions. La notion  d'instruction est relative au  microcode de la machine qui a peu à voir avec celle utilisée par le programmeur qui pense aux instructions  du langage évolué qu'il emploie.  Une instruction de C ou Fortran, de Java encore plus,  correspond à plusieurs instructions du microcode. Le temps d'exécution de ces instructions élémentaires   représente le quantum de temps minimum pendant lequel le processeur ne peut être stoppé. Les points d'arrêt sont donc les instants entre les instructions. Ils sont désignés sous le nom de point interruptible.

La commutation de contexte est liée à l'état d'un certain nombre d'indicateurs que le processeur doit consulter en chacun de ces points interruptibles. On distingue plusieurs mécanismes de commutation de contexte, suivant la signification de ces indicateurs :

• les interruptions extérieures à l'activité en cours qui sont la réaction du système d'exploitation à des événements asynchrones externes.
• un déroutement lié à l'exécution de l'instruction en cours : traitement d'une erreur ou situation exceptionnelle. Le processus est interrompu et un nouveau processus est chargé pour gérer la situation.
• un appel au superviseur lié à l'instruction en cours qui nécessite l'usage d'une fonction du système d'exploitation : traitement d'une entrée-sortie par exemple.

Les interruptions

Une interruption est un signal envoyé de façon asynchrone au processeur qui le force à suspendre l'activité en cours au profit d'une autre. La source peut être un autre processeur, un contrôleur d'entrées-sorties ou tout autre dispositif physique externe. Le programme en cours d'exécution suspend son activité au premier point interruptible. Le processeur exécute alors un programme prédéfini de traitement de l'interruption. Les causes d'interruption sont multiples. Il faut donc être capable de les distinguer et de les traiter chacune de façon spécifique. Pour cela on peut envisager diverses méthodes :

1. si l'indicateur d'interruption est unique, le code de l'interruption est stocké quelque part dans la mémoire et doit être lu par le programme de traitement.
2. s'il existe des indicateurs multiples, chacun est appelé niveau d'interruption. On attache un programme différent de traitement à chacun de ces niveaux.
3. on peut utiliser simultanément ces deux méthodes. Chaque niveau d'interruption est accompagné d'un code qui est lu par le programme de traitement de ce niveau. On distingue alors les interruptions matérielles qui sont les différents niveaux et les interruptions logicielles qui correspondent aux codes lus.

Chaque niveau d'interruption est affecté d'une priorité différente. En effet si deux niveaux étaient activés simultanément il se produirait un conflit. Le système d'exploitation le résout en traitant l'interruption la plus prioritaire. Ainsi l'activité qui a pour mission de contrôler la présence de la tension d'alimentation - elle n'existe pas dans toutes les machines - et de basculer le fonctionnement sur des batteries de sauvegarde doit être la plus prioritaire. Lorsqu'elle détecte une variation anormale de la tension, elle arrête immédiatement tout fonctionnement et commute l'alimentation électrique. Par convention le niveau de priorité le plus élevé est 0. La priorité décroît lorsque sa valeur augmente.

Lorsqu'on emploie une solution mixre (cas n°3) les niveaux d'interruption logiciels qui correspondent au même niveau matériel sont affectés de la même priorité. Les conflits possibles sont gérés en attachant à chaque niveau une file d'attente pour traiter successivement les causes d'interruptions. Nous en verrons un exemple avec le temps partagé.

On peut schématiser les différents niveaux d'interruptions comme dans le schéma ci-contre. La priorité va en décroissant du haut vers le bas.

 

Erreurs matérielles

Horloge

Requêtes disque

Requêtes réseau

Terminaux

Interruptions logicielles

Figure 2.2  Hiérarchie des interruptions

Un processus doit être protégée contre les interruptions moins prioritaires. On retarde donc volontairement la commutation de contexte jusqu'à ce que le processus le plus prioritaire  ait terminé son travail ou soit lui-même interrompu par un autre plus prioritaire. Ceci est réalisé grâce à un masque d'interruption attaché à chaque processus. En chaque point interruptible lorsqu'on consulte les valeurs des niveaux d'interruption activés,  ce masque cache les niveaux qui doivent être ignorés. Le masque fait partie du mot d'état. Il est lui-même modifiable par une interruption. Un niveau d'interruption peut être désarmé pour supprimer l'effet de l'arrivée d'un signal puis réarmé à la demande. Ce mécanisme est programmable. Ainsi lorsque le système d'exploitation masque les interruptions correspondant au disque, toutes les entrées-sorties sont inhibées qu'elles se fassent avec le disque, le réseau ou les terminaux. Bien entendu les interruptions logicielles déclenchées par les processus actifs le sont également puisque moins prioritaires. En général les unités centrales comportent deux lignes de requêtes d'interruptions : la première ne peut pas être masquée. Elle est réservée aux événements dits "non récupérables" comme les erreurs matérielles ainsi qu'à l'horloge qui doit absolument garder son cadencement. La deuxième ligne comprend tous les autres événements qui peuvent être interrompus avant toute séquence d'instructions critiques.

Le schéma de fonctionnement d'une interruption est indiqué dans la figure 2.3.

Les interruptions font partie de l'architecture d'un ordinateur. Leur conception diffère avec le constructeur mais elles obéissent toutes à des principes communs. Leur rôle est de transférer le traitement au programme approprié comme le schématise la figure 2.3. Pour gérer ce transfert on pourrait concevoir un programme unique qui examinerait une information liée à l'interruption puis qui, à son tour, appellerait un gestionnaire spécifique. Ceci n'est pas efficace car les interruptions doivent être traitées le plus rapidement possible et on peut faire l'économie de ce double appel en utilisant une table de pointeurs vers des programmes spécifiques de traitement. Cette table est stockée dans les adresses basses de la machine. On l'appelle vecteur d'interruptions. Le système d'exploitation doit savoir utiliser les informations contenues dans ce vecteur.

Déroutement, appels au superviseur

Les déroutements et les appels au superviseur sont déclenchés par une cause interne au programme en cours, à la différence des interruptions qui sont d'origine externe, autre processus ou par le matériel.

Le superviseur est un élément du système d'exploitation qui contrôle l'exécution des programmes et traite les déroutements (trap en anglais) et les interruptions.Un déroutement se produit, en particulier, lorsqu'un programme effectue une opération interdite, comme dans le cas de débordement de tableaux hors de la zone d'adresses allouée au programme, lorsque des données sont incorrectes, division par zéro par exemple, ou lorsque l'instruction ne correspond pas à un code exécutable. Les déroutements peuvent être supprimés. On peut ainsi autoriser la suite des opérations si l'erreur n'est pas trop grave: un arrondi à zéro peut être légitime et il serait stupide d'arrêter le calcul. Il ne peut pas être retardé: c'est un événement synchrone au programme en cours d'exécution pour lequel la notion de masque d'interruption ne s'applique pas. Ainsi, lorsqu'on décide de surveiller les arrondis à zéro (underflows), cela signifie que le déclenchement de l'interruption correspondante ne sera pas ignoré et déclenchera l'appel à une procédure qui signalera l'erreur et pourra même (cela dépend de la réalisation du système d'exploitation) la traiter ou terminer l'exécution du processus. La gestion des traps est très variable d'un système d'exploitation à l'autre. Ceci explique qu'un programme qui semble fonctionner correctement sur une machine se révèle erroné sur une autre. Les choix par défaut sont souvent mal documentés et cela peut amener bien des surprises. Une panne hardware peut aussi, surtout avec des machines sans code autocorrecteur comme les PCs, apparaître sous forme d'un déroutement. Lorsqu'une information est mal lue dans la mémoire et que ni l'électronique ni le système d'exploitation ne sont capables de le détecter, l'instruction ou la donnée erronée ont de fortes chances de déclencher une opération interdite donc un déroutement. C'est le cas des PCs fonctionnant sous Windows.Un appel au superviseur provoque toujours une commutation de contexte pour faire appel à la commande appropriée. C'est un événement tout à fait identique aux appels de procédures que nous avons étudié précedemment. Il déclenche des mécanismes de sécurité qui interdisent les opérations illicites afin de préserver l'intégrité du fonctionnement de la machine: tout appel n'est pas autorisé. Cela dépend du contexte.

Exemples de systèmes d'interruption

Le processeur Pentium possède 16 interruptions hardware (IRQ). Certaines sont réservées à des équipements spécifiques, d'autres sont libres. Certaines correspondent à des adresses réservées dans la mémoire où sont placés les programmes de traitement. Les systèmes d'exploitation doivent tenir compte de cela pour implémenter les fonctions de traitement. Ceci est fait dans le noyau du système. S'il arrivait qu'une application modifie le contenu de ces zones le fonctionnement de l'ordinateur s'en trouverait perturbé. Ceci se produit parfois lorsque les programmeurs, pour diverses raisons, ont voulu capter directement des causes d'interruptions mais cela est une mauvaise façon de programmer car d'une version à l'autre du système d'exploitation, l'implémentation du noyau peut varier et un programe qui fonctionnait dans une version précédente du système peut non seulement s'arrétert mais même bloquer l'ordinateur !

Le tableau suivant montre les affectations des interruptions du processeur Pentium :

Fonction	IRQ	Adresse	Commentaires
Horloge système	0
Clavier	1
Contrôleur d'IRQ programmable	2
Com 2 Com 4	3	2F8-2FF 2E8 - 2EF
Com 1 Com 3	4	3F8-3FF 3E8-3EF
Libre	5		Souvent utilisé par la carte son
Contrôleur lecteur de disquette	6
LPT 1 LPT 2	7	378 -37F (3C pour les produits de marque) 278 - 27F
Horloge : date et heure	8
	9		Souvent utilisé par la carte son
	10		Libre
	11		Libre
	12		Libre
Coprocesseur mathématique	13
	14		Souvent IDE 1
	15		Souvent IDE 2

Table 2.4 : Interruptions du processeur Pentium

Chaque interruption correspond à un élément matériel et ceci peut causer un problème lorsque deux cartes, mal configurées veulent employer la même IRQ.

La figure suivante montre la gestion des déroutements pour ce même processeur.

Numéro de vecteur	Usage
0	Division par zéro
1	Exception de déboguage
2	Coninuer
3	Point d'arrêt
4	Dépassement de capacité de registre interne
5	Dépassement de limite
6	Code d'opération non valide
7	Périphérique indisponible
8	Erreur sur nombre double précision
9	réservé : gestion coprocesseur
10	segment d'état de tâche invalide
11	segment absent
12	Erreur dans la pile
13	Erreur de protection
14	Défaut de page
15	réservé
16	Erreur dans nombre en virgule flottante
17	Contrôle alignement
18	Contrôle hardware
19 - 31	réservé
32 - 255	Interruptions masquables

Figure 2.5 : table des vecteurs d'interruption du processeur Pentium d'Intel.

Certains usages peuvent paraître à ce point du cours. Ils s'éclaircirons par la suite.

Exemples d'utilisation des interruptions

Simulation d'une instruction manquante

Les processeurs ne sont capavbles de traiter que des instructions qui portent sur les nombres entiers. Ils recourent à un coprocesseur mathématique pour travailler sur les nombres flottants, addition ou multiplication. Dans les processeurs anciens ou aujourd'hui dans les processeurs embarqués, ce coprocesseur n'existe pas. Une tentative d'exécution d'un code flottant déclenche une interruption qui est traitée en déroutant l'activité sur une procédure qui simule cette instruction. La procédure de simulation doit connaître l'adresse de retour dans le programme appelant. Il faut sauvegarder les mots d'état lors de cet appel. Cette procédure doit pouvoir traiter les erreurs éventuelles. Elle peut donc elle-même être déroutée.

Gestion des travaux en temps partagé

Considérons n programmes qui sont exécutés simultanément dans un ordinateur qui possède un seul processeur. Il ne peut exécuter qu'un seul processus à la fois. Le processeur est alloué successivement aux différents processus, par tranches de temps de durée fixe. Lorsqu'un processus a terminé son travail avant la fin de sa tranche de temps ou lorsque le processeur se trouve en attente d'un autre dispositif, pour une opération d'écriture par exemple, le moniteur d'enchaînement des travaux s'intéresse au processus suivant et lance son exécution. De cette façon chaque processus se voit garantir une tranche de temps du processeur et le moniteur de temps partagé veille à ce qu'aucun d'entre eux ne le monopolise. Ceci permet d'exploiter au mieux le processeur car il n'attend pas inutilement une ressource indisponible (fig. 2.5) et permet en même temps à chaque processus d'avancer de façon égale.

figure 2.5 Partage du temps entre activités

Ce mode de fonctionnement est employé pour les processus des utilisateurs qui sont moins prioritaires que la plupart de ceux du système. C'est une façon de gérer, sur un même niveau de priorité hardware un ensemble de processus.

Unix possède un moniteur de temps partagé car il est conçu pour plusieurs utilisateurs simultanés. Même lorsque la machine est employée par une seule personne le moniteur de temps partagé continue à être utilisé pour répartir le temps du processuer entre les différents processus lancés par cette personne. Ce moniteur n'existe pas dans Windows, ce qui explique pourquoi certains processus, très gourmands en ressources, peuvent pratiquement geler la machine. Les utilisateurs de Photoshop ou de programmes de montage vidéo connaissent bien ce problème !

On alloue à chaque processus des zones de mémoire pour ranger son mot d'état ainsi que celui du processeur qui lui correspond. Le moniteur de temps partagé est plus prioritaire que toutes les taches qu'il doit gérer car il peut les interrompre alors que l'inverse n'est pas vrai. Il sauve le contexte du processus en cours et charge celui du suivant. Il arme une horloge qui déclenche à nouveau une interruption lorsque le temps alloué à ce dernier processus est à son tour écoulé.

Un ordinateur possède donc des niveaux d'interruption matériels et logiciels. Ils sont indispensables au fonctionnement de plusieurs activités en parallèle mais c'est le système d'exploitation qui les utilise. Selon la sophistication de ce dernier les possibilités seront différentes,assez pauvres pour un processeur Pentium travaillant sous Windows, infiniment plus grandes pour le même ordinateur utilisant un système Unix. Encore une fois rappelons que les possibilités de programmation des interruptions dépendent essentiellement du système d'exploitation. Elles sont difficilement programmables sous DOS: un Pentium ou un vieux 80286 sont totalement similaires, de ce point de vue, alors que le premier est un processeur très sophistiqué.

---

Copyright Yves Epelboin, université P.M. Curie, 2000, MAJ 4 avril, 2005