Cours Methodes de Programmations

Nombre de pages : 171
Mise à jours 28 janvier 2001 Révision : 2.690
Ce document peut être téléchargé à son dernier indice à l’adresse suivante: http://coursducnam.free.fr/
Pour tous commentaires sur ce support de cours contacter nous sur : coursducnam@free.fr
CONSERVATOIRE NATIONNAL DES ARTS ET METIERS Année 2000-2001
Il est autorisé de copier, distribuer et/ou modifier ce document

suivant les termes de la Licence de Documentation Libre GNU (GNU Free Documentation License)
Version 1.1 ou plus récente de la Fondation de logiciel libre (Free Software Foundation) ;
avec les sections invariantes qui sont listée avec leurs titres,
et avec les textes des pages de garde et pages de fin de ce document.
Une copie de cette licence est inclue dans ce document à la section "GNU
Free Documentation License".
Pour plus d’informations, consulter l’adresse : http://www/gnu.org/copyleft/fdl.html
METHODES DE PROGRAMMATIONS Page 2

Table de mises à jours
Version Date Commentaires

1 30/09/2000 Edition originale
2 28/01/2001 Mise à jours des travaux dirigés
METHODES DE PROGRAMMATIONS Table de mises à jours Page 3

Sommaire
1. COURS : INTRODUCTION AUX METHODES DE

PROGRAMMATION ..........................................................................................................................9
1.1. / PRESENTATION GENERALE..............................................................................................................................10
1.1.1. / INTRODUCTION............................................................................................................................................10
1.1.2. / LE ROLE D’UN SYSTEME D’EXPLOITATION ..............................................................................................11
1.1.3. / LES FONCTIONS D’UN SYSTEME D’EXPLOITATION .................................................................................12
1.1.4. / HISTORIQUE .................................................................................................................................................13
1.1.4.1. / Première génération (1945-1955) tubes à vides et panneaux de raccordement...........................................13
1.1.4.2. / Deuxième génération (1955-1965) Transistors et systèmes par lots ..........................................................14
1.1.4.3. / Troisième génération (1965-1980) Circuits intégrés et multiprogrammation ............................................16
1.1.4.4. / Quatrième génération (1980-1990) Ordinateurs personnels......................................................................18
1.1.4.5. / Génération multimédia (1990-à nos jours)................................................................................................20
1.1.5. / LES DIVERS TYPES DE SYSTEMES D’EXPLOITATION MULTITACHE.......................................................24
1.1.5.1. / Les systèmes multitâche monoprocesseur .................................................................................................24
1.1.5.2. / Les systèmes multi-utilisateur ..................................................................................................................25
1.1.5.3. / Les systèmes temps-réel ...........................................................................................................................26
1.1.5.4. / Les systèmes transactionnels....................................................................................................................28
1.1.5.5. / Les systèmes multitraitement ...................................................................................................................29
1.1.6. / STRUCTURE GENERALE D’UN SYSTEME D’EXPLOITATION....................................................................30
1.1.6.1. / Le noyau..................................................................................................................................................30
1.1.6.2. / Le gestionnaire de tâches .........................................................................................................................31
1.1.6.3. / Le gestionnaire de mémoire .....................................................................................................................31
1.1.6.4. / La gestion des entrées-sorties...................................................................................................................31
1.1.6.5. / La gestion des fichiers .............................................................................................................................32
1.1.6.6. / Le dialogue homme-machine ...................................................................................................................33
1.1.7. / CONCLUSION................................................................................................................................................33
1.2. / LA GESTION DES TACHES.................................................................................................................................34
1.2.1. / INTRODUCTION............................................................................................................................................34
1.2.2. / NOTION DE TACHE ......................................................................................................................................34
1.2.3. / STRUCTURER UNE APPLICATION EN TACHES..........................................................................................35
1.2.4. / LES ETATS D’UNE TACHE............................................................................................................................37
1.2.4.1. / L’état ACTIF...........................................................................................................................................37
1.2.4.2. / L’état PRET.............................................................................................................................................38
1.2.4.3. / L’état EN ATTENTE ..............................................................................................................................38
1.2.4.4. / L’état SUSPENDU ..................................................................................................................................38
1.2.5. / CHANGEMENT D’ETAT D’UNE TACHE ......................................................................................................39
1.2.5.1. / Création et destruction.............................................................................................................................39
1.2.5.2. / La préhension ..........................................................................................................................................40
1.2.5.3. / L’endormissement ...................................................................................................................................40
1.2.5.4. / La suspension ..........................................................................................................................................40
1.2.5.5. / Le réveil ..................................................................................................................................................41
1.2.5.6. / La résomption..........................................................................................................................................41
1.2.5.7. / Notion de contexte ...................................................................................................................................41
1.2.6. / LES LISTES ASSOCIEES AUX ETATS............................................................................................................42
1.2.7. / STRUCTURE DES DONNEES ASSOCIEES AUX TACHES ............................................................................43
1.2.7.1. / La pile .....................................................................................................................................................43
1.2.7.2. / Le descripteur de tâche ............................................................................................................................44
1.2.8. / TRAITEMENT DU TEMPS .............................................................................................................................45
METHODES DE PROGRAMMATIONS SOMMAIRE Page 4

1.2.8.1. / Les interruptions d’horloge interne ..........................................................................................................45

1.2.8.2. / L’horloge temps réel................................................................................................................................46
1.2.8.3. / Traitement des attentes ............................................................................................................................46
1.2.9. / ALLOCATION DU PROCESSEUR..................................................................................................................49
1.2.9.1. / Objectifs de l’allocation ...........................................................................................................................49
1.2.9.2. / Critères d’allocation ................................................................................................................................50
1.2.9.3. / Les priorités.............................................................................................................................................51
1.2.10. / MECANISMES D’ORDONNANCEMENT .......................................................................................................51
1.2.10.1. / Algorithmes sans réquisition....................................................................................................................52
1.2.10.1.1. / Ordonnancement par ordre d’arrivée (FIFO) ......................................................................................52
1.2.10.1.2. / Ordonnancement « Plus court d’abord»..............................................................................................53
1.2.10.2. / Algorithmes avec réquisition ...................................................................................................................53
1.2.10.2.1. / Ordonnancement « Plus court temps restant » ....................................................................................53
1.2.10.2.2. / Le tourniquet......................................................................................................................................54
1.2.10.2.3. / Ordonnancement par priorité .............................................................................................................55
1.2.10.2.4. / Ordonnancement par files multiples ...................................................................................................56
1.2.10.2.4.1. / Les files prioritaires.....................................................................................................................56
1.2.10.2.4.2. / Les files rétroactives ....................................................................................................................57
1.2.11. / LES PROCEDURES DE GESTION DE TACHES............................................................................................58
1.2.11.1. / Les procédures de base.............................................................................................................................58
1.2.11.2. / Les procédures de haut niveau .................................................................................................................59
1.3. / LA GESTION DES INTERRUPTIONS ..................................................................................................................62
1.3.1. / INTRODUCTION............................................................................................................................................62
1.3.2. / NOTION D’INTERRUPTION..........................................................................................................................62
1.3.3. / DIFFERENTES CAUSES D’INTERRUPTION ................................................................................................63
1.3.3.1. / Les interruptions internes ........................................................................................................................63
1.3.3.2. / Les interruptions externes ........................................................................................................................64
1.3.4. / MODE SYSTEME ET MODE UTILISATEUR..................................................................................................64
1.3.5. / LE MECANISME D’INTERRUPTION.............................................................................................................65
1.3.5.1. / Le masquage des interruptions.................................................................................................................67
1.3.5.2. / Reconnaissance d’une interruption...........................................................................................................69
1.3.5.3. / Identification de la source ........................................................................................................................69
1.3.5.3.1. / Identification directe ............................................................................................................................70
1.3.5.3.2. / Identification par scrutation .................................................................................................................70
1.3.5.3.3. / Reprise de la tâche interrompue ...........................................................................................................70
1.3.6. / NOTION DE NIVEAU D'INTERRUPTION......................................................................................................71
1.3.6.1. / Niveau unique à priorité unique ...............................................................................................................72
1.3.6.2. / Niveau unique à priorités multiples..........................................................................................................72
1.3.6.3. / Niveaux multiples à priorités multiples ....................................................................................................73
1.3.6.3.1. / Systèmes à une ligne d’interruption......................................................................................................74
1.3.6.3.2. / Systèmes à lignes d’interruption multiples............................................................................................75
1.3.6.3.3. / Notion de contrôleur d’interruption......................................................................................................76
1.3.7. / TRAITEMENT DES INTERRUPTIONS INTERNES.........................................................................................77
1.3.7.1. / Les appels au superviseur.........................................................................................................................77
1.3.7.2. / Les déroutements .....................................................................................................................................78
1.4. / LA GESTION DU PARALLÉLISME ET DE LA COOPÉRATION ENTRE LES TÂCHES...................................79
1.4.1. / INTRODUCTION............................................................................................................................................79
1.4.2. / L’EXCLUSION MUTUELLE...........................................................................................................................79
1.4.2.1. / Le mécanisme d’attente active .................................................................................................................82
1.4.2.2. / Le Sémaphore..........................................................................................................................................83
1.4.3. / SYNCHRONISATION ENTRE TACHES ..........................................................................................................85
1.4.3.1. / Mécanisme d’action directe .....................................................................................................................86
1.4.3.2. / Mécanismes d'action indirecte .................................................................................................................87
1.4.3.3. / Synchronisation par événements ..............................................................................................................88
1.4.3.4. / Synchronisation par sémaphores ..............................................................................................................88
1.4.4. / LA COMMUNICATION ENTRE TACHES.......................................................................................................91
1.4.4.1. / Communication par variables communes .................................................................................................91
1.4.4.2. / Communication par boîtes aux lettres ......................................................................................................92

1.4.4.3. / Communication par Rendez-vous.............................................................................................................95

1.5. / LA GESTION DE LA MÉMOIRE..........................................................................................................................97
1.5.1. / INTRODUCTION............................................................................................................................................97
1.5.2. / HIERARCHIE DES MEMOIRES.....................................................................................................................98
1.5.2.1. / Les registres.............................................................................................................................................98
1.5.2.2. / La mémoire cache....................................................................................................................................98
1.5.2.3. / La mémoire centrale ................................................................................................................................98
1.5.2.4. / La mémoire d’arrière-plan .......................................................................................................................98
1.5.2.5. / La mémoire de masse...............................................................................................................................99
1.5.3. / ESPACE PHYSIQUE ET ESPACE VIRTUEL ..................................................................................................99
1.5.3.1. / Espace physique supérieur à l’espace virtuel.............................................................................................99
1.5.3.2. / Espace physique inférieur à l’espace virtuel............................................................................................101
1.5.4. / LES FONCTIONS DE BASE .........................................................................................................................101
1.5.4.1. / Transformation adresses logiques / adresses physiques...........................................................................101
1.5.4.2. / Partage de la mémoire physique.............................................................................................................102
1.5.4.3. / Allocation de la mémoire.......................................................................................................................102
1.5.4.3.1. / Allocation statique .............................................................................................................................102
1.5.4.3.2. / Allocation dynamique ........................................................................................................................102
1.5.4.4. / La protection .........................................................................................................................................103
1.5.4.5. / Extension de l’espace mémoire ..............................................................................................................103
1.5.4.5.1. / Technique de l’overlay.......................................................................................................................104
1.5.4.5.2. / Technique du chaining (ou pagination manuelle) ...............................................................................104
1.5.4.5.3. / Technique du swapping......................................................................................................................104
1.5.5. / LA MEMOIRE VIRTUELLE..........................................................................................................................104
1.5.5.1. / Les informations accessibles à une tâche................................................................................................105
1.5.5.2. / Organisation de la mémoire virtuelle .....................................................................................................106
1.5.5.2.1. / Mémoire virtuelle linéaire..................................................................................................................106
1.5.5.2.2. / Mémoire virtuelle segmentée..............................................................................................................106
1.5.5.3. / La segmentation ....................................................................................................................................106
1.5.5.3.1. / La table des segments.........................................................................................................................107
1.5.5.3.2. / Adressage d’une mémoire virtuelle segmentée ...................................................................................109
1.5.5.3.3. / Traitement d’un défaut de segment ....................................................................................................110
1.5.5.4. / La pagination.........................................................................................................................................110
1.5.5.4.1. La table des pages ................................................................................................................................111
1.5.5.4.2. / Adressage d’une mémoire virtuelle paginée .......................................................................................112
1.5.5.4.3. / Traitement d’un défaut de page..........................................................................................................113
1.5.5.4.4. / Notion d’espace de travail ..................................................................................................................113
1.5.5.5. / Segmentation paginée............................................................................................................................114
1.5.5.5.1. / Association des tables des segments et des tables des pages ................................................................114
1.5.5.5.2. / Adressage d’une mémoire segmentée et paginée ................................................................................115
1.5.5.6. / Algorithmes de remplacement ...............................................................................................................116
1.5.5.6.1. / Algorithme aléatoire (random)...........................................................................................................116
1.5.5.6.2. / Algorithme PEPS...............................................................................................................................117
1.5.5.6.3. / Algorithme MRU ...............................................................................................................................117
1.5.5.6.4. / Algorithme MFU ...............................................................................................................................117
1.6. / LA GESTION DES ENTRÉES/SORTIES ............................................................................................................118
1.6.1. / INTRODUCTION..........................................................................................................................................118
1.6.2. / ORGANISATION GENERALE DES ENTREES/SORTIES..............................................................................118
1.6.2.1. / Les périphériques d’entrées-sorties ........................................................................................................119
1.6.2.2. / Les interfaces.........................................................................................................................................119
1.6.2.2.1. / Les instructions spéciales ...................................................................................................................119
1.6.2.2.2. / La cartographie mémoire ...................................................................................................................120
1.6.2.2.3. / Les entrées-sorties contrôlées par interruptions ..................................................................................120
1.6.2.3. / Les contrôleurs de périphériques............................................................................................................120
1.6.2.3.1. / L’accès direct à la mémoire................................................................................................................122
1.6.2.3.2. / Programmation d’un contrôleur .........................................................................................................123
1.6.2.4. / Les canaux d’entrées-sorties ..................................................................................................................124
1.6.2.4.1. / Le sélecteur........................................................................................................................................125

1.6.2.4.2. / Le multiplexeur par octet ...................................................................................................................126

1.6.2.4.3. / Le multiplexeur par bloc ....................................................................................................................127
1.6.2.4.4. / Programmation d’un canal .................................................................................................................127
1.6.3. / PILOTAGE DES PERIPHERIQUES..............................................................................................................128
1.6.3.1. / Notion de conducteur de périphérique....................................................................................................128
1.6.3.2. / Pilotage d 'entrées-sorties synchrones.....................................................................................................130
1.6.3.3. / Pilotage d’entrées-sorties asynchrones ...................................................................................................132
1.6.4. / PRINCIPE DU GESTIONNAIRE D’ENTREES/SORTIES..............................................................................134
1.6.4.1. / Structure du gestionnaire d’entrées/sorties .............................................................................................135
1.6.4.2. / Le LIOCS ..............................................................................................................................................135
1.6.4.3. / Le PIOCS ..............................................................................................................................................136
1.6.4.4. / Le gestionnaire de tampons....................................................................................................................136
1.6.4.4.1. / Le double tampon...............................................................................................................................136
1.6.4.4.2. / Le tampon circulaire ..........................................................................................................................137
1.6.4.4.3. / Le pool de tampons ............................................................................................................................138
1.6.5. / PRISE EN CHARGE DES ENTREES/SORTIES PAR LE SYSTEME ..............................................................139
1.6.5.1. / Les routines de services des entrées/sorties.............................................................................................139
1.6.5.2. / Structure de données associées aux entrées/sorties..................................................................................139
1.6.6. / MECANISMES D’EXECUTION DE REQUETES D’ENTREES/SORTIES .....................................................141
2. TRAVAUX DIRIGES ..................................................................................143
2.1. / EXERCICE 1 : LA GESTION DES LISTES DE TACHES D’UN SYSTEME TR........................................................................144

2.1.1. / Enoncé..........................................................................................................................................................144
2.1.2. / Solutions .......................................................................................................................................................144
2.1.2.1. / La procédure S’ENDORMIR .................................................................................................................144
2.1.2.2. / La procédure ENDORMIR.....................................................................................................................145
2.1.2.3. / La procédure SUSPENDRE ...................................................................................................................146
2.1.2.4. / La procédure DESSUSPENDRE ............................................................................................................147
2.2. / EXERCICE 2 : LA GESTION DE L’INTERRUPTION DE L’HORLOGE TR ...........................................................................148
2.2.1. / Enoncé..........................................................................................................................................................148
2.2.2. / Solutions .......................................................................................................................................................148
2.3. / EXERCICE 3 : ORDONNANCEMENT DE TACHES DANS UN SYSTEME TR .......................................................................150
2.3.1. / Enoncé..........................................................................................................................................................150
2.3.2. / Solutions .......................................................................................................................................................151
2.4. / EXERCICE 4 : ADRESSAGE D’UNE MEMOIRE VIRTUELLE PAGINEE ..............................................................................158
2.4.1. / Enoncé..........................................................................................................................................................158
2.4.2. / Solutions .......................................................................................................................................................158
2.5. / EXERCICE 5 : ADRESSAGE D’UNE MEMOIRE VIRTUELLE SEGMENTEE ET PAGINEE .......................................................159
2.5.1. / Enoncé..........................................................................................................................................................159
2.5.2. / Solutions .......................................................................................................................................................159
2.6. / EXERCICE 6 : GESTION D’UNE MEMOIRE VIRTUELLE PAGINEE ...................................................................................160
2.6.1. / Enoncé..........................................................................................................................................................160
2.6.2. / Solutions .......................................................................................................................................................160
2.7. / EXERCICE 7 : GESTION D’UNE MEMOIRE VIRTUELLE ET DEFAUTS DE PAGES ...............................................................161
2.7.1. / Enoncé..........................................................................................................................................................161
2.7.2. / Solutions .......................................................................................................................................................161
2.8. / EXERCICE 8 : TEMPS D’EXECUTION D’UNE INSTRUCTION ET DEFAUT DE PAGE............................................................162
2.8.1. / Enoncé..........................................................................................................................................................162
2.8.2. / Solutions .......................................................................................................................................................162
2.9. / EXERCICE 9 : TEMPS D’EXECUTION D’UNE INSTRUCTION ET HEURE D’ARRIVEE..........................................................162
2.9.1. / Enoncé..........................................................................................................................................................162
2.9.2. / Solutions .......................................................................................................................................................162
3. INDEX ................................................................................................................................................164

4. LEXIQUE ..................................................................................................................................168
5. LICENCE DE DOCUMENTATION LIBRE ..............................................................................................................170

1. COURS : Introduction aux méthodes de

programmation
METHODES DE PROGRAMMATIONS COURS Page 9

1.1. / PRESENTATION GENERALE

1.1.1. / INTRODUCTION
Un ordinateur est caractérisé par une structure matérielle qui définit ses possibilités et ses limites
physiques. L’exploitation plus ou moins heureuse des potentialités offertes par l’architecture matérielle
du système en vue d’effectuer un travail donné, dépend des programmes mis en oeuvre par l’ordinateur.
Sans programme, un ordinateur n’est qu’un ensemble d’équipements matériels inutilisables. L’efficacité
globale d’un système dépend donc tout autant du matériel que du logiciel. Le logiciel (software) peut
être sommairement décomposé en deux classes :
· Les programmes d’application: écrits par le ou les utilisateurs pour apporter une solution à un
problème donné (contrôle-commande de procédés industriels, gestion de systèmes bancaires,
réservations de places dans un avion ou un train, jeux...)
· Les programmes systèmes : développés par le constructeur de l’ordinateur ou le concepteur du

système pour, d’une part, aider l’utilisateur dans sa démarche de programmation et lui apporter
les outils de développement dont il a besoin et d’autre part tirer le maximum de bénéfice des
possibilités de l’ordinateur. Le système d’exploitation (O.S. . Operating Svstem) est le plus
important de tous ces programmes systèmes. C’est lui qui contrôle toutes les ressources de la
machine et qui fournit les éléments de base permettant l’écriture des programmes d’application.
Du point de vue de l’utilisateur, le système d’exploitation fournit l’environnement destiné à faciliter le

développement des programmes et leur exécution. A ce titre, il met à la disposition des usagers toute
une série de logiciels (éditeurs, compilateurs, assembleurs...) qui permettent d’assembler, de charger et
d’exécuter les programmes d’application. De plus, Il fournit à l’utilisateur toute une série de commandes
simples qui lui permettent de traiter les opérations d’entrée-sortie et la gestion de l’information d’une
façon logique, sans entrer au niveau du détail de l’implantation.
Du point de vue du concepteur du système, le système d’exploitation contrôle et alloue les ressources
matérielles et logicielles de l’ordinateur, telles que le processeur, la mémoire centrale, les périphériques
ou les programmes systèmes. Les systèmes d’exploitation possèdent chacun une spécificité qui les rende
plus ou moins faciles à utiliser, plus ou moins efficaces aussi. Cependant, ils sont tous basés sur des
concepts et des techniques communs.
Le but de ce cours est d’abord de donner les principes sur lesquels sont fondés tous les systèmes
d’exploitation et de montrer très vite à l’utilisateur que le système d’exploitation travaille pour lui. En
effet, les programmes réalisés s’exécutent sur une sorte de machine virtuelle et toutes les
caractéristiques de son matériel sont cachés. Il en résulte un plus grand confort de programmation, une
plus grande rapidité de mise au point et une plus grande transportabilité des logiciels devenant alors
indépendants des machines réelles.

1.1.2. / LE ROLE D’UN SYSTEME D’EXPLOITATION
Dans un système informatique la place du système d’exploitation est dans la plupart des cas présentée
par référence à un ensemble de niveaux ou de couches, tel que sur la figure 1.1. Aux extrémités hautes
et basses de cette figure sont situés respectivement l’utilisateur (ou les utilisateurs) et la machine (ou les
machines).
Le système d’exploitation apparaît alors comme constituant la charnière entre le logiciel et le matériel.
Son rôle consiste à gérer au mieux l’utilisation des ressources matérielles dont le logiciel va disposer
processeur(s), mémoire(s), entrées-sorties... Pour cela il doit constituer une interface entre les
ressources physiques et l’utilisateur en fournissant à ce dernier un langage de commande (avec
interpréteur associé) plus ou moins complexe (graphique ou textuel) et des programmes utilitaires.
Ainsi, l’utilisateur voit une machine virtuelle standard plus facile à utiliser que la machine réelle. Cette
machine virtuelle le décharge de la connaissance des caractéristiques exactes de l’architecture matérielle
sur lequel ses programmes d’application vont fonctionner ou encore des caractéristiques physiques des
périphériques annexes (disques, bandes magnétiques, imprimantes, scanners...).
Figure 1.1 Découpage en niveau d’un système informatique
Cette notion de machine virtuelle évite que les opérations imposées par la machine accaparent
l’utilisateur au détriment du vrai problème et de sa solution. Les systèmes d’exploitation ont donc
plusieurs motivations et objectifs :
· Réduire et dominer la complexité des machines,
· Paire en sorte que les possibilités de la machine soient utilisées au mieux.

· Préserver les investissements,
· Faciliter le travail des utilisateurs et leur permettant, par exemple, de spécifier et d’obtenir des
solutions sans référence à des considérations reliées à la machine...
1.1.3. / LES FONCTIONS D’UN SYSTEME D’EXPLOITATION
Les fonctions couvertes par un système d’exploitation peuvent varier considérablement selon les
objectifs visés par le constructeur et l’importance de l’ordinateur, mais d’une manière générale, les
principales d’entre elles sont les suivantes:
- Gestion et ordonnancement des tâches,
- Communication et synchronisation,
- Gestion de la mémoire centrale,
- Gestion des interruptions,
- Gestion des périphériques,
- Gestion des fichiers,
- Traitement des erreurs et reprise,
- Gestion des programmes,
- Gestion des travaux,
- Gestion du temps,
- Programmes utilitaires.
Les algorithmes mis en oeuvre pour réaliser ces différentes fonctions varient beaucoup d’un système à
l’autre selon les objectifs visés et ils peuvent être par exemple très différents selon que le concepteur
cherche avant tout une utilisation optimum des ressources ou, au contraire, un temps de réponse
minimum. D’une manière générale, l’implantation de toutes ces fonctions conduit à des logiciels très
complexes qui doivent nécessairement être structurés pour pouvoir être maîtrisés.

1.1.4. / HISTORIQUE
L’informatique n’existe que depuis la deuxième guerre mondiale. En fait, les différents composants d’un
ordinateur sont arrivés avec une série de prototypes. On peut rappeler que les machines à calculer ont
leurs origines dans des travaux tels que ceux de Schickard en 1623, Blaise Pascal en 1643, Leibniz en
1673 et plus récemment ceux de Babbage en 1833. Les systèmes informatiques ont considérablement
évolué à travers les années. Les systèmes d’exploitation étant très liés aux machines qu’ils exploitent,
nous pouvons les classer par génération de la même manière que le sont les ordinateurs
1.1.4.1./ Première génération (1945-1955) tubes à vides et panneaux de raccordement
Au milieu des années 1940, un groupe de personnes composé entre autres de John von Neumann à
l’Université de Princeton, J. Presper Eckert et William Mauchley de l’Université de Pennsylvanie et
Konrad Zuse en Allemagne, a réussit à construire le premier calculateur électronique, appelé ENIAC
(Electronie Numerical Integrator And Computer). L’ENIAC pouvait effectuer 5000 additions ou 350
multiplications par seconde. Sa mémoire était de 20 mots de 10 chiffres décimaux. Cette machine, bien
que beaucoup moins puissante que la plupart des calculettes programmables de poche, pesait près de 30
tonnes, occupait une surface au sol de 160 m², consommait 175 kW/h et comprenait près de 20000
tubes à vide.
Les systèmes d’exploitation et les langages de programmation n’existaient pas encore (pas même les
langages assembleurs). Toute programmation était Laite en langage machine par le câblage, en enfichant
des prises du type «jack », d’un tableau de connexion (plugboard) qui commandait directement les
fonctions de base de la machine. Le mode d’utilisation de la machine consistait alors pour un
programmeur à venir s’inscrire sur une feuille de réservation de la machine pour une heure donnée et
pour un temps limité. Puis, à venir à l’heure prévue dans la salle machine insérer son tableau de
connexion dans le calculateur et enfin à attendre, quelques heures, les résultats du calcul en espérant
qu’aucune des 20000 tubes à vide ne grillerait pendant l’exécution du travail Au début des années 1950,
les cartes perforées (punched cards) pour l’introduction des programmes ont remplacé les tableaux de
connexion. Néanmoins la procédure d’utilisation du calculateur était la même.
IBM (International Business Machine corporation) réclame la paternité du premier «vrai » ordinateur
avec le SSEC qui fut livré en 1948 par F. Hamilton et R. Sheeber. C’était la première machine
électronique avec programme enregistré. En 1949, en Angleterre, M.H. Newman, F.C. Williams, T.
Kilburn et I.J. Good sortirent la machine de Manchester (MADM) qui intégrait des mémoires de 128
mots de 40 bits, à tubes électrostatiques, un tambour de 1024 mots et disposait d’un jeu de 26
instructions de 20 bits. Toujours en Angleterre, A. Turing travailla pendant la deuxième guerre
mondiale sur la machine ACE sortie en 1950, commercialisée en 50 exemplaires (de 1955 à 1964) sous
le nom de DEUCE et dont le détail est toujours resté secret.

Le premier ordinateur Français, le CUBA fut livré en 1952 à l’armée par le SEA. La société des
machines BULL travailla aussi sur la conception de machine informatique dès 1950 et sortit en 1958 le
BULL GAMMA ET qui avait une mémoire principale de 96 lignes à retard, de 12 chiffres décimaux
chacune et d’un tambour de 8 Kmots.
Cependant, la transition entre cette génération de prototypes et celle des premières machines
commercialisées a été vraiment réalisée par deux grands projets américains : le WHIRLWIND et le
JAS:
· Le « Whirlwind », machine très innovatrice, fut à l’origine de Il grandes « premières dont les
mémoires à tores (2048 mots de 16 bits), une ébauche de langage de programmation, des
utilitaires... Très rapide pour l’époque (elle exécutait jusqu’à 20000 instructions par secondes).
elle fit partie du système de défense de l’armée américaine dès 1951.
· Le «IAS » a une importance historique en tant que concrétisation des idées publiées par Von
Neumann. Mis au point en 1951, elle ne fut exploitée qu’en 1952 avec une mémoire,
considérée à l’époque comme considérable, de 4096 mots de 40 bits.
Ainsi, le premier ordinateur, le FERRANTI MARK 1, successeur de la machine de Manchester, fut

commercialisé, dès 1951. Puis en 1952, J.P. Eckert et W. Mauchley sortirent le successeur de l’ENIAC
: UNIVAC-1. Un an plus tard IBM sortit l’IBM 650 qui fut le premier ordinateur vendu en plus de
1000 exemplaires, et la série IBM 701, 702, 709...
1.1.4.2./ Deuxième génération (1955-1965) Transistors et systèmes par lots
L’introduction des transistors au milieu des années 1950 changea radicalement l’image des ordinateurs
qui devinrent suffisamment fiables et sûrs pour être fabriqués et vendus en grande quantité. Pour la
première fois, il y eut une séparation nette entre concepteurs, fabricants, programmeurs, opérateurs et
mainteneurs. Ces calculateurs étaient enfermés dans des pièces climatisées et utilisés par des personnels
hautement qualifiés. Seules des grandes compagnies d’état ou de grandes universités pouvaient s’offrir
ces ordinateurs qui coûtaient plusieurs millions de dollars.
A cette époque (entre 1956 et 1958), une équipe d’IBM, créa le premier langage de programmation le
FORTRAN, acronyme de FORmula TRANslation. Il était au départ destiné à la traduction de formules
mathématiques et est devenu le langage de base des utilisateurs numériciens. En dépit de ses lacunes
évidentes, sa position historique fait qu’il demeure un des langages principaux aujourd’hui.
Pour exécuter un travail (job) (un programme ou un ensemble de programmes), un programmeur devait
d’abord écrire le programme sur papier (en langage FORTRAN ou assembleur), puis le transcrire sur
cartes perforées. Il devait ensuite amener le jeu de cartes perforées dans la pièce des entrées de la
machine (input room) et le remettre à un opérateur. Une fois le travail terminé, les résultats produits par
le calcul étaient imprimés. Un opérateur récupérait les listings sur l’imprimante et les déposait dans la
pièce des sorties de la machine (output room) où les programmeurs pouvaient venir les récolter. Si le
compilateur FORTRAN était nécessaire, un opérateur était chargé de l’introduire dans le calculateur.
Enormément de temps était perdu pendant l’exécution de toutes ses opérations. Etant donné le coût de
ce type d’équipement, les constructeurs ont rapidement tenté de réduire la perte de temps.

Figure 1.2 : Principe du traitement par lots
La solution généralement adoptée est le traitement par lots (batch system). L’idée de départ consistait à
collecter un maximum de travaux sur cartes perforées dans la salle des entrées de la machine et à les
transférer sur une bande magnétique (tape). Cette opération était réalisée par un ordinateur (type « IBM
1401 ») moins cher que l’ordinateur central (type « IBM 7094 ») et spécialisé dans la lecture de cartes,
la copie sur bandes magnétiques et l’impression à partir de ces bandes (cf. figure 1.2). Après avoir
collecté un lot suffisant de travaux, la bande était rembobinée et amenée sur l’ordinateur central où elle
était montée sur un lecteur de bandes (tape drive). Un opérateur chargeait alors un programme spécial,
ancêtre des systèmes d’exploitation actuels, qui lisait le premier travail enregistré sur la bande et
l’exécutait. Après chaque fin de travail, le système d’exploitation lisait automatiquement le travail
suivant stocke sur la bande d’entrée et commençait son exécution. En sortie les résultats étaient stockés
sur une autre bande magnétique. Quand le lot complet avait été traité, l’opérateur enlevait les bandes
d’entrée et de sortie pour charger les bandes du lot suivant. La bande de sortie était alors amenée sur
une machine du type « IBM 1401 » qui se chargeait de l’impression des résultats hors-ligne (sans
aucune connexion au calculateur central).
Figure 1.3: Principe du traitement par lot
Par conséquent, un système « batch » était un système monotâche (single task system) qui ne pouvait
exécuter qu’un seul programme quels que soient sa taille et son temps d’exécution. Le programme en
cours de traitement accaparait donc complètement la machine pendant toute la durée de son exécution.
Les programmes étaient traités en séquence (cf. figure 1.3). Les utilisateurs travaillant avec ces
systèmes n’avaient aucune possibilité d’interaction avec leur programme qui se déroulait d’une manière
autonome, avec un temps de réponse imprévisible puisqu’il dépendait du nombre de travaux soumis.

1.1.4.3./ Troisième génération (1965-1980) Circuits intégrés et multiprogrammation
Au début des années 1960, la plupart des constructeurs d’ordinateurs avaient mis en oeuvre de deux
types de lignes de fabrication d’ordinateurs totalement distinctes l’une de l’autre et, de surcroît,
incompatibles
. Les lignes de fabrication et de montage des calculateurs scientifiques, tels que les « IBM 7094 »,
très largement utilisés pour le calcul numérique en science et en ingénierie.
. Les lignes de fabrication et de montage des calculateurs à caractère commercial, tels que les «
IBM 1401 », qui étaient très largement utilisés résultats par les banques et les compagnies
d’assurances pour le stockage et le tri de bandes magnétiques, et pour la gestion des impressions.
Ils ont été très rapidement confrontés au problème du coût très élevé du développement et du maintient
de deux lignes de production. De plus, un grand nombre de leurs clients qui, dans un premier temps,
n’avaient besoin que de petites machines se sont très vite développés et ont voulu alors s’équiper de
machines plus performantes sur lesquelles leurs anciens programmes devaient pouvoir être plus
rapidement exécutés. IBM tenta alors de résoudre ces problèmes par l’introduction sur le marché du
système 360. Le « 360 » était une série de machines composées d’un ensemble compatible logiciel-
matériel et pouvant intégrer les possibilités qu’offraient les IBM 1401 et IBM 7094. Les machines de
cette nouvelle gamme étaient toutes construites suivant la même architecture et disposaient toutes du
même jeu d’instructions ce qui permettait à un programme d’être exécuté sur n’importe laquelle d’entre
elles. Les machines de la série « 360» étaient les premières à utiliser des circuits imprimés (ICs), offrant
ainsi un grand avantage prix/performance par rapport aux machines de deuxième génération. Ce fut un
succès immédiat et l’idée fut reprise par la grande majorité des constructeurs. Depuis, IBM a développé
de nombreux successeurs au système « 360 » tels que les systèmes « 370 ». « 4300 », « 3080 » et «
3090 » dont certains sont encore en service dans de grands centres de calcul.
Tous les logiciels, y compris le système d’exploitation, devaient alors répondre à un grand nombre de
contraintes. Ils devaient être capables de tourner sur de petits calculateurs pour remplacer les « 1401 »
ou sur de gros calculateurs pour remplacer des « 7094 », sur des machines utilisant peu de
périphériques ou sur d’autres en utilisant beaucoup, pour des environnements scientifiques ou
simplement commerciaux, et bien entendu être performants dans tous les cas. Ceci a conduit au
développement d’un énorme et très complexe système d’exploitation composé de plusieurs millions de
lignes en langage assembleur écrits par des milliers de programmeurs et contenant des milliers de bogs
(bugs) dont chaque correction en engendrait d’autres Beaucoup de temps et de patience furent
nécessaires pour aboutir à un système d’exploitation satisfaisant pour la plupart des utilisateurs des
séries « 360 » et des autres machines de troisième génération développées par d’autres constructeurs.
Bien que ces systèmes étaient toujours à la base des systèmes de traitement par lot, ils ont contribué au
développement de grands concepts tels que ceux de la multiprogrammation et du spooling
Le concept de la multiprogrammation (multiprogramning) consiste à utiliser les temps morts de

calcul du processeur pour exécuter d’autres travaux. Ainsi sur une machine du type 7094, lorsqu’un
travail était en attente d’une entrée-sortie (chargement d’une bande, positionnement d’une bande pour
une lecture ou une écriture...) le processeur était bloqué jusqu’à la fin de l’opération d’entrée-sortie.
Lors du traitement de calcul scientifique, les opérations d’entrée-sortie sont peu fréquentes et ce temps
perdu à attendre n’est pas significatif.

Par contre, lors du traitement de données commerciales sur supports externes, tel qu’une bande
magnétique, les temps d’attente atteignent régulièrement 80% à 90% du temps de traitement total. La
solution a consisté partitionner la mémoire de travail en segments pouvant chacun recevoir un travail
donné. Quand un des travaux chargés en mémoire était en attente de la réalisation d’une opération
d’entrée-sortie, un autre travail pouvait alors utiliser le processeur. Si suffisamment de travaux étaient
présents en mémoire centrale, le processeur pouvait être ainsi rentabilisé à 100%.
Le concept du spooling (Simultaneous Peripherical Operation On Line) est né du besoin de supprimer

toutes les manipulations de bandes magnétiques en entrée comme en sortie des calculateurs. Pour cela,
tout nouveau travail soumis à la machine était retranscrit en entrée à partir des cartes perforées sur
disque (disk). Ainsi, dès qu’un travail sur la machine se terminait. le système d’exploitation pouvait
immédiatement aller chercher sur le disque un nouveau travail et le charger en mémoire dans la partition
qui venait de se libérer. Ce principe était également appliqué en sortie et conduisit ainsi à la mort des «
1401 ».
Au cours des années 1960, IBM mit au point le système VMICMS. Il ne s’agit pas d’un système, mais
de deux, voire même plusieurs avec un hyperviseur (virtual machine system) auquel on pouvait greffer
n’importe quel système d’exploitation classique. Les chercheurs du Centre Scientifique d’IBM à
Cambridge (Etats-Unis) éprouvaient une gêne pour utiliser l’ordinateur puissant dont il disposait car,
étant donné que leurs recherches portaient sur les systèmes d’exploitation, ils passaient à tour de rôle,
en monoprogrammation, sur l’ordinateur. En effet, comme leurs expériences avaient lieu en « mode
système », ils risquaient toujours de perturber les travaux en cours. C’est donc pour des raisons de
sécurité qu’il a fallu trouver le moyen de donner à chaque utilisateur la possibilité de travailler en «
mode système » sans perturber les autres. Le concept de machine virtuelle répond à cette nécessité. Ce
concept a représenté un pas important dans les recherches sur les systèmes d’exploitation. C’est le
programme de commande (Control Pro gram) VM (Virtual Machine) qui gérait (et gère toujours...) les
machines virtuelles, alors que CMS (Cambridge Monitor System, maintenant appelé « Conversational
Monitor Svstem ») était le système d’exploitation classique. L’hyperviseur simule un ordinateur complet
pour chaque utilisateur. Avec un système de machines virtuelles, la simulation de la machine offre toutes
les possibilités de l’ordinateur à chaque utilisateur. L’utilisateur de VM/CMS passe toujours par les
deux systèmes pour se connecter la première fois, il faut créer une machine virtuelle sous VM en
définissant ses limites (mémoire, périphériques...), puis y générer le système CMS ; par la suite, au
moment de la connexion, il faut passer par deux étapes se connecter sous VM, puis charger CMS dans
la machine virtuelle.
Avec ces systèmes de troisième génération, il fallait souvent plusieurs heures pour récupérer des
résultats d’un travail une fois que celui-ci avait été soumis (ce pouvait être encore plus long lorsqu’un «
point virgule » mal placé dans un programme entraînait une erreur de compilation). Le désir des
utilisateurs d’avoir des résultats plus rapidement, amena les concepteurs à se pencher sur la notion de
temps partagé (time-sharing ). Cette notion est une variante du concept de la multiprogrammation.
Avec un système en temps partagé, si 20 utilisateurs ont ouvert une session (logon) sur le système et 17
d’entre eux ne l’utilisent pas (ils pensent à leur programme ou discutent en buvant un café ...)
l’allocation du processeur se fera que sur les trois tâches en service chargées en mémoire. Ce concept a
permis de fournir un service rapide et interactif aux utilisateurs que se soit pour des travaux courts (tel
que la compilation de cinq pages de programme) ou pour des travaux plus longs (tel que le classement
d’un million d’enregistrements sur bande).

Cette notion vit le jour dès 1962 au M.I.T. (Massachusetts Institut of Technologv) sur un « 7094 »
modifié, grâce à une collaboration entre « Bell Lobs » et « General Electric ». Néanmoins, pour la
mettre en oeuvre, il était absolument nécessaire que la machine qui devait supporter un tel système
puisse matériellement assurer à tous les travaux chargés en même temps en mémoire, une protection des
zones mémoire utilisées. Ce qui fut fait seulement avec l’avènement de nouvelles technologies sur les
machines de troisième génération. Le premier système temps partagé fut le système MULTICS
(MULTIplexed Information and Computing Service) qui tournait sur les machines du type GE645
développé conjointement par Bell Labs et General Electric.
D’autre part, la troisième génération fut aussi celle des mini-ordinateurs (minicomputers) dont les
premiers, appelés « PDP-I », furent développés par «DEC » (Digital Equipment Corporation). Ces
mini-ordinateurs qui pouvaient gérer que 8 Ko de mots de 18 bits mais coûtaient que 120.000$ (soit
moins de 5% du prix d’un 7094), se sont très vite et très bien vendus. Ils donnèrent naissance à toute
une série de machines « PDP », du « PDP-I » au «PDP-II ». A la même époque (en 1969), un des
scientifiques de «Bell Labs », Ken Thompson, qui avait travaillé sur le projet MULTICS, trouva un jour
un mini-ordinateur « PDP7» non utilisé et décida d’y développer une version simplifiée de MULTICS.
Ce sont ses travaux qui furent à la base du développement du système UNIX qui est depuis devenu le
standard des systèmes d’exploitation sur les mini-ordinateurs et les stations de travail.
En 1978, DEC disposait d’une bonne gamme de mini-ordinateurs 16 bits avec la série «PDP-l1 »
équipée d’un système d’exploitation multitâche temps-réel (real-time multitasking), le « RSX-11M».
Mais la limitation de l’espace d’adressage des machines 16 bits commençait à poser de sérieux
problèmes. L’extension de cette machine en une machine 32 bits, appelé VAX, conçue dès le départ
pour supporter une gestion de mémoire paginée, a nécessité l’écriture d’un nouveau système
d’exploitation, VMS (Virtual Management System). A l’origine, VMS était donc qu’un noyau de
gestion de la mémoire virtuelle et utilisait un grand nombre d’utilitaires de RSX-IIM, et le processeur
du VAX disposait d’un microcode capable d’exécuter des instructions du processeur PDP-II. Ensuite,
VMS a évolué vers un système d’exploitation complet et performant écrit en assembleur VAX.
1.1.4.4./ Quatrième génération (1980-1990) Ordinateurs personnels
Avec le développement des circuits intégrés L.S.I. (Large Scale Integration) qui sont des puces
électroniques (chips) pouvant contenir des milliers voire même des millions de transistors sur un cm2 de
Silicium, l’âge des ordinateurs personnels (P.C. : Personal Computer) et des stations de travail
(workstations) était venu. En insérant dans des puces de quelques mm2 les composants d’une unité
centrale, cette nouvelle technologie a permis de réduire de manière considérable l’encombrement des
machines. En terme d’architecture, ces calculateurs n’étaient pas très différents des mini-ordinateurs de
la classe des « PDP-11 ». Par contre, en terme de prix, leurs productions en grandes séries les ont
rendus beaucoup moins chers. Alors que les mini-ordinateurs ont permis aux petits départements
universitaires ou aux petites entreprises d’avoir leur propre ordinateur, les P.C. ont permis à un simple
individu de posséder le sien. Ils ont favorisé de manière considérable le développement de
l’informatique et la Création d’un grand nombre d’entreprises produisant des logiciels pour P.C.. Le
premier ordinateur personnel fut le « Altair » développé par la société américaine MITS et sur lequel,
un jeune homme, appelé Bill Gates, développa un langage de programmation évolué, le BASIC (Be
ginner’s All-purpose Symbolic Instruction Code), qui devint très vite populaire parmi les utilisateurs de
micro-ordinateurs (par opposition avec le FORTRAN) et qui fit alors sa fortune.

Deux grands systèmes d’exploitation ont alors dominé le marché des ordinateurs personnels et des
stations de travail
UNIX qui est le système d’exploitation le plus utilisé sur les micro-ordinateurs n’utilisant pas la
technologie INTEL, les stations de travail (ordinateurs personnels plus puissants) et plus
particulièrement celles mettant en oeuvre des processeurs RISC. Il est issu des travaux de Ken
Thompson et D.M. Ritchie qui développèrent, à partir du système MULTICS. pour leurs propres
besoins sur un « PDP-7 », un système d’exploitation mono-utilisateur (single-user system) apte à
supporter la multiprogrammation. Il fut dans un premier temps appelé UNICS (UNiplexed Information
and Coinputing Service) par opposition à MULTICS et par plaisanterie de la part d’un autre chercheur
de Bell Labs, Brian Kernighan. (« Eunuchs » voulant dire eunuque en anglais ce qui correspondait bien à
l’utilisation «castrée » faite alors de MULTICS pour créer ce nouveau système temps partagé) avant de
prendre plus tard son appellation définitive
En 1973, les utilitaires et la plus grande partie du noyau furent réécrits en langage C (langage mis au
point dans l’intervalle par D.M. Ritchie à partir d’un autre langage, moins complet, qui s’appelait le
langage « B »). Cette version rendit UNIX portable sur d’autres machines que des « PDP ».
Microsofts MS-DOS qui est le système d’exploitation le plus utilisé sur les micro-ordinateurs IBM
P.C. et compatibles (toutes les machines utilisant des processeurs de la famille Intel 8088 (et ses
successeurs les « 80286 », « 80386 », « 80486 »). Lorsque la compagnie IBM s’intéressa au
développement de la micro-informatique, elle décida de fabriquer son propre ordinateur personnel en
douze mois. En si peu de temps, il n’était pas question qu’elle fasse tout elle-même La plus grande
partie des composants fut achetée à d’autres compagnies, assemblée et testée dans les usines d’IBM.
C’est le processeur « 8088 » qui fut choisi pour composer l’architecture de base des ordinateurs IBM
P.C.. Il avait l’avantage d’être peu cher et de permettre ainsi à IBM de vendre ses P.C. à faible prix.
Cependant, ces machines ne disposaient pas de disque dur et n’avaient que 64 Ko de mémoire vive. Ces
limites ne permirent pas l’utilisation d’UNIX comme système d’exploitation puisque, développé pour
des mini-ordinateurs, il nécessitait l’uti1isation d’un disque dur et demandait 100 Ko de mémoire vive
rien que pour le système. Bill Gates suggéra alors à IBM d’utiliser le système d’exploitation CPM-86
qui était en cours de conception chez Digital Research. Mais « CP/M-86 » était beaucoup trop en retard
sur le calendrier et IBM ne pouvait pas attendre. IBM revint alors tout naturellement demander à Bill
Gates qui avait créé depuis l’entreprise Microsoft pour commercialiser son interpréteur BASIC, s’il
pouvait développer un système d’exploitation équivalent à CP/M-86 pour leur P.C. Bill Gates savait
qu’il n’avait pas suffisamment de temps pour cela mais savait aussi qu’une compagnie voisine, Seattle
Computer Products, avait écrit un système d’exploitation du type CP/M, appelé 86-DOS, pour tester
les différents types mémoires qu’elle fabriquait et vendait. En avril 1981, il décida d’acheter 86-DOS et
d’embaucher son principal auteur, Tîm Paterson, pour le mettre au point et le développer. Ils le
renommèrent alors MS-DOS (Micro Soft - Disk Operating System) et le livrèrent en temps voulu à
IBM qui put annoncer dès août 1981 la sortie de son P.C. livré avec une première version de MS-DOS.
Depuis, avec plus de 60 millions de licences vendues, il est devenu maintenant le système d’exploitation
le plus utilisé au monde.

Les années 1980 connurent aussi l’avènement des machines Macintosh développées par APPLE.
L’architecture de base de cet ordinateur personnel était constituée du microprocesseur 32 bits, le «
68000 » de MOTOROLA avec une mémoire vive de 512 Ko, étendue en 1986 à I Mo, extensible
jusqu’à 4 Mo et une unité de disquettes externe de 3,5 pouces. Mais l’innovation majeure du « Mac»
était son écran graphique à mémoire de trame associé à des menus déroulant (pull down menu)
entièrement commandée par une souris (mouse). L’ensemble, correctement intégré et accompagné de
quelques logiciels bien choisis et innovateurs (pour l’époque), mettait ainsi à la portée du plus grand
nombre des techniques de programmation et un mode de relation avec la machine jusqu’alors confinés
dans quelques laboratoires de recherche.
Au milieu des années 1980, le développement des réseaux informatiques (networks) et plus
particulièrement celui des réseaux de micro-ordinateurs, pris une importance considérable. Avec eux
deux autres types de systèmes d’exploitation ont été développés les systèmes administrateurs de réseaux
(Network Operating Systems) et les systèmes d’exploitation distribués (distributed Operating Systems)
Avec un système «administrateur de réseaux », les utilisateurs peuvent ouvrir une session sur les
différentes machines connectées et copier des fichiers d’une machine vers une autre. Chaque machine a
son propre système d’exploitation locale et ses propres utilisateurs. Ces systèmes d’exploitation sont
peu différents des systèmes d’exploitation monoprocesseur (uniprocessor System). Ils ont simplement
besoin de gérer en plus un contrôleur d’interface réseau et son pilote afin d’assurer à distance
l’ouverture d’une session sur un poste sur le réseau et l’accès aux fichiers, mais cela ne change pas la
structure et les fonctions essentielles d’un système d’exploitation.
Un système d’exploitation distribué apparaît aux yeux des utilisateurs comme un système
monoprocesseur traditionnel alors qu’il est vraiment composé de plusieurs processeurs. Avec ces
systèmes, un utilisateur peut très bien ne pas savoir sur quelle machine ses programmes seront exécutés
ni où sont physiquement localisés ses fichiers. Tout cela étant automatiquement et efficacement pris en
charge par le système d’exploitation. Dans leur conception, les systèmes d’exploitation distribués
diffèrent beaucoup des systèmes centralisés. Ils peuvent, par exemple, demander l’exécution des
programmes sur plusieurs processeurs en même temps, ce qui implique des algorithmes d’allocation de
processeur beaucoup plus complexes afin d’optimiser la gestion du parallélisme. Les délais des
communications sur un réseau font qu’en plus ces algorithmes doivent souvent tourner avec des
données incomplètes, souvent incorrectes ou pas mises à jour. Cette situation est très différente de celle
des systèmes à processeur unique dont le système d’exploitation dispose toujours de la totalité des
informations sur l’état du système.
1.1.4.5./ Génération multimédia (1990-à nos jours)
Depuis le début des années 1990, la puissance des micro-ordinateurs et de leurs périphériques n’a
jamais cessé de croître pendant que leur prix, par contre, devenait de plus en plus bas. La puissance et la
qualité des cartes d’adaptation entre l’ordinateur et l’écran (notamment la carte VGA) ont offert de
grandes possibilités telles que le travail sur écran en mode graphique et le remplacement du texte par
des pictogrammes, appelés icônes (icon).

Ces techniques ont rendu le travail sur ordinateurs beaucoup plus simple et beaucoup plus agréable. Ce
phénomène a permis l’ouverture du marché à la Bureautique et au grand public. Cette ouverture ne put
se faire que grâce au développement de systèmes d’exploitation interactifs (interactive systems) et
conviviaux (user-friendly systems) permettant la mise en oeuvre et l’utilisation simple d’une machine.
La plupart de ces systèmes ont été développés pour des utilisateurs novices, ne connaissant rien à
l’informatique en général, et n’ayant, de plus, aucune intention d’apprendre.
Les innovations principales concernèrent alors l’interface de communication entre l’utilisateur et la

machine, communément appelé interface homme-machine (Human-Computer Interface) et les
techniques multimédia qui permettent la gestion d’images, de vidéo et de sons.
Dès 1982, un groupe d’informaticiens du centre de recherche de la société XEROX à Palo Alto en
Californie, avait mis au point un ordinateur révolutionnaire baptisé STAR. Celui-ci était doté d’une
mémoire peu commune pour l’époque (plusieurs centaines de Ko), d’un écran à haute résolution
graphique et d’un nouveau type de périphérique curieusement appelé souris (mouse). Cette machine
intégrait le concept de menus déroulants et celui de multifenêtrage (multiwindowing ). Tout ce qui
suscite l’engouement des utilisateurs d’aujourd’hui et quià contribué au développement et à la
vulgarisation de l’informatique se trouvait déjà dans la machine « STAR » Cependant, cette machine ne
connut aucun succès commercial, à cause de la politique de «XEROX» mais valut un prestige
considérable à l’équipe « PARC » (Palo Alto Research Center). C’est ce concept qui fut repris ensuite
par les gens de chez APPLE lors du développement du Macintosh.
Le concept d’interaction homme-machine développé alors est la métaphore du bureau (desktop). La

figure 1.4 est un exemple d’interface homme-machine graphique développée selon cette métaphore. Sur
ces machines, l’interface s’efforce d’être la reproduction miniature du monde du bureau. Par exemple,
dans cet environnement, un dossier électronique (répertoire ou fichier) a la même présentation externe
qu’un dossier réel il comporte une chemise et un nom.
Comme le dossier du monde réel, il peut être ouvert, reproduit, déplacé sur le bureau, rangé dans un
autre dossier, jeté à la poubelle, etc. Toutes ces actions s’effectuent avec la souris (ou un autre dispositif
de pointage) qui sert de substitut électronique de la main. L’utilisation d’un ordinateur est devenue alors
extrêmement simple et ne nécessita plus de qualification et de formation particulières.
Ce concept fit la gloire d’APPLE qui imposa pendant très longtemps les systèmes « Macintosh »
comme un standard en Bureautique. Néanmoins, la politique d’APPLE qui consistait à développer des
produits complètement fermés destinés à des non-informaticiens, l’a conduit, depuis le milieu des années
1990, à une rude concurrence avec les machines P.C. qui elles sont totalement ouvertes et offrent ainsi
de très grandes possibilités d’évolution.
Pour faire accepter les P.C. aussi bien par les particuliers que par les entreprises, il fallait rendre ces
machines beaucoup plus simples d’utilisation qu’elles ne l’étaient à travers le système MS-DOS. C’est le
travail que Microsoft a entrepris dès 1985 en développant une première version du système WINDOWS
qui connut alors qu’un succès d’estime, et qui fut suivie d’une deuxième version, fin 1987, qui suscita
suffisamment d’intérêt pour décider plusieurs éditeurs d’applications, et notamment de conception ou
de publication assistées par ordinateur, à développer leurs applications sous WINDOWS. Ce n’est que
la version 3 de WINDOWS, sortie fin 1991, qui suscita l’enthousiasme. En fait WINDOWS 3.1/3.11,
n’est pas un système d’exploitation (même Si Microsoft l’appelle ainsi...).

Il s’agit simplement d’une interface utilisateur de la version 6 de MS-DOS (MS-DOS 6.22). Il offre un
moyen confortable d’accéder â la machine et permet un fonctionnement multitâche (chaque tâche
pouvant s’exécuter dans une fenêtre différente) ainsi que l’échange de données entre applications. Il se
charge donc uniquement de la partie gestion des entrées-sorties, laissant la gestion de toutes les autres
tâches du système d’exploitation.
Le système WINDOWS 95, réalise le mariage attendu du système d’exploitation MS-DOS et de

l’interface utilisateur. Ainsi, il n’est plus besoin de lancer d’abord DOS et ensuite WINDOWS ou
encore d’adapter les deux éléments l’un à l’autre ils ne forment plus qu’un seul ensemble. Il constitue en
fait un clone du système Macintosh sur PC. en offrant toutes les possibilités et tous les concepts
développés par APPLE, et propose en plus d’autres services tels que l’accès aux réseaux et la gestion
multitâche des programmes.
Figure 1.4 . Exemple d’interface graphique du type « métaphore du bureau » (LINUX - KDE)
Au début des année 90, un jeune étudiant finlandais LINUS B. TORVALDS commença à écrire les
fondements d’un système UNIX pour ces études en informatique. Il mit a disposition ces codes sources
sur Internet et initia le développement logiciel en coopération par l’intermédiaire du réseaux mondial.
Ce modèle de développement appeler Open Source évolua rapidement, donna naissance à un système
UNIX compatible POSIX basé avec des extensions System V et Berkeley nommé LINUX.

Ce système d’exploitation fonctionnant sous un nombre considérable d’architectures matérielles, pris sa

véritable grandeur tout d’abord sur Internet pour la création de serveur WEB. Plus tard, d’autres
projets Open Source, on permit de démarqué LINUX des systèmes UNIX traditionnels par des
interfaces graphiques particulièrement soignées (CF figure 1.4) à l’effigie du bureaux de travail virtuels
WINDOWS et MAC.
Sa gratuité et sa robustesse le place en sérieux concurrent des systèmes d’exploitation commerciaux

aussi bien pour les processus industriels que pour la bureautique personnelle grâce à une multitude
d’applications disponibles gratuitement sur le WEB.
Le multimédia est né dans les années 1980, avec la vidéo interactive qui consistait alors à utiliser un
vidéodisque entièrement analogique pour stocker des sons, des images fixes et des images vidéo. Il ne
constitue pas un domaine particulier de l’informatique mais n’est que le prolongement logique et
l’aboutissement de l’évolution technologique, tant matérielle que logicielle. C’est aussi le mariage de
techniques issues de l’audiovisuel, de l’informatique et des télécommunications. Certaines avancées
technologiques ont contribué à son développement :
· Le développement des technologies de stockage optique pour des volumes importants de

données, telles que les disques otiques compacts (CD-ROM).
· Le développement des méthodes de compression et de décompression de textes. d’images fixes

ou animées.
· L’accroissement continu des performances, en terme de capacité de traitement des

microprocesseurs.
· Le développement des technologies de transfert de données numériques volumineuses.
L’objectif du multimédia est à la fois d’acquérir, de gérer et d’utiliser non seulement des valeurs
numériques et du texte, mais aussi des graphiques, des images, du son (données audio) et de l’image
animée (vidéo). Il permet de travailler ou d’apprendre mieux et plus vite en intégrant, par exemple, des
commentaires sonores ou des séquences vidéo dans des logiciels de formation. dans des systèmes d’aide
à la vente, à la réparation et à l’entretien d’appareillages divers, dans des présentations assistées par
ordinateur... Il a ouvert également la voie à la messagerie électronique multimédia, ainsi qu’à la
vidéoconférence.
Son véritable lancement s’est fait avec l’apparition du logiciel Hypercard sur Macintosh, grâce auquel
les utilisateurs pouvaient stocker des données, telles que du texte, des images et du son, dans des piles
de cartes et naviguer au sein de cet ensemble de piles par association d’idées à l’aide de techniques
hypertextes utilisant des boutons et des icônes. Les principales caractéristiques des données multimédia
concernent d’une part leur volume, nécessitant des capacités de stockage qui s’expriment en mégaoctets
(megabytes) voire même en gigaoctets (gigabytes) et des méthodes de compression de données, et
d’autre part le fait quelles soient, dans l’état actuel des technologies, à la fois numériques et
analogiques, bien que s’orientant à terme vers le tout-numérique.

Les applications multimédia se distinguent en deux catégories les applications professionnelles qui
concernent la formation, la présentation assistée par ordinateur, la Bureautique, la gestion de documents
techniques et la vidéoconférence, et les applications domestiques grand public qui concernent les jeux,
le tourisme et les catalogues. Elles se répartissaient en 1997 de la manière suivante :
· Formation : 25%
· Points de vente et de renseignements (bornes) 14%
· Loisirs :12%
· Bureautique: 12%
· Publicité, présentation :11%
· Communications: 11%
· Autres : 15%
En dehors des coûts des matériels et des logiciels, on peut noter, pour les applications multimédia, le
coût, non négligeable, d’acquisition des informations à partir de sources diverses: micros ou interfaces
MIDI pour le son, scanners pour la numérisation de schémas, d’images ou de textes, systèmes de
reconnaissance optique de caractères à partir de textes scannés, caméras vidéo pour les images... Ainsi,
pour donner un ordre de grandeur, il faut compter de 1 à 10 MF pour le développement d’une
application et de 50 à 500 KF pour la création d’une borne interactive.
1.1.5. / LES DIVERS TYPES DE SYSTEMES D’EXPLOITATION MULTITACHE
La nature de la machine virtuelle peut être très diverse et cela donne naissance à divers types de
systèmes d’exploitation multitâche (multitasking Operating Systems). Nous en avons répertorié deux
grandes classes : les systèmes multitâche monoprocesseur et les systèmes multitâche multiprocesseur.
1.1.5.1./ Les systèmes multitâche monoprocesseur
Ces systèmes ont pour rôle de permettre le partage du processeur par plusieurs programmes qui, vus de
l’utilisateur, se déroulent en même temps. Cette notion de simultanéité apparente d’exécution. est basée
sur une utilisation optimisée du processeur. L’allocation du processeur aux programmes est effectuée
selon leurs priorités et leurs besoins au moyen de règles d’ordonnancement plus ou moins sophistiquées.
Ce concept de multiprogrammation (multiprogramming) permet de faire cohabiter des programmes qui
peuvent être totalement indépendants ou qui peuvent au contraire coopérer pour réaliser un objectif
commun. Dans ce contexte, une application peut être décomposée en tâches (ou processus) créées,
activées et détruites donnant une vue dynamique d’un programme. Cette organisation est beaucoup plus
souple que celle d’une application mise en oeuvre par un seul programme monolithique, mais pose un
certain nombre de problèmes comme, par exemple :

· Comment partager l’unité de traitement entre plusieurs programmes et sauvegarder le contexte

(l’état d’exécution) de chaque programme ?
· Comment gérer la mémoire centrale en permettant le chargement d’un nombre élevé de

programmes dans un espace mémoire limité ?
· Comment gérer les entrées-sorties des différents programmes, en assurant un trafic ordonné de
données entre la mémoire et les unités périphériques tout en empêchant le système de mélanger ou
confondre les informations appartenant à ces différents programmes ?
· Comment protéger les programmes et les données stockés dans la mémoire centrale et sur
disques, des erreurs éventuelles (des programmes, du système et de la machine) qui pourraient
avoir des conséquences graves sur le déroulement des opérations ?
Suivant le domaine d’application retenu, divers systèmes d’exploitation multitâche ont été développés à
partir de ce concept de base. Ces systèmes procèdent tous selon des principes différents
1.1.5.2./ Les systèmes multi-utilisateur
La caractéristique principale des systèmes multi-utilisateur (multi-user systems) est qu’ils donnent
l’impression à chaque utilisateur d’être le seul à utiliser la machine. Un système d’exploitation Multi-
Utilisateur doit, en conséquence, gérer l’ensemble des ressources (processeurs, mémoires, disques...) en
assurant une certaine protection aux utilisateurs, de manière a éviter la destruction non intentionnelle ou
malveillante des données d’un utilisateur par un autre. De plus cette gestion des ressources doit être
équitable afin d’assurer une bonne cohabitation des tâches des utilisateurs sur la machine.
Pour ce qui concerne le processeur, ce partage équitable est souvent résolu en attribuant à chaque
utilisateur une tranche de temps de façon périodique ce qui correspond à la notion de systèmes à temps
partagé (time-sharing systems). Lorsque le temps alloué à un utilisateur s’est écoulé, le système
sauvegarde le contexte de cet utilisateur de façon à pouvoir le rétablir au cycle suivant (cf. figure 1.5).
Avec un tel système une partie du temps processeur est évidemment perdue lors des changements de
contextes. Néanmoins, le rendement global reste satisfaisant si les utilisateurs ne sont pas trop
nombreux.
Les délais d’exécution des petits travaux sont considérablement raccourcis, sans pénalisation excessive
des travaux importants. En effet, si l’ordinateur est partagé entre 10 utilisateurs, par tranches de temps
de 25 ms, avec un temps de traitement égal à 1 minute pour 9 des utilisateurs et égal à I heure pour le
dixième utilisateur, les 9 programmes rapides seront terminés au bout de 10 mn alors que le programme
lent le sera au bout de 1 heure et 10 mn.

Figure 1.5 Allocation du temps processeur dans un système en temps partagé
Ce type d’exploitation ne convient évidemment pas dans le cas où les travaux soumis à l’ordinateur ont
une durée très importante, car ils sont tous uniformément retardés, alors que certains d’entre eux
auraient pu être terminés plus rapidement, par exemple avec un traitement par lots. Ainsi, l’exécution
simultanée de 10 programmes requérant chacun 1 heure de traitement prend 10 heures avec un système
en temps partagé, alors que le premier programme est terminé au bout d’une heure dans le cas d’un
traitement par lots.
1.1.5.3./ Les systèmes temps-réel
La caractéristique principale des systèmes temps-réel est de permettre le traitement en temps réel
d’événements (event), c’est-à-dire de garantir une réponse dans un temps donné. Cette contrainte
concernant le temps d’exécution amène à classer les travaux à effectuer selon divers niveaux de priorité,
les plus prioritaires étant ceux dont les contraintes de temps de réponse sont les plus fortes. Dans un tel
contexte, chaque travail à effectuer correspond à une tâche avec une priorité donnée dont le
déroulement peut être suspendu à tout moment pour permettre l’exécution d’une tâche plus prioritaire.
Dans cet environnement, l’exécution des différentes tâches est assurée sous le contrôle d’un moniteur
qui commande le déroulement en fonction des priorités, des événements extérieurs et des contraintes de
temps. Les systèmes d’exploitation temps-réel sont, en général, appelés exécutifs temps-réel.
La figure 1.6 illustre le fonctionnement d’un système en mode multitâche temps-réel. On considère dans
cet exemple deux tâches A et B de priorités respectives 2 et 1 devant être exécutées de manière
cyclique, sous le contrôle d’une horloge temps-réel qui provoque une interruption au début de chaque
cycle. Par ailleurs, certaines tâches asynchrones peuvent être exécutées à tout instant à la suite d’une
interruption provoquée par un événement.
Au temps t1 la première interruption d’horloge provoque l’activation de la tâche A qui est la plus
prioritaire à cet instant. La tâche A s’exécute jusqu’à l’instant t2 où elle se bloque dans l’attente de la fin
d’une opération d’entrée-sortie. L’exécutif reprend alors le contrôle et passe la main à la tâche B qui est
la seule en attente.

Au temps t3, une interruption d’alarme signale au processeur une demande d’exécution d’une tâche de
gestion d’alarme de priorité 3. Comme cette tâche est plus prioritaire que la tâche B, l’exécutif suspend
le traitement de la tâche B et passe la main à la tâche de gestion d’alarme qui s’exécute jusqu’à sa fin
survenant à l’instant t4. La tâche B reprend alors son exécution qui est de nouveau suspendue à l’instant
t5 par une interruption d’entrée-sortie dont l’apparition signale que les informations attendues par la
tâche A sont arrivées. L’exécutif passe alors le contrôle à la tâche A qui termine son exécution à
l’instant t6, pour être ensuite suivie par la fin du traitement de la tâche B. Le cycle suivant démarre à la
prochaine interruption de l’horloge temps-réel, à l’instant t8.
Figure 1.6: Exemple d’exécution multitâche temps-réel
Les systèmes d’exploitation temps-réel sont destinés à fonctionner dans un contexte industriel où le ou
les calculateurs sont connectés à un procédé physique. Les domaines d’application des systèmes temps-
réel sont extrêmement divers et étendus
On trouve ainsi dans l’industrie manufacturière, pétrolière ou chimique, des systèmes de commande de
procédés industriels où le calculateur est utilisé pour automatiser, c’est-à-dire réguler une installation ou
ordonnancer une production. L’intégration des différents niveaux d’automatisation, depuis la
commande locale jusqu’à la planification de la production, est l’une des composantes de la productique.
Les calculateurs chargés de la commande locale sont en interaction constante avec le procédé industriel
au moyen de capteurs et d’actionneurs.
La diversité des procédés fait que les temps de réponse peuvent varier de quelques millisecondes
(commande de robots en mouvement), à quelques minutes (industrie céramique et commande de fours),
voire à quelques heures (procédés biologiques).
On rencontre également des systèmes de télécommunication où la tâche du calculateur consiste à

composer, transmettre et traiter des messages. La reconstitution des messages transmis à haute vitesse
(en général sur des lignes en série ou par faisceaux hertziens), découpés en paquets, codés, encryptés,
compactés et modulés, s’effectue en temps-réel avec des constantes de temps très courtes (en général
inférieures à la milliseconde).

Les applications militaires, où l’on retrouve de nombreux problèmes centrés autour des communications
et du pilotage à distance (avec un degré de complexité accru par des contraintes très sévères de sécurité
amenant à utiliser des redondances logicielles et matérielles), sont un autre domaine d’application des
systèmes temps-réel.
Enfin, les systèmes interactifs de simulation dont le but est de fournir à l’utilisateur un moyen de
remplacer un système physique par un système informatique ayant le même comportement, travaillent
en temps-réel et nécessitent, en général, un système graphique de haute performance.
Remarque:
La différence principale entre les systèmes multi-utilisateur et les systèmes temps-réel réside dans le fait
que les tâches sont souvent indépendantes dans les premiers, puisque chacune correspond à un
utilisateur différent, alors que dans les seconds les tâches coopèrent toutes d’une manière ou d’une
autre à la commande d’un procédé. Elles ont donc besoin dans ce cas de se synchroniser et de se
transmettre des messages afin d’atteindre l’objectif de commande souhaité. D’autre part, dans les
systèmes temps-réel il ne faut surtout pas chercher à être équitable dans le partage des ressources. Au
contraire, les tâches les plus urgentes doivent accaparer totalement le processeur en suspendant le
déroulement des tâches les moins urgentes pendant tout le temps nécessaire au traitement des tâches
prioritaires. Les problèmes liés à la concurrence entre les tâches et traités dans le chapitre 4 prennent
donc toute leur importance lors du traitement d’applications devant se dérouler en temps-réel et traitées
pour cela par des systèmes d’exploitation temps-réel.
1.1.5.4./ Les systèmes transactionnels
Les systèmes d’exploitation transactionnels sont basés sur l’utilisation d’un programme commun par
plusieurs utilisateurs en même temps. Les systèmes bancaires et de réservation de places sur lignes
aériennes ou ferroviaires en sont des applications. Ses systèmes sont caractérisés par des bases de
données mises à jour très fréquemment (plusieurs fois par seconde). Dans le premier cas, la base de
données contient le détail des comptes bancaires mis à jour par chaque opération de débit ou de crédit et
dans le second cas, la base de données enregistre toutes les réservations de places d’avions.
La principale contrainte des systèmes transactionnels résulte de la nécessité de maintenir les bases de
données à jour car il est clair que le système est inefficace si les transactions portent sur des données
erronées. Les difficultés s’accroissent lorsqu’il faut pouvoir prendre en compte simultanément deux
transactions affectant la même donnée (par exemple, deux agences de voyages désirant réserver au
même moment la même place d’avion). Dans de tels systèmes, le système d’exploitation du calculateur
doit prendre en charge ces problèmes afin d’assurer en permanence la cohérence, l’intégrité et la
sécurité de la base de données partagée.

1.1.5.5./ Les systèmes multitraitement
Avec les systèmes monoprocesseur, le parallélisme dans l’exécution est obtenu par le partage du
processeur entre plusieurs tâches. L’évolution actuelle de la microélectronique va plutôt dans le sens de
l’abaissement du coût des circuits que dans le sens d’un accroissement de leur vitesse de
fonctionnement. On est donc amené aujourd’hui à concevoir des ensembles informatiques qui
comportent plusieurs processeurs. Cette évolution est évidemment très intéressante pour les
applications d’informatique industrielle, car elle va dans le sens d’une amélioration de la modularité et
de la fiabilité des systèmes.
Avec les systèmes multitraitement (concurrent processing systems), la simultanéité réelle d’exécution de
plusieurs programmes est possible du fait de l’existence de plusieurs processeurs. Les systèmes
d’exploitation ont alors pour objet d’ordonnancer le traitement sur plusieurs processeurs qui peuvent
être semblables ou non
Le fonctionnement s’effectue selon le principe du partage de charge (Load sharin g), c’est-à-dire qu’un
programme, au cours de son déroulement peut être amené à être exécuté successivement sur des
processeurs différents à chaque fois que son exécution est interrompue et reprise. L’attribution des
processeurs aux programmes s’effectue de façon à équilibrer au mieux, à chaque instant, la charge des
processeurs. Les caractéristiques des processeurs étant connues, des algorithmes efficaces
d’ordonnancement ont été définis. Cependant, un problème se pose au niveau des processeurs
d’entrées-sorties puisque les temps de transfert et de réponse sont quelques fois difficiles à prévoir. On
fait alors à nouveau appel aux mécanismes de multiprogrammation.
Dans ce type de système, que les processeurs aient des caractéristiques identiques ou qu’ils soient pré
affectés et dévolus à des tâches spécialisées (processeurs de traitement de signaux. processeurs
d’entrées-sorties...), le système d’exploitation est situé sur un processeur central qui coordonne
l’activité des autres processeurs.
Par contre, il existe des systèmes où les processeurs ont, non seulement des propriétés différentes, mais
en plus possèdent une certaine autonomie et un certain pouvoir de décision. Dans ce cas, sur chaque
processeur se trouve un système d’exploitation et suffisamment de mémoire pour qu’il puisse constituer
un calculateur à lui seul. Les liaisons entre calculateurs sont en général de nature série ce qui entraîne la
définition de protocoles de communication complexes. On parle alors de systèmes informatiques
distribués (distribured systems) dont Les réseaux locaux en sont un exemple type.
Il faut alors adjoindre aux fonctions habituelles du système d’exploitation qui est obligatoirement du
type multitâche (afin de gérer la simultanéité de la gestion des communications et du déroulement des
programmes utilisateurs) des procédures qui permettent d’assurer la cohérence et l’intégrité des
données partagées. En effet, avec ces systèmes la simultanéité des événements peut être totale car le
parallélisme et vrai et non pas simulé.

1.1.6. / STRUCTURE GENERALE D’UN SYSTEME D’EXPLOITATION
Pour que l’utilisateur ait une vision simplifiée de la machine virtuelle et puisse utiliser les fonctions les
mieux adaptées à son application, les systèmes d’exploitation comportent un certain nombre de modules
distincts. Chaque module prend en compte une des fonctions ou un sous-ensemble d’une fonction du
système. Ces modules sont bien délimités et communiquent avec les autres selon une procédure précise
à travers une interface. Les modules logiciels constituant un système d’exploitation sont ainsi organisés
en niveaux ou couches selon la structure en pelures d'oignon présentée en figure 1.7.
Toutes les couches ne sont pas obligatoires, mais lorsqu’elles n’existent pas ou qu’elles ne conviennent
pas à l’application, c’est à l’utilisateur de les créer. Avec cette structure, chaque niveau communique
avec le niveau supérieur et le niveau inférieur à travers des interfaces bien définies. Chaque niveau peut
alors être considéré comme une machine virtuelle qui met en oeuvre les logiciels et les matériels
correspondant aux niveaux qui lui sont inférieurs. Le niveau le plus bas est celui du processeur qui est
accessible par l’intermédiaire d’instructions en langage machine.
Figure 1.7: Structure en couches d’un système d’exploitation
Mis à part les systèmes d’exploitation mono-utilisateur dérivés des systèmes basés sur la soumission des
travaux (batch) dont sont dotés les micro-ordinateurs personnels, les systèmes d’exploitation sont
construits à partir d’un noyau (nucleus, kernel) assurant des fonctions de base dont le nombre varie
selon le type de système, de sa politique d’allocation du ou des processeurs, de sa politique de gestion
de mémoire (virtuelle ou non, paginée ou segmentée..)... Autour de ce noyau gravitent des couches
logiciels comportant: les fonctions de gestion des entrées-sorties, les fonctions de gestion de fichiers et
les fonctions d’interaction homme-machine.
1.1.6.1./ Le noyau
Le noyau d’un système d’exploitation, appelé également moniteur, comprend généralement deux
fonctions principales : la gestion de tâches et la gestion de mémoire (les systèmes les plus simples
(systèmes monotâche), ne disposant pas en fait de gestionnaire de tâches).

1.1.6.2./ Le gestionnaire de tâches
Le rôle du gestionnaire de tâches (task manager) d’un système d’exploitation, appelé également
distributeur de tâches (dispatcher, job-controller ou encore scheduler) est d’attribuer le contrôle du
processeur aux différentes tâches utilisateur en compétition pour leur exécution. Il comprend au moins
les trois fonctions suivantes
. Ordonnancement des tâches à exécuter selon des règles plus ou moins élaborées mises en oeuvre
par l’allocateur du processeur.
. Manipulation des tâches par un ensemble de procédures de bas niveau (inaccessibles aux
utilisateurs),
. Prise en compte et le traitement des interruptions (l’horloge temps-réel est une interruption de
haut niveau, gérée à ce niveau).
Ces fonctions permettent le lancement, la synchronisation, la destruction de tâches. Il est également

possible la plupart du temps de faire transiter des informations d’une tâche à une autre (échanges de
messages). Ces dernières fonctions, dites de communication, sont en fait à la limite entre le gestionnaire
de tâches et le gestionnaire de mémoire. Le gestionnaire de tâches est très souvent sollicité lorsqu’une
application se déroule. Il est écrit de façon très optimisée (en général en langage assembleur) et très lié
au matériel.
1.1.6.3./ Le gestionnaire de mémoire
Le gestionnaire de mémoire (memory manager) est chargé d’allouer aux diverses tâches des zones de la
mémoire qui est considérée comme une ressource partageable dans le temps. Il veille à ce qu’aucune
tâche n’accède illégalement à l’espace mémoire alloué à une autre. Il prend toute son importance lorsque
le concept de mémoire virtuelle est mis en oeuvre au moyen d'opérations de pagination de segmentation
de la mémoire. Ce gestionnaire est encore plus souvent sollicité que le gestionnaire de tâches, c’est
pourquoi la tendance actuelle consiste à intégrer le plus grand nombre de ses fonctions dans des circuits
spécialisés appelés M.M.U. (Memory Management Unit). C’est le cas des microprocesseurs 32 bits MC
68020 de MOTOROLA, du WE32100 de AAT, du NS32032 de National Semiconductors et du 80386
d’INTEL qui intègre les opérations de segmentation et de pagination.
1.1.6.4./ La gestion des entrées-sorties
Les diverses techniques de gestion des entrées-sorties ont pour objet de faire en sorte que chaque
utilisateur voit les unités périphériques de manière standard, d’où le concept de terminal virtuel. En
raison de la diversité des périphériques et leurs différences de caractéristiques, ce niveau souvent traité
cas par cas dans les applications de type temps-réel.
Les gestionnaires d’entrées-sorties (input-output manager) permettent de traiter les périphériques

comme des unités logiques dont les caractéristiques physiques sont transparentes à l’utilisateur. Cette
transparence se fait au prix d’une baisse de performance puisqu’une véritable optimisation n’est pas
possible. Les unités logiques sont décrites de façon unifiée à l’aide d’un descripteur d’unité, leur
spécificité étant donnée par des paramètres.

L’utilisation de ces unités s’effectue alors par un gestionnaire d’unités (handler). Les utilisateurs se
contentent alors d’effectuer des demandes qui sont placées en file d’attente. Pour rendre plus efficace le
travail du gestionnaire d’unités d’entrées-sorties, on lui adjoint des mémoires tampon (buffer) pour la
mémorisation des demandes.
Les entrées-sorties les plus sollicitées peuvent être gérées par des gestionnaires spécialisés, appelés
spoolers, capables de traiter en parallèle et de manière cohérente des demandes provenant de plusieurs
utilisateurs.
1.1.6.5./ La gestion des fichiers
Les différents objets manipulés par le système sont organisés sous forme de fichiers (file) qui
rassemblent sous une même dénomination une collection d’objets apparentés entre eux. Ces fichiers
sont des blocs d’informations permettant le stockage :
. Du système d’exploitation lui-même,

. Des programmes et des données des utilisateurs,
. Des programmes utilitaires (bibliothèques), des éditeurs, des compilateurs...
Certains blocs peuvent être résidents (c’est-à-dire constamment présents en mémoire centrale), c’est
notamment le cas des parties du système d’exploitation utilisées le plus fréquemment (le noyau en
particulier), d’autres sont situées en mémoire de masse.
La structure des fichiers étant définie (dimension des blocs), les fonctions de gestion des fichiers ont
pour objet d’en gérer l’accès. Elles utilisent pour cela un répertoire ou catalogue des fichiers pouvant
être organisés hiérarchiquement. Ces répertoires permettent de faire une correspondance entre l’adresse
logique d’un fichier (son nom) et son adresse physique (le numéro de piste et de secteur correspondant
au début du fichier sur un disque, par exemple).
Les fichiers peuvent être à accès séquentiel (on accédera toujours à une information en lisant le fichier à
partir du début) ou aléatoire (on peut lire et modifier une partie du fichier en y accédant directement) et
de taille fixe ou variable. Certains fichiers peuvent être partagés par plusieurs utilisateurs et le
gestionnaire doit alors vérifier les droits d’accès avant de permettre leur utilisation.
Les fonctions du gestionnaire de fichiers directement accessibles aux utilisateurs sont celles d’ouverture
de fichier (pour y lire ou y écrire) et celle de fermeture (remise à jour des répertoires après
modification).

1.1.6.6./ Le dialogue homme-machine
Ce dernier niveau d’un système d’exploitation permet à l’utilisateur le dialogue effectif avec le système
d’exploitation. Il constitue l’interface avec l’utilisateur (human-computer interface). C’est grâce à lui
que l’utilisateur peut créer son application, c’est-à-dire bâtir ses fichiers sources sous le contrôle d’un
éditeur, appeler un compilateur ou un éditeur de liens, configurer le système vis-à-vis des unités
d’entrées-sorties utilisées, lancer l’application et suivre son exécution grâce à des utilitaires d’aide au
développement.
Pour solliciter toutes ces fonctions, il dispose d’un éditeur de lignes qui lui permet d’introduire des
directives et de les modifier en cas d’erreurs. Ces directives sont écrites dans un langage de commande
(command language) conçu de telle sorte que chaque instruction soit immédiatement traduite par le
système à l’aide d’un interpréteur de commande (command interpreter).
L’interpréteur est généralement conçu pour que l’utilisateur puisse définir de nouvelles commandes
appelées procédures cataloguées en regroupant sous le même nom une série de commandes simples.
Enfin, les opérateurs du système disposent de commandes privilégiées qu’ils sont les seuls à pouvoir
utiliser et qui leur permettent de régler le système en fonction des besoins des utilisateurs (affecter des
priorités, des quotas de temps, des quotas de mémoire...).
Le système d’exploitation fournit également un certain nombre de programmes utilitaires dont le

nombre et la nature varient beaucoup d’une installation à une autre et qui servent par exemple à calculer
des fonctions mathématiques d’intérêt général, à effectuer des opérations de tri, à organiser une partition
sur un disque, etc.
1.1.7. / CONCLUSION
Les fonctions qui doivent être assurées par le système d’exploitation sont très diverses et très
complexes. Dans ces conditions, il est souhaitable d’assurer le maximum d’indépendance entre les
divers éléments logiciels et matériels du système afin d’éviter qu’une modification, même mineure, d’un
des éléments n’entraîne une série de modifications qui affectent tout le système. Afin d’obtenir le
maximum d’indépendance vis-à-vis du matériel et un partage aussi grand que possible des ressources
matérielles et logicielles, on est amené à regrouper les fonctions en familles qui correspondent chacune à
un niveau d’abstraction donné.
Dans les systèmes d’exploitation des micro calculateurs les divers niveaux que nous venons de préciser
sont plus ou moins développés selon les domaines d’applications visés. La montée en puissance des
micro calculateurs est telle que les systèmes d’exploitation du type multitâche ont tendance à se
généraliser. En conséquence, tous les niveaux décrits précédemment existent. Nous allons à présent
décrire ces niveaux en détail en examinant les concepts auxquels ils font appel.

1.2. / LA GESTION DES TACHES

Le rôle du noyau d’un système d’exploitation consiste à gérer le processeur et la mémoire. Cet élément
prend une grande importance dans le cas des systèmes d’exploitation multitâches qu’ils soient dédiés à
la commande de procédés industriels ou multi-utilisateurs. Le premier cas implique l’existence de
plusieurs tâches coopérant pour la réalisation d’un but commun, le second correspond à des tâches
fonctionnellement indépendantes mais en compétition pour l’utilisation des ressouçces communes du
système informatique.
Dans les deux cas, il s’agit de définir des techniques permettant une utilisation optimisée du processeur
et de l’espace mémoire. Ces techniques procèdent par découpage de temps et/ou de l’espace mémoire.
Ce sont ces techniques que nous allons expliciter dans ce chapitre et dans les deux chapitres suivants.
Le rôle du gestionnaire de tâches d’un système d’exploitation est principalement de gérer l’allocation du
processeur en fonction des contraintes d’exécution et d’ordonnancement des tâches selon des règles
plus ou moins évoluées et caractéristiques du système. Le problème principal du gestionnaire de tâches
consiste alors à déterminer à chaque instant quelle tâche doit être allouée au processeur, en fonction des
critères d’optimisation choisis par le concepteur ou par l’exploitant. La gestion de tâches n’intervient
qu’au sein des systèmes multitâches, à savoir lorsque différentes tâches se partagent un seul processeur
ou un nombre limité de processeurs (cas des systèmes multiprocesseur).
1.2.2. / NOTION DE TACHE
Une tâche (task), appelée également processus (process), correspond à une suite d’actions obtenues par
l’exécution d’une séquence d’instructions, c’est-à-dire d’un programme. Une tâche a une existence
éphémère elle est créée, elle exécute un programme ou plusieurs, puis elle est tuée par le système
d’exploitation. Elle représente donc une entité dynamique créée à un instant donné et qui disparaît en
général au bout d’un temps fini. La notion de tâche est donc dynamique, par opposition à la notion de
programme, qui est statique.
Le traitement effectué par un ordinateur est généralement du type multitâche, avec exécution quasi-
parallèle ou parallèle d’un certain nombre de tâches appartenant au système d’exploitation ou à
l’utilisateur. Aucune tâche n’est totalement isolée des autres. Toute tâche peut communiquer avec les
autres (par exemple, pour échanger des informations), elle peut parfois les créer, les détruire, les arrêter
provisoirement et les faire repartir.
Une tâche est donc plus qu’un simple programme elle doit contenir toutes les informations nécessaires
au système d’exploitation pour permettre la gestion de l’ensemble des tâches. L’activation d’une tâche
est effectuée par l’intermédiaire d’un agent appelé processeur qui exécute le programme associé. Cet
agent est mis en oeuvre exclusivement à partir de matériel ou sous forme de combinaison de matériel et
logiciel.

Remarque : La simultanéité d’exécution est considérée comme l’activation de plusieurs tâches, c’est-à-
dire l’exécution de plusieurs programmes au même moment. S’il y a autant de processeurs que de
tâches, le problème est facilement résolu en attribuant une tâche à chaque processeur. Mais
habituellement, il y a moins de processeurs que de tâches, si bien que la simultanéité sera obtenue en
basculant les processeurs d’une tâche à l’autre. Si le basculement est réalisé à des intervalles de temps
suffisamment courts, le système donne l’illusion de la simultanéité. Ainsi, la simultanéité apparente
d’exécution est, en fait, réalisée par l’exécution « enchevêtrée » de plusieurs tâches sur un seul
processeur.
1.2.3. / STRUCTURER UNE APPLICATION EN TACHES
La première étape de la conception d’une application, consiste à spécifier cette application. Pour mener
à bien cette étape, une approche descendante, dans laquelle on commence à spécifier les fonctions
principales et leurs interactions, semble la mieux appropriée. Ces fonctions peuvent être considérées
comme des tâches que doit accomplir le système de commande. Le détail des opérations, c’est-à-dire le
corps des tâches, peut être spécifié à part et il ne doit pas remettre en cause les interactions prihcipales
pour que la procédure soit valable.
Prenons comme exemple la commande d’un système de fabrication de feuilles de papier :
Il s’agit de concevoir une application permettant d’obtenir des feuilles de papier d’épaisseur régulière,
en régulant la température d’un bac de pâte à papier et la pression des rouleaux de calandrage à travers
lesquels la pâte va s’écouler. De plus l’opérateur doit pouvoir être en relation avec le système s’il veut
modifier les consignes de température et de pression ou encore demander l’affichage de l’état du
procédé. Dans cet exemple, on peut identifier un certain nombre de fonctions principales distinctes :
· Lecture et interprétation des commandes de l’opérateur,
· Changement des paramètres de régulation,
· Régulation de température,
· Régulation de la pression,
· Affichage de l’état du procédé sur console.
Certaines de ces opérations sont indépendantes et peuvent se dérouler en même temps. Certaines sont
prioritaires et ne doivent pas être interrompues trop longtemps (cas des régulations). Il est donc
important, pour que la gestion des tâches soit judicieuse, de bien spécifier leurs interactions.
Un déroulement séquentiel systématique est bien entendu possible. Il consisterait à réunir ces opérations
en un programme unique et monolithique, tel que, par exemple, celui présenté figure 2.1.

Programme Commande de la fabrication de feuilles de papier
Début
Tant que pas fini
Faire • Lecture et interprétation des consignes de l’opérateur
• Si Paramètre_Température changé
Alors Modifier Température de consigne
• Affichage (Température de consigne, Température instantanée)
• Si Paramètre_Pression changé
Alors Modifier Pression de consigne
• Affichage (Pression de consigne, Pression instantanée)
• Régulation de température
• Régulation de Pression
FinTantQue
Fin
Figure 2.1 : Exemple de programme de commande
On voit bien qu’une telle structure de programme est coûteuse en temps puisque à chaque cycle
l’algorithme teste si l’opérateur est intervenu et si cette intervention nécessite un changement de
paramètres ou demande un affichage de valeurs caractéristiques de l’état du procédé. Or, ces opérations
ne devraient être exécutées que plus rarement et de manière asynchrone à la demande de l’opérateur afin
d’éviter un travail inutile au processeur. Ceci n’est possible que si le système de commande est pourvu
d’un mécanisme d’exploitation répondant au concept de multiprogrammation et mettant en oeuvre une
gestion multitâche.
Dans ce cas, chaque fonction principale pourra être définie de manière autonome : certaines comme
tâches de fond (régulation de température et régulation de pression), d’autre comme tâches
d’interruption (changement de paramètres) et d’autres encore comme tâches cycliques (affichage de
l’état du procédé). Bien que corrélées afin de pouvoir communiquer ou de se synchroniser, elles
pourront être exécutées les unes indépendamment des autres. Cet exemple tend à montrer l’intérêt
d’utiliser d’un système d’exploitation multitâche pour mettre en oeuvre une gestion dynamique des
fonctions à accomplir. Ainsi, les fonctions de régulation de température et de pression pourraient être
exécutées en même temps, alors que les fonctions de lecture et d’interprétation, de changement de
paramètres et d’affichage pourraient être exécutées que lorsqu’elles sont nécessaires.

D’autre part, la mise en oeuvre d’une application de ce type doit être précédée d’une modélisation
formelle et globale à l’aide d’un outil de modélisation (GRAFCET, Réseaux de Pétri...) capable de
décrire les évolutions simultanées (parallélisme) et asynchrones de ces fonctions ainsi que leurs
interactions. L’avantage d’une modélisation globale est multiple :
- Elle permet de valider le schéma de synchronisation de l’application et de justifier partiellement

le découpage des tâches (à compléter par l’analyse des données partagées entre les différentes
fonctions),
- Elle permet aussi une mise en oeuvre quasiment directe des interactions entre tâches avec un
débogage aidé par l’existence d’un schéma de synchronisation auquel on peut se référer.
1.2.4. / LES ETATS D’UNE TACHE
Au niveau fonctionnel, c’est-à-dire vue de l’utilisateur, une tâche est soit en cours d’exécution Soit
arrêtée parce que ses données de travail ne sont pas prêtes ou bien parce que son exécution n’est
momentanément pas utile. Au niveau du système d’exploitation d’un calculateur, c’est-à-dire vue du
processeur, une tâche peut passer en fait par quatre états (cf. figure 2.2) : l’état ACTIF, l’état PRET,
l’état EN ATTENTE et l’état SUSPENDU.
1.2.4.1./ L’état ACTIF
Une tâche est active (current state) lorsqu’elle est en train d’être exécutée par le processeur (on dit
aussi «qu’elle a la main »). Dans les systèmes monoprocesseur une seule tâche peut être
active, puisqu’un processeur ne peut travailler qu’avec une seule tâche à la fois. Dans les systèmes
multitâches, la tâche active est choisie par l'algorithme d’ordonnancement des tâches mis en oeuvre par
I ‘allocateur du processeur.
Figure 2.2 : Les états d’une tâche

1.2.4.2./ L’état PRET
Une tâche est prête (ready state) ou éligible lorsqu’elle possède toutes les ressources nécessaires à son
exécution, tant matérielles (mémoires, dispositifs d’entrées-sorties...) que logicielles (données,
message...), sauf le processeur. Elle est donc prête à être exécutée et le sera dés que son tour arrivera ou
dés qu’elle deviendra la tâche la plus prioritaire. C’est parmi l’ensemble des tâches prêtes que
l’allocateur du processeur va choisir la tâche à exécuter. Dans un contexte temps réel, la tâche active est
celle qui a la plus haute priorité parmi les tâches prêtes. Avec un système en temps partagé, la tâche
active est celle qui dispose de la tranche de temps d’exécution à l’instant considèrè.
1.2.4.3./ L’état EN ATTENTE
Une tâche est en attente (waiting state) lorsqu’elle attend un événement. Si une ressource lui manque
(imprimante, espace mémoire...) elle attend une interruption physique (fin d’entrées/sorties, défaut de
page...) ou un message lui signalant que cette ressource vient de lui être attribuée. A part dans les
systèmes temps réel où l’endormissement peut être commandé par une instruction générée par la tâche
d’application active, cet état est entièrement géré par le système d’exploitation.
1.2.4.4./ L’état SUSPENDU
Une tâche est suspendue (suspended state) quand l’utilisateur ne veut plus qu’elle soit en concurrence
avec les autres vis-à-vis du processeur. Une tâche suspendue est donc une tâche que l’utilisateur ne veut
plus avoir dans l’état prêt, mais qui ne peut être en attente car elle dispose de toutes les ressources
nécessaires à son exécution. Elle peut être suspendue dans le cas où elle n’est plus utile momentanément
(tâche d’initialisation, tâche de test ou d’autotest, tâche de maintenance...). Cet état est pris en compte
par le système qu’après l’émission d’un ordre généré par une instruction exécutée par une tâche
d’application.
Remarque : Certains systèmes d’exploitation du type temps réel, gèrent un cinquième état l’état «En
attente - Suspendu ». Cet état hybride est la conséquence de la suspension par une tâche utilisateur
d’une autre tâche utilisateur déjà mise en attente par le système, ou bien de la mise en attente d’une
tâche utilisateur déjà suspendue. Pour devenir prête, une tâche se trouvant dans l’état «en attente-
suspendue » doit recevoir deux informations dont l’ordre d’arrivée n’a aucune importance :
· Une information la prévenant que l’événement qu’elle attendait s’est produit. La tâche passe
alors dans l’état suspendu,
· Une information provenant de la tâche active sous la forme d’un ordre de résomption. La tâche
passe alors dans l’état en attente.

1.2.5. / CHANGEMENT D’ETAT D’UNE TACHE
Dans un système monoprocesseur, une seule tâche est active à un instant donné. Cependant, sur une
période de temps de quelques centaines de millisecondes, un grand nombre de tâches prêtes, suspendues
ou en attente peuvent devenir actives. Les changements d’états sont ainsi très fréquents. Lors d’un
changement d’état, on peut rencontrer l’un des cas suivants illustrés par la figure 2.3
Figure 2.3 : Les changements d’état d’une tâche
1.2.5.1./ Création et destruction
Pour être exécutée, une tâche doit tout d’abord faire l’objet d’un ordre de création. Cet ordre de
création émanant soit d’une tâche d’application, soit directement du système, permet de générer
l’ensemble des opérations et des paramètres nécessaires au gestionnaire de tâches pour lancer
l’exécution de la tâche concernée : allocation de l’espace mémoire nécessaire, création du descripteur
de la tâche et de sa pile (cf. §7 de ce chapitre), mise à jour des paramètres du descripteur, insertion du
descripteur dans la liste des tâches prêtes (cf. §6 de ce chapitre)... La création d’une tâche ne peut être
générée que par une tâche active. Créer une tâche ne veut pas dire l’exécuter. Lorsqu’elle est créée, une
tâche est mise dans l’état prêt afin qu’elle puisse s’exécuter quand son tour viendra (selon la politique
d’allocation du processeur mise en oeuvre par le système).
Nous avons vu qu’une tâche a une durée de vie limitée. Pour arrêter définitivement l’exécution d’une
tâche celle-ci doit être simplement détruite. L’ordre de destruction émanant de la tâche active réalise la
suppression de la tâche de toute liste. Cette opération permet au système de récupérer tous les espaces
mémoire qu’occupait la tâche afin de les redistribuer aux autres tâches. La tâche n’apparaissant plus
dans aucune des listes du système est alors inconnue de l’allocateur et nécessitera un nouvel ordre de
création pour être de nouveau exécutée. Une destruction de tâche peut être exécutée quel que soit l’état
de la tâche concernée.

1.2.5.2./ La préhension
Il y a préhension lorsque la tâche active cesse de l’être mais reste dans l’état prêt. Cette tâche
démissionne alors et le système d’exploitation doit élire une autre tâche parmi celles qui sont prêtes. Ce
changement d’état peut se produire du fait :
· D’un événement extérieur à la tâche (interruption de l’horloge temps-réel, événement attendu

par une tâche...) qui nécessite l’exécution d’une tâche associée à cet événement et plus
prioritaire que la tâche active,
· D’un événement provoqué par la tâche active elle-même, tel que, par exemple, l’envoi d’un
message à une autre tâche plus prioritaire qu’elle et qui était en attente de ce message.
1.2.5.3./ L’endormissement
Il y a endormissement lorsqu’une tâche active ou suspendue passe dans l’état en attente. Ce changement
est géré par le gestionnaire de tâches quand :
· Le temps alloué à la tâche active est écoulé et qu’il existe des tâches prêtes. Ce mécanisme, dit
de tranche de temps, est mis en oeuvre sur les systèmes multi-utilisateurs plutôt que sur les
systèmes temps réel,
· La tâche active se met en attente d’un événement. Cet événement peut être un message, une
interruption interne provenant, par exemple de l’horloge temps réel et la prévenant qu un
certain temps s’est écoulé (délai), ou encore une interruption externe (cf. chapitre 3),
· La tâche suspendue est mise en attente par le système qui anticipe sur les besoins en ressources
qui seront nécessaires à son exécution lors de la fin de sa suspension.
1.2.5.4./ La suspension
Il y a suspension lorsque qu’une tâche prête ou en attente passe dans l’état suspendu. Ce changement
d’état est géré par le gestionnaire mais ne peut être généré que sur un ordre de la tâche active.
Il peut se produire soit quand la tâche active se suspend elle-même (autosuspension), ou suspend une
autre tâche, ou encore dans certains cas, quand le système suspend une tâche en attente afin que celle-ci
ne puisse pas s’exécuter à la fin de son attente.

1.2.5.5./ Le réveil
Il y a réveil lorsqu’une tâche en attente devient prête ou redevient dans l’état suspendu après un passage
dans l’état en attente - suspendue. Ce changement d’état se produit quand :
· Un événement externe et attendu, signalé par une interruption, se produit,
· La tâche active provoque elle-même l’événement attendu par une tâche plus prioritaire qu’elle
(tel que l’envoi d’un message),
· Le temps d’attente d’une tâche est écoulé.
1.2.5.6./ La résomption
Il y a résomption lorsqu’une tâche qui était suspendue ou dans l’état en attente et suspendue reçoit un
ordre de réveil de la part de la tâche active, ce changement d’état ne peut se produire que sur l’ordre de
la tâche active et donc être généré soit par une tâche d’application, soit par une tâche du système
d’exploitation.
1.2.5.7./ Notion de contexte
Une tâche peut obtenir le contrôle du processeur, le perdre, l’obtenir de nouveau.., de nombreuses fois
en quelques millisecondes. Un certain nombre d’informations propres à la tâche et nécessaires à son
exécution doivent être sauvegardées lors de la perte du contrôle du processeur, afin d’être restaurées en
cas de reprise de la tâche. Ces informations constituent le contexte de la tâche et sont regroupées sous
le nom de mot d’état (process status word) :
· Le compteur ordinal donnant l’adresse de la prochaine instruction à exécuter,
· Les contenus des registres généraux du processeur,
· Un registre d’état indiquant son statut (prête, en attente, suspendue),
· Les registres décrivant son espace mémoire virtuel,
· Les registres décrivant l’espace mémoire physique qu’elle occupe,
· D’autres informations telles que l’espace mémoire minimum nécessaire à son exécution. les
adresses de ses tâches filles...
Lorsqu’une tâche active s’arrête, le gestionnaire de tâche donne la main à l'allocateur du processeur
dont le rôle consiste à attribuer le contrôle de l’unité centrale, à tour de rôle, aux différentes tâches en
compétition suivant une politique définie à l’avance par les concepteurs du système (temps partagé,
préemption...).

L’allocateur du processeur se charge alors de l’opération de changement de contexte (context

switching) qui consiste en trois opérations :
· Sauvegarde du contexte de la tâche qui s’arrête à partir des différents registres du processeur
utiles au rétablissement de la tâche,
· Sélection parmi les tâches prêtes de la tâche devant alors être exécuter (tâche suivante, tâche
plus prioritaire...),
· Restauration du contexte de la tâche choisie en initialisant les registres du processeur avec le

contexte précédemment sauvegardé.
Le passage effectif du contrôle du processeur à une tâche (passage de la tâche de l’état prêt à l’état
actif) est réalisé par l’opération de commutation du mot d’état. La stratégie d’allocation du processeur
varie beaucoup selon le mode d’exploitation et le degré de sophistication du système (cf. §9 et §10 de
ce chapitre). En général, le contrôle est donné à une tâche prête une fois que la tâche en cours
d’exécution ait été interrompue, suspendue, mise en attente ou se soit terminée naturellement.
1.2.6. / LES LISTES ASSOCIEES AUX ETATS
Pour gérer les changements d’état de manière simple et rapide, à chaque état est associée une liste
contenant l’ensemble des tâches figurant dans l’état correspondant. Sur les systèmes de type
monoprocesseur, il existe en général trois listes la liste des tâches prêtes (LTP), la liste des tâches en
attente (LTA) et la liste des tâches suspendues (LTS).
Il n’existe pas de liste des tâches actives puisque ces systèmes ne peuvent exécuter qu’une seule tâche à
la fois (ce qui est faux dans le cas des systèmes multiprocesseur qui par définition peuvent exécuter
plusieurs tâches simultanément et dont le gestionnaire de tâches gère alors une liste des tâches actives
en plus des trois autres listes). En général, la tâche active se trouve alors en tête de la liste des tâches
prêtes. Chaque tâche du système figure sur une liste et une seule. L’ordre des taches dans ces listes
dépend à la fois de l’instant elles y ont été placées, de leur priorité et des algorithmes mis en oeuvre par
le gestionnaire de tâches. Les tâches les plus prioritaires Sont placées, en général, en tête de liste. Ainsi,
selon la politique d’allocation du processeur, lors d’un changement d’état, une tâche ne sera pas
nécessairement rajoutée en queue de liste mais insérée, par exemple, à un endroit précis dans la liste
selon sa priorité.
Ces listes sont constituées d’éléments répartis liés par un chaînage à l’aide de pointeurs. Un pointeur est
une variable particulière qui, au lieu de contenir directement une information, contient l’adresse du bloc
mémoire où se trouve cette information. Les avantages de cette structure résident dans le fait que les
éléments associés aux tâches conservent toujours la place qui leur a été affectée en mémoire (pas de
déplacement d’espaces mémoire coûteux en temps), et les procédures d’insertion sont simples et
extrêmement rapides (les modifications ne concernant que quelques pointeurs).

Figure 2.4 : Constitution d’une liste à l’a ide de pointeurs
Pour insérer une tâche Tj dans une liste des tâches entre les tâches Ti et Tk, il suffit au gestionnaire de
tâches de modifier, comme le montre la figure 2.4, la valeur de trois pointeurs :
· Le pointeur suite de la tâche Ti doit contenir l’adresse de la tâche
· Le pointeur suite de la tâche tj doit contenir l’adresse de la tache Tk,
· Le pointeur de début de la liste des tâches prêtes doit alors prendre pour valeur, l’adresse de la
tache qui va prendre le contrôle.
1.2.7. / STRUCTURE DES DONNEES ASSOCIEES AUX TACHES
En plus, des données connues et définies par le programmeur de l’application, d’autres sont associées à
chaque tâche. Celles-ci sont nécessaires aux algorithmes mis en oeuvre par les fonctions de gestion de
tâches (allocation du processeur, changement de contexte, manipulation des listes...). Ces données sont
créées par le système d’exploitation qui est alors le seul à pouvoir y accéder. La structure de données
associée à chaque tâche et illustrée par la figure 2.5, est ainsi composée d’une pile et d’un descripteur de
tâche.
1.2.7.1./ La pile
La pile a pour rôle de stocker l’ensemble des données nécessaires à la reconstitution de l’état de la
tâche. Il s’agit essentiellement des valeurs des registres internes du processeur (accumulateurs, le
compteur ordinal...). Lorsqu’une tâche perd le contrôle du processeur, la fonction de sauvegarde de son
contexte, exécutée par l’allocateur du processeur, consiste à ranger toutes les données utiles à la reprise
de cette tâche dans la pile qui lui est associée. Lorsque cette tâche reprendra le contrôle du processeur,
l’allocateur du processeur restaurera Son contexte en copiant, dans les registres concernés, les valeurs
précédemment sauvegardées dans la pile. Ce n’est qu’une fois cette restauration de contexte réalisé que
la tâche pourra prendre la main.
Afin de rendre plus souples les fonctions du gestionnaire de mémoire, les piles sont des éléments
répartis pouvant donc être logés n’importe où en mémoire (là où il reste de la place). Chaque pile est
liée à son descripteur par l’intermédiaire d’un pointeur (cf. figure 2.5).

Figure 2.5: Ordonnancement des données associées aux tâches
1.2.7.2./ Le descripteur de tâche
Le descripteur de tâches contient des paramètres utilisés par l’allocateur du processeur pour gérer les
changements d’états des tâches et former les listes (cf. figure 2.5). Le nombre de paramètres contenus
dans le descripteur dépend de la complexité du système d’exploitation. On y trouve généralement les
éléments de base suivants :
· Le statut contient l’état présent de la tâche : actif, prêt, en attente, suspendu...
· La priorité sert à l’ordonnancement des tâches dans la liste des tâches prêtes. Elle est en
générale identifiée par un numéro,
· Délai représente un délai d'endormissement ou un temps d’attente maximum,
· Le code représente le code exécutable de la tâche et les données,
· L’adresse de la pile, la longueur de la pile et le pointeur de pile permettant la localisation de la

pile en mémoire,
· Le pointeur de liste assure le chaînage des descripteurs de tâches dans la liste des tâches prêtes
ou dans celle des tâches suspendues. On y trouve généralement l’adresse du descripteur de la
tâche suivante dans la liste,
· Le pointeur d’attente joue le même rôle que le pointeur de liste dans le cas de la liste des tâches
attente...

Le système peut facilement identifier la liste dans laquelle figure une tâche en consultant le paramètre
statut de son descripteur. Deux cas peuvent se présenter alors la tâche est en attente ou elle n’y est pas.
Lorsqu’elle n’est pas en attente, son pointeur de liste indique alors l’adresse de la tâche suivante dans la
liste des tâches prêtes, si la tâche est dans l’état prêt, ou dans la liste des tâches suspendues, si elle est
dans l’état suspendu. Dans le cas ou la tâche est en attente, le pointeur d’attente de son descripteur
donne alors l’adresse du descripteur de la tâche suivante dans la liste des tâches en attente.
La liste des tâches en attente est généralement traitée à part car la plupart des moniteurs prévoient
l’association d’un temps d’attente maximum (éventuellement infini) quel que soit l’événement attendu
(cf. §8.3 de ce chapitre).
1.2.8. / TRAITEMENT DU TEMPS
Quels que soient le type et la nature d’un système d’exploitation, un gestionnaire de tâches nécessite
toujours une connaissance précise du temps, afin par exemple :
· De rythmer le travail du ou des processeurs du système,
· De mettre en oeuvre des mécanismes de partage du processeur par tranches de temps,
· D’activer périodiquement des tâches,
· D’enregistrer l’heure exacte à laquelle certains événements se sont produits,
· De mettre certaines tâches en attente de synchronisation d’une application temps réel,
· De synchroniser le travail des différents processeurs (systèmes multitraitement),
· De gérer des mécanismes du type chien de garde (watch dog) afin d’interrompre une attente
trop longue ou délai de garde (timeout) pour interrompre des tâches qui ne sont pas terminées
après un certain délai d’exécution...
La mesure du temps est basée sur la génération de signaux électroniques déclenchés par les circuits
d’horlogerie du système informatique.
1.2.8.1./ Les interruptions d’horloge interne
Tout système informatique dispose d’une horloge interne (dock) dont la fréquence (proportionnelle à la
fréquence de l’oscillateur à quartz utilisé par le système 16 Mhz, 33 Mhz, 66 Mhz...) est généralement
connue aussi bien par le système que par l’utilisateur. Cette horloge (cf. figure 2.6) est un métronome
électronique dont le rôle est de cadencer le travail du processeur.

Figure 2.6: Génération de l’horloge temps-réel et calibrage de la base de temps
A chaque top (dock tick) ou cycle de cette horloge une opération du processeur est générée. Une
opération de base (accès mémoire, addition...) nécessite un certain nombre de tops d’horloge. Ainsi,
plus la fréquence de l’horloge interne est élevée plus la quantité de travail que peut accomplir un
système informatique pendant une durée déterminée augmente.
1.2.8.2./ L’horloge temps réel
Pour évaluer le temps qui s’écoule et être ainsi capable de gérer finement le temps, la plupart des
systèmes d’exploitation utilisent le comptage d’impulsions de l’horloge interne. Le calibrage des
impulsions de cette horloge permet de définir sa période appelée également base de temps du système.
Cette base de temps peut être modifiée et programmée (cf. figure 2.6). Elle se situe généralement entre
0,1 microsecondes et 100 millisecondes.
Sa programmation permet de définir le nombre de tops d’horloge interne nécessaires au déclenchement

d’une interruption dite de l’horloge temps réel (real time dock). Cette interruption est une interruption
de très haut niveau qui nécessite un traitement très court et très rapide afin que les autres interruptions
ne restent pas masquées trop longtemps (cf. chapitre 3). L’horloge temps réel d’un système aide à
garantir des temps de réponse acceptables dans un système interactif, évite au système de rester
monopolisé dans une boucle de programme et permet en outre de traiter des applications en temps réel.
1.2.8.3./ Traitement des attentes
Le paramètre « Délai » du descripteur de tâche en attente mémorise pour chaque tâche le temps
d’attente maximum pour une ressource ou encore son temps d’endormissement. Ce paramètre est
décrémenté à chaque top de l’horloge temps réel. Lorsqu’il vaut zéro la tâche est mise automatiquement
dans la liste des tâches prêtes. Ainsi, l’ordre des tâches dans la liste des tâches en attente a une grande
importance.

Effectivement, si les tâches étaient rangées dans cette liste dans un ordre quelconque ou encore par
ordre de priorité, chaque interruption de l’horloge temps réel nécessiterait pour toutes les tâches en
attente : une décrémentation de leur paramètre délai, un test à zéro de ce paramètre et, selon la valeur
de ce test, un changement d’état de la tâche concernée. Le traitement de l’interruption de l’horloge
temps réel serait alors beaucoup trop coûteux en temps d’exécution et dépendrait, de plus, du nombre
de tâches en attente.
Pour augmenter l’efficacité du système les tâches sont en fait rangées dans l’ordre des délais d’attente
croissants. Le paramètre délai contient alors le supplément d’attente vis à vis de la tâche précédente
dans la liste. Ainsi, quel que soit le nombre de tâches dans la liste des tâches en attente, seul le
paramètre délai de la tâche en tête de cette liste est décrémenté à chaque top d’horloge temps réel. Dès
que ce paramètre atteint la valeur zéro, le temps d’attente de la tâche est écoulé.
La tâche est alors de nouveau prête à être exécutée. Elle doit donc quitter la liste des tâches en attente
pour entrer dans la liste des tâches prêtes. La tâche qui se trouvait en deuxième position dans la liste des
tâches en attente passe alors en tête de cette liste et c’est alors son paramètre délai qui sera décrémenté
au prochain top de l’horloge temps réel.
Dans l’exemple de la figure 2.5, la tâche Ti doit encore attendre 50 unités de temps avant de redevenir
prête. Les tâches Tj et Tk devront attendre, quant à elles, respectivement 110 unités et 205 unités. Dès
que le paramètre délai d1, de Ti vaudra zéro, Ti sera insérée dans la liste des tâches prêtes. Tj se
retrouvera alors en tête de la liste des tâches en attente avec un délai dj de 60 unités de temps d’attente
supplémentaire, par rapport à Ti.
Le paramètre délai dj serra décrémenté d’une unité au top d’horloge temps réel suivant. Dès que dj
vaudra zéro, la tâche Tj serra placée dans la liste des tâches prêtes et la tâche Tk se retrouvera alors en
tête de la liste des tâches en attente avec un délai d’attente supplémentaire Tk de 95 unités de temps.
L’algorithme mis en oeuvre, lors de l’insertion d’un descripteur de tâches dans la liste des tâches en
attente est présenté figure 2.7, avec :
· i : le rang d’une tâche dans la liste des tâches en attente,
· di: le paramètre délai de la tâche de rang i,
· Tj: la tâche à insérer dans la liste des tâches en attente,
· dj: le paramètre délai de la tâche à insérer,
· Si: la valeur de la somme des délais au rang i.

Insertion en liste d’attente
Début
iß0
Si ß 0
Répéter
•ißi+1
• Si <— Si+ di
Jusqu’à Si > di
di. ß dj -Si-1
di ß di - dj
Pointeur d’attente de Ti-1 ß Adresse de Tj.
Pointeur d’attente de Tj ß Adresse de Ti
Fin
Figure 2.7: Algorithme d’insertion d’une tâche en liste d’attente
Cet algorithme réalise la sommation des délais d’attente d, en avançant tâche par tâche dans la liste des
tâches en attente. La place du descripteur est localisée dés que la somme des délais S, est supérieure à la
valeur du paramètre délai dj du descripteur concerné. Le système doit alors mettre à jour ce paramètre
dj ainsi que le paramètre délai di de la tâche qui suit la tâche Tj dans la liste des tâches en attente. Il
suffit alors de mettre en oeuvre le chaînage des pointeurs d’attente pour terminer l’opération
d’insertion. Le traitement de la tâche d’insertion peut être coûteux en temps d’exécution dans la mesure
où il dépend du nombre de tâches en attente. Ce temps de traitement n’a néanmoins qu’une importance
relative dans la mesure où la tâche d’insertion n’opère pas sur interruption.
LTA T2 T3 T1
d1=200 d2=300 d3=300
(i=1) (i=2) (i=3)
T4
i 1 2 3
Si 200 500 1000 dj=200
Exemple d’ajout d’une tâche T4 dans une liste des tâches en

attente.T4 doit s ‘endormir pendant 7s. Avec 1000 tops d’horloge
correspondant à 1s on a dj=200 pour T4. Dans LTA, on
a déjà T2, T3, et T1 qui ont respectivement un délais d’attente
de 2s, 5s, et 10s.

1.2.9. / ALLOCATION DU PROCESSEUR
Le gestionnaire de tâches d’un système d’exploitation possède un allocateur de processeur (dispatcher

ou job-controller ou encore scheduler). Son rôle est d’attribuer le contrôle de l’unité centrale aux
différentes tâches en compétition en mettant en oeuvre une politique d’allocation propre à chaque
système. L’allocateur du processeur dispose d’un algorithme de choix (cf. figure 2.8) qui met en oeuvre
une politique d’ordonnancement des tâches selon le type de travail que nécessite chacune d’elles
(entrées-sorties, calculs...) et de telle sorte que chaque utilisateur ait l’impression que son travail avance
régulièrement.
Comme le montre la figure 2.8, seules les tâches prêtes sont en compétition pour obtenir le contrôle du
processeur. Une seule d’entre elles sera choisie par l’allocateur et sera dite alors élue. Elle gardera le
contrôle de l’unité centrale pendant un certain temps dépendant fortement de la politique d’allocation
mise en oeuvre. Lorsque ce temps d’exécution est écoulé, la tâche élue perd alors la main et retourne
alors soit dans la liste des tâches prêtes, soit dans une des autres listes selon son statut.
Figure 2.8 . Attribution du contrôle du processeur
1.2.9.1./ Objectifs de l’allocation
La mise en oeuvre d’une politique d’allocation du processeur doit répondre pour le système
d’exploitation aux objectifs suivants :
· Etre équitable dans le partage si toutes les tâches doivent être considérées de la même manière
(cas des systèmes multi-utilisateurs),
· Mettre en oeuvre les priorités et éventuellement les réajuster dynamiquement,
· Faire en sorte de satisfaire le plus grand nombre de demandes par unités de temps,
· Prendre en charge le maximum d’utilisateurs interactifs tout en leur assurant des temps de
réponse acceptables,
· Exécuter une même tâche dans un temps à peu près équivalent quelle que soit la charge du
système,

· Favoriser les tâches peu exigeantes en nombre de ressources,
· Ne pas accepter de nouveaux travaux lorsque le système est en surcharge,
· Etre la moins coûteuse possible pour ne pas éprouver les performances du système...
La liste de ces objectifs est loin d’être exhaustive, ce qui dénote une grande complexité dans la
détermination de la tâche active et qui est justement en complète opposition avec le dernier point lié à la
performance du système. Ces objectifs ont pour but d’optimiser le rendement du système informatique
dans le cadre de systèmes mettant en oeuvre le concept de multiprogrammation.
1.2.9.2./ Critères d’allocation
L’optimisation du rendement d’un système informatique sous-entend des règles d’ordonnancement des
tâches qui prennent en compte efficacement des critères d’allocation. Pour réaliser tout ou partie des
objectifs de l’allocation du processeur, le mécanisme d’ordonnancement d’un système d’exploitation
doit considérer :
· Le taux d’utilisation du processeur pour chaque tâche,
· Le taux des entrées/sorties de chaque tâche,
· Le taux de défaut de pages pour chaque tâche : certaines politiques d’allocation tendent à
favoriser les processus ayant un taux de défaut de pages faible car la place mémoire qui leur est
allouée suffit à contenir leur espace de travail (cf. chapitre 5),
· Le degré d’urgence de la tâche qui est lié à la nature du système (une tâche d’un procédé temps
réel nécessite des réponses très rapides alors que les tâches d’un système batch ne requièrent
pas de réponses immédiates),
· Le fonctionnement interactif ou par lot : les utilisateurs interactifs émettent en général des
requêtes simples devant être satisfaites très rapidement, alors que les utilisateurs batch n’étant
pas présents peuvent subir des délais (devant toutefois restés raisonnables),
· La priorité des tâches : les tâches de forte priorité doivent bénéficier d’un meilleur traitement
que les tâches de priorité plus faible,
· Le taux de réquisition du processeur qui est très lié à la priorité de la tâche concernée (plus la
priorité est faible, plus il est élevé) et qui permet d’éviter des temps de commutation en pure
perte lors de forte probabilité de réquisition,
· Le temps d’utilisation restant qui permet de restreindre le temps d’attente de tâches prêtes en
exécutant de préférence les tâches réclamant un temps d’exécution minimum pour s’achever.

1.2.9.3./ Les priorités
Les priorités peuvent être allouées automatiquement par le système ou de manière externe par
l’utilisateur. Elles peuvent être allouées de manière rationnelle ou arbitraire, en particulier lorsque le
système est contraint de faire une distinction entre plusieurs tâches sans avoir les moyens d’être sûr de
faire le bon choix. Ceci engendre deux types de priorité :
· Les priorités statiques qui, par définition, ne changent pas une fois allouées. C’est le cas des
applications temps-réel pour lesquelles les priorités sont définies par le programmeur en
fonction de l’ensemble des tâches de l’application et par rapport à leur degré d’urgence. Elles
ne peuvent en aucun cas être modifiées par le système d’exploitation qui ne connaît pas les
tenants et aboutissants de chacune des tâches de l’application. Elles sont, par contre,
insensibles aux changements survenus dans l’environnement et nécessitant, dans certains cas,
un ajustement des priorités.
· Les priorités dynamiques qui peuvent changer en fonction des modifications de

l’environnement. Leur gestion est beaucoup plus complexe et engendre des coûts plus grands
que ceux engendrés avec des priorités statiques. Par contre, leur emploi permet d’accroître
considérablement le débit et la souplesse du système.
1.2.10./ MECANISMES D’ORDONNANCEMENT
Le choix de la tâche à laquelle le système va donner la main, c’est-à-dire celle qui va être allouée au
processeur, est réalisé par un algorithme dit d’ordonnancement. Cet algorithme de choix utilise un
certain nombre de paramètres pour prendre des décisions :
· L’état de chaque tâche correspondant à son statut,
. La priorité associée à chaque tâche (de nombreux algorithmes utilisent les notions de priorité
de base et la priorité actuelle),
· La tranche de temps qui représente le temps maximum pendant lequel une tâche peut garder la
main sans ré-exécution de l’algorithme de choix...
Les différents algorithmes d’ordonnancement utilisent les structures de listes que nous avons vues
précédemment et mettent en oeuvre deux concepts importants :
· Le concept d’événement significatif (fin d’une entrée/sortie, interruption d’horloge indiquant la

fin d’une tranche de temps...) qui, lorsqu’il survient, provoque obligatoirement l’exécution par
le système de l’algorithme de choix,
· Le concept de préemption lorsqu’une tâche importante (de haute priorité) passe dans l’état
prêt. l’algorithme de choix doit décider d’arrêter l’exécution de la tâche en cours (même si elle
n’a pas épuisé sa tranche de temps) pour passer la main à la tâche prioritaire.

Le mécanisme de choix peut être plus ou moins complexe selon qu’il opère sur réquisition du
processeur ou non, ou encore qu il prenne en compte la notion de priorité statique ou de priorité
dynamique.
1.2.10.1./ Algorithmes sans réquisition
Les algorithmes d’ordonnancement sans réquisition ne permettent pas au système de retirer le contrôle à
une tâche dés lors que le processeur lui a été attribué. Ainsi, la tâche élue ne rendra la main que
lorsqu’elle sera complètement achevée.
Le principe de la non-réquisition est gênant pour les travaux courts lorsqu’ils doivent attendre qu’un
travail très long s’achève. Il reste néanmoins équitable du fait que les travaux à forte priorité ne viennent
pas perturber l’ordre des travaux en attente.
Parmi les algorithmes mettant en oeuvre une politique de non-réquisition nous avons retenu les deux
principaux.
1.2.10.1.1./ Ordonnancement par ordre d’arrivée (FIFO)
La technique d’ordonnancement par ordre d’arrivée est la manière la plus simple et la plus naturelle
d’ordonnancer les tâches à exécuter. Elle consiste à choisir la tâche qui est depuis de plus long temps
dans la liste des tâches prêtes.
Cette politique (premier arrivé, premier servi) revient à organiser la liste de tâches prêtes comme une file
d’attente du type FIFO (First In First Out). Cette file est unique et les tâches y sont gérées sans prendre
en compte leur priorité.
Figure 2.9 : Ordonnancement FIFO de la liste des tâches prêtes
Ainsi, le descripteur d’une tâche arrivant dans la liste des tâches prêtes est ajouté en queue de liste (cf.
figure 2.9). Dès que le processeur est libre, l’algorithme d’ordonnancement choisit alors simplement la
tâche dont le descripteur se trouve en tête de la liste pour lui donner le contrôle. Les tâches en fin
d’exécution sont détruites par le système par leur suppression. de la liste des tâches prêtes.

1.2.10.1.2./ Ordonnancement « Plus court d’abord»
La politique d’ordonnancement dite «Plus court d’abord» (SJF : Shortest Job First) est une technique
sans réquisition dans laquelle la tâche ayant le plus faible temps estimé d’exécution jusqu’à achèvement
est prioritaire. Les travaux à exécuter sont alors ordonnés dans la liste des tâches prêtes selon leur temps
de service supposé connu à l’avance. Les travaux les plus courts sont classés en tête de liste. Cette
méthode d’ordonnancement favorise donc les travaux brefs au détriment des travaux les plus
importants. Le but de cet algorithme consiste à achever dès que possible les petits travaux. Ceci à pour
conséquence de diminuer le nombre de travaux en attente du processeur dans la liste des tâches prêtes
et ainsi à diminuer la moyenne des temps d’attente des tâches dans cette liste. Sur le plan pratique, cet
algorithme présente deux inconvénients :
. Il y a un risque non négligeable de privation du processeur pour les travaux longs si le taux
d’arrivée des travaux courts est élevé. Un moyen d’y remédier consiste à attribuer à chaque
tâche prête une priorité croissante avec le temps de séjour dans la liste des tâches prêtes,
. Il nécessite une connaissance exacte a priori des temps de service. L’évaluation de ce temps
d’exécution peut être correcte dans des environnements de production (cas des applications
temps réel) mais s’avère rarement possible dans les environnements de développement.
1.2.10.2./ Algorithmes avec réquisition
Les algorithmes d’ordonnancement avec réquisition permettent au système de retirer à tout moment le
contrôle à une tache active. Le principe de la réquisition est absolument nécessaire tant sur les sites
supportant des applications temps réel que sur les systèmes multi-utilisateurs. Cette technique est
indispensable dans les systèmes interactifs à cause des fortes contraintes de temps de ces systèmes.
Néanmoins, la réquisition engendre un surcoût non négligeable à l’exploitation occasionné
principalement par les changements de contextes incessants mais également par l’ensemble des
mécanismes liés au principe de multiprogrammation mis en place sur la plupart de ces systèmes.
1.2.10.2.1./ Ordonnancement « Plus court temps restant »
L’algorithme d’ordonnancement «Plus court temps restant » (SRT . Shortest Remaining Time) est la
version avec réquisition de l’algorithme «Plus court d’abord» (SJF). Avec cette technique, la priorité est
donnée à la tâche dont le temps d’exécution restant est le plus faible. Cette méthode permet donc
d’interrompre une tâche active au profit d’une nouvelle tâche ayant un temps d’exécution estimé plus
court que le temps nécessaire à l’achèvement de la tâche qui est interrompue. Le coût d’exécution de
cet algorithme est supérieur à celui occasionné par l’algorithme SJF. En effet, il doit tenir compte du
temps déjà alloué aux tâches en cours et effectuer immédiatement les commutations à chaque arrivée
d’un travail dont le traitement est plus court que celui de la tâche active. La tâche interrompue pourra
être relancée ensuite, à moins qu’un travail encore plus court intervienne.
L’algorithme SRT appelle les mêmes remarques que l’algorithme SJF, concernant son implantation.
Mais il fournit, néanmoins, la valeur optimale de la durée moyenne de traitement, pour l’ensemble des
algorithmes d’ordonnancement avec réquisition.

1.2.10.2.2./ Le tourniquet
L’algorithme d’ordonnancement par tourniquet (round robin) s’inspire de la technique FIFO et ne tient
pas compte des priorités. Les tâches prêtes sont rangées dans la liste de tâches prêtes gérée, dans ce cas,
sous la forme d’une liste circulaire. L’allocateur du processeur alloue le contrôle à la tâche en tête de
liste pour un temps donné, appelé quantum. Lorsque ce temps d’exécution expire avant l’achèvement de
la tâche active, celle-ci est placée en queue de liste (cf. figure 2.10) et le contrôle est alors donné à la
tâche suivante dans la liste pour, en principe, le même quantum.
Figure 2.10: principe d’ordonnancement par tourniquet
Cette technique est principalement mise en oeuvre dans les systèmes multi-utilisateurs où les
applications interactives doivent bénéficier de temps de réponse corrects et équitables (contrairement
aux applications temps réel devant elles être gérées d’après leur niveau d’urgence définie par leur
priorité). Le coût de la réquisition peut être maintenu faible si les mécanismes de commutation sont
efficaces et la mémoire suffisante pour contenir plusieurs tâches en même temps. Il est à noter qu’un
réglage judicieux du quantum permet d’accroître le taux d’utilisation du processeur et de diminuer ainsi
les temps de réponse.
Avec cette méthode, le temps de réponse maximum (temps d’attente d’une tâche dans la liste des tâches
prêtes avant d’obtenir le contrôle du processeur) est donné par:
Tr = NbT * Q où NbT représente le nombre de tâches prêtes et Q le quantum.
Le tourniquet garanti ainsi Q secondes de service toutes les NbT * Q secondes. Le produit NbT * Q
peut devenir grand lorsque la charge du système augmente. Ainsi, avec, par exemple, Q = 0,1 seconde
et NbT = 30 tâches, le temps de réponse maximum est alors de 3 secondes. Pour pallier ce problème,
certains systèmes utilisent alors un dérivé : le tourniquet à cycle fixe (cyclic round robin).

Avec ce tourniquet, le quantum Q est choisi par le système et le nombre de tâches prêtes donne le temps
de réponse Tr Le système choisit alors le temps de réponse Tr et le quantum Q est donné par :
Q = Tr / NbT où Tr est le temps de réponse et NbT représente le nombre de tâches.
L’inconvénient de ce mécanisme est que si NbT est très grand, Q devient très petit et le temps de
changement de contexte devient très important par rapport à Q.
1.2.10.2.3./ Ordonnancement par priorité
La méthode d’ordonnancement par priorité (highest priority first) réalise le classement des tâches par
ordre croissant de priorité dans la liste des tâches prêtes. Pour choisir une tâche prête à exécuter, ou
pour reprendre son exécution, le système va alors toujours prendre la tâche qui se trouve en tête de
liste. Cette tâche sera exécutée et gardera le contrôle du processeur soit jusqu’à ce qu’elle se termine,
soit jusqu’à ce qu’elle se bloque (mise en attente, auto-suspension, destruction...). L’entrée dans la liste
de tâches prêtes d’une tâche de priorité supérieure à celle de la tâche active constitue un événement
significatif Cet événement provoque l’exécution de l’algorithme de choix qui doit alors interrompre la
tâche active pour donner le contrôle à cette tâche de plus haute priorité en effectuant la commutation du
contexte. La tâche interrompue est alors renvoyée dans la liste des tâches prêtes (en général en
deuxième position).
Ces algorithmes sont principalement implantés dans les systèmes d’exploitation temps réel où
l’allocation du processeur ne doit pas être équitable mais doit répondre à un souci d’un ordonnancement
de tâches permettant de réaliser un objectif commun (tel que la commande d’un procédé physique).
Dans ce type d’application, on considère que la tâche active correspond au travail courant nécessaire à
la réalisation de cet objectif. Avec ce type d’ordonnancement il n’y a pas de notion de tranche de temps
la tâche la plus prioritaire s’exécutera pendant tout le temps où elle restera la plus prioritaire. Plus une
tâche a un niveau de priorité élevé, plus elle fournira des résultats rapidement, dans la mesure où elle
risque d’être beaucoup moins souvent interrompue qu’une tâche de priorité basse.
Dans les systèmes multi-utilisateurs le service rendu par le système doit être équitable pour la majorité
des utilisateurs. Néanmoins, il doit être possible d’accepter qu’un usager bénéficie d’un traitement
particulier. Celui-ci ayant, par exemple, un travail particulièrement urgent peut désirer payer un
supplément de service pour acquérir une priorité plus forte afin que son application soit exécutée plus
rapidement. Ces priorités sont appelées priorités acquises. Elles sont fortement utilisées par les
personnels responsables de l’équipement informatique lors, par exemple des phases de maintenance.
Dans ces conditions, à chaque tâche est affecté un numéro de priorité pouvant être fixe (priorité
statique) ou, au contraire, pouvant évoluer dans le temps (priorité dynamique). L’affectation de
priorités fixes présente des risques de famine une tâche de faible priorité risque de ne jamais être
exécutée si des tâches plus prioritaires se présentent constamment. Pour éviter le risque de famine le
système doit être capable de gérer des priorités dynamiques. L’affectation de priorités dynamiques
nécessite de recalculer périodiquement le numéro de priorité des tâches prêtes non exécutées.

Le système peut alors augmenter périodiquement d’une unité le numéro de priorité de toutes les tâches
prêtes. Ce calcul s’effectue à la fin de chaque quantum, lorsque l’interruption d’horloge redonne le
contrôle à l’algorithme d’ordonnancement qui choisira alors la tâche la plus prioritaire. Ainsi, une tâche
initialisée avec un niveau de priorité faible, pourra atteindre au bout d’un certain temps un niveau de
priorité qui lui permettra d’être élue.
1.2.10.2.4./ Ordonnancement par files multiples
Afin de réduire l’attente du processeur de certaines tâches prêtes, sans avoir à abaisser la valeur du
quantum et ainsi produire un surcoût dû aux nombreux changements de contexte, les algorithmes
d’ordonnancement par files multiples répartissent les tâches prêtes dans plusieurs files. Ces algorithmes
gèrent alors chaque file à l’aide d’un tourniquet, en associant à chacune d’elle un numéro de priorité
statique et des quanta de temps différents. Il existe deux variantes à ce type de traitement.
1.2.10.2.4.1./ Les files prioritaires
Avec ce type de traitement, la répartition du temps processeur entre les files est réalisée
proportionnellement à leur priorité (cf. figure 2.11). Ainsi, la file de plus haute priorité peut recevoir un
quantum correspondant par exemple à 60% du temps d’unité centrale, la suivante un quantum de 30%,
etc. Chaque file représente une liste de tâches prêtes. Pour exécuter les tâches prêtes, l’allocateur du
processeur suit l’ordre d’exécution représenté sur la figure 2.11 par les flèches en pointillés.
Tourniquet
file 1
Séquencement
du Tourniquet
Tourniquet
Séquencement des file 2
tâches actives
Tourniquet
file 3
Figure 2.11 : Ordonnancement utilisant plusieurs files de priorité différentes

Chaque file est alors gérée par un algorithme d’ordonnancement spécifique au type des tâches qui sont
censées s’y trouver. Les tâches qui ne supportent pas une attente trop longue (par exemple les tâches
système) sont placées dans la file disposant du plus grand temps d’unité centrale. Pour lutter contre le
phénomène de famine, les niveaux de priorité des tâches peuvent être traités dynamiquement.
L’allocateur du processeur doit alors augmenter régulièrement le numéro de la priorité associé aux
tâches non encore exécutées et organiser la remontée de ces tâches des files de bas niveau vers les files
de plus haut niveau.
1.2.10.2.4.2./ Les files rétroactives
Cette méthode d’ordonnancement, appelée également tourniquet multi-niveau, consiste à ordonner

hiérarchiquement les différentes files (cf. figure 2. 12).
Figure 2.12 : Ordonnancement par files rétroactives
Elle utilise n files F1 à Fn. A chaque file Fi est associée un quantum Qi dont la valeur croît avec i. Une
tâche d’une file Fi ne peut être élue par l’allocateur que si les files de niveau inférieur à i sont toutes
vides. Lorsqu’une tâche issue de Fi a épuisé son quantum sans être terminée, elle entre dans la file Les
tâches issues de Fn retournent dans Fn après épuisement de leur quantum. Toute nouvelle tâche entre
dans Fi.

1.2.11./ LES PROCEDURES DE GESTION DE TACHES
La gestion des tâches est réalisée par deux types de procédures les procédures de base qui sont
transparentes à l’utilisateur et les procédures de haut niveau qui sont accessibles à l’utilisateur. Ces
procédures sont présentées ici de manière générique (les noms cités le sont simplement à titre
d’exemple) et non exhaustive (elles sont plus ou moins nombreuses selon le type du gestionnaire de
tâches).
1.2.11.1./ Les procédures de base
Les procédures de base sont utilisées par le système d’exploitation pour mettre en oeuvre la gestion des
listes associées aux états des tâches et l’ordonnancement des tâches dans ces listes. Parmi les plus
courantes on rencontre :
· INSERER : qui permet d’insérer le descripteur d’une tâche au bon endroit dans n’importe
quelle des listes traitées par le gestionnaire, en fonction de différents critères : priorité, ordre
d’attente, délais d’attente...
· INSERER_H : qui effectue l’insertion d’un descripteur de tâche directement en tête de liste,
pour la liste des tâches suspendues et la liste des tâches en attente, ou derrière la tâche active
(c’est-à-dire en deuxième position) pour la liste des tâches prêtes. Les listes formées àl’aide de
cette procédure sont gérées sous forme de piles du type LIFO (Last In First Out).
· AJOUTER : qui réalise l’ajout d’un descripteur de tâche directement en queue d’une des
listes traitées par le système. Les listes formées à l’aide de cette procédure sont gérées sous la
forme d’une file d’attente du type FIFO (First In First Out).
· ENLEVER : qui permet d’enlever un descripteur de tâche d’une des listes du système. Cette
opération doit être réalisée avant chaque insertion (une tâche ne peut être insérée dans une liste
que si elle est au préalable enlevée d’une autre liste) ou lors de chaque destruction.
· ORDONNER (schedule) : qui permet de classer les différentes listes gérées par le
gestionnaire de tâches selon divers critères qui dépendent de la politique d’ordonnancement et
d’allocation du système :
- Lancée par l’allocateur du processeur et appliquée sur la liste des tâches prêtes. elle
permet, de déterminer à chaque démission qu’elle est la tâche qui doit être alors élue,
- Lancée et appliquée sur la liste des tâches en attente, elle permet de classer cette liste,
par exemple par ordre d’arrivée ou encore par délais d’attente supplémentaires...
· TRANSFERER (dispatch) : qui permet au gestionnaire de tâches de lancer la tâche qui passe
dans l’état actif (tâche en général se trouvant en tête de la liste des tâches prêtes après
l’exécution de la procédure ORDONNE). Pour réaliser cette opération, cette procédure
déclenche l’opération de commutation du mot d’état (cf. §5.7 de ce chapitre), c’est-à-dire la
sauvegarde du contexte de la tâche qui démissionne, s’endort ou se suspend, et la restauration
du contexte de la tâche élue.

1.2.11.2./ Les procédures de haut niveau
Les procédures de haut niveau sont fournies par le système d’exploitation à l’utilisateur afin de lui
permettre de concevoir, définir et mettre en oeuvre une application multitâche. Elles sont appelées par
les tâches d’application pour exprimer la synchronisation et la communication et dans certains cas la
mise en attente et la suspension. Ces procédures sont accessibles à l’utilisateur au moyen de primitives
(procédures exécutées de manière ininterruptible). Les plus courantes sont les suivantes :
· CREER (Ti, Priorité, Pile, Statut...) : permet de créer la tâche Ti et d’initialiser les
paramètres nécessaires à sa gestion. Lors de son exécution, le gestionnaire de tâches fait appel
au gestionnaire de mémoire (cf. chapitre 5) afin d’allouer un emplacement mémoire au
descripteur de la tâche Ti. Ce descripteur est alors inséré dans la liste des tâches prêtes et sa
position dans cette liste dépend de l’algorithme d’ordonnancement. Créer une tâche ne signifie
pas exécuter la tâche : la tâche créée ne sera exécutée que lorsque son descripteur se trouvera
en tête de la liste des tâches prêtes. Néanmoins, son exécution peut provoquer, selon la
politique d’allocation du processeur, le déclenchement de l’algorithme de choix de l’allocateur
afin de vérifier si la tâche nouvellement créée ne nécessite pas une exécution immédiate.
· DETRUIRE (Ti) : permet la destruction d’une tâche, c’est-à-dire l’arrêt de son exécution. Elle
provoque la libération de l’espace mémoire qui avait été affecté à Ti lors de sa création et la
disparition de toute liste de son descripteur. Si le paramètre Ti représente la tâche active, il y a
alors autodestruction de Ti. L’exécution d’une autodestruction provoque nécessairement le
déclenchement de l’algorithme de choix de l’allocateur du processeur afin d’élire une nouvelle
tâche à exécuter.
· ATTENDRE (événement) : permet à une tâche de se mettre en attente de l’événement précisé

en paramètre. La tâche active lançant cette primitive perd la main, prend l’état en attente. Cette
opération est réalisée par l’insertion du descripteur de la tâche active dans la liste des tâches en
attente et le déclenchement de l’algorithme d’allocation afin d’élire une nouvelle tâche à
executer.
· SIGNALER (événement) : permet de réveiller une tâche en attente en lui signalant la

réalisation de l’événement attendu par cette tâche et précisé en paramètre. L’exécution de cette
primitive provoque l’insertion du descripteur de la tâche réveillée dans la liste des tâches
prêtes, si la tâche était simplement en attente, ou encore son insertion dans la liste des tâches
suspendues, si la tâche était dans l’état «en attente-suspendu ». Selon la politique d’allocation
du processeur mise en oeuvre, l’algorithme de choix sera ou ne sera pas déclenché afin de
vérifier si la tâche nouvellement insérée ne nécessite pas une exécution immédiate.
· ENDORMIR (délai) : réalise l’arrêt de la tâche active pendant un certain temps précisé par la
valeur du paramètre délai (auto-endormissement). L’exécution de cette primitive provoque la
perte du contrôle du processeur pour la tâche active et l’insertion de son descripteur dans la
liste des tâches en attente. Le paramètre délai du descripteur est alors mis à jour en fonction de
la valeur du paramètre d’appel de cette primitive et de la politique de gestion des attentes mise
en oeuvre par le gestionnaire de tâches.

Dans certains systèmes, en particulier dans les systèmes temps réel, une tâche peut également
en endormir une autre alors précisée par un second paramètre.
· SUSPENDRE (Ti) : effectue la suspension ou l’auto-suspension de la tâche Ti précisée en

paramètre d’appel. Cette opération ne peut être commandée que par la tâche active. Elle
provoque le transfert du descripteur de la tâche Ti de la liste des tâches prêtes ou de la liste de
tâches en attente vers, respectivement, la liste des tâches suspendues ou la liste des tâches dans
l’état «en attente-suspendue» (si le système gère ce type d’état et que la tâche à suspendre est
déjà dans l’état en attente). Lorsque le paramètre d’appel Ti identifie la tâche active, il y a alors
auto-suspension. Le descripteur de la tâche active est alors inséré dans la liste des tâches
suspendues et l’algorithme de choix de l’allocateur du processeur est déclenché afin d’élire une
nouvelle tâche.
· DESUSPENDRE (Ti) : réalise la dé-suspension de la tâche Ti. Cette opération ne peut être
générée que par la tâche active. Elle provoque le transfert du descripteur de la tâche concernée
de la liste des tâches suspendues vers la liste des tâches prêtes, ou encore de la liste des tâches
en attente-suspendues vers la liste des tâches en attente. Dans le cas où Ti devient prête,
l’algorithme de choix de l’allocateur du processeur peut être exécuté afin de vérifier si T ne
nécessite pas une exécution immédiate.
· P(S) : permet de mettre en place un mécanisme de synchronisation indirecte par sémaphore (cf.
chapitre 4) en effectuant le test de la variable de sémaphore S et en bloquant éventuellement de
la tâche qui l’effectue. Le blocage est réalisé en insérant le descripteur de cette tâche dans la
file d’attente F(S) associée au sémaphore S. En cas de blocage, l’algorithme de choix est
déclenché afin d’élire une nouvelle tâche.
· V(S) : permet le déblocage d’une tâche en attente dans la file d’attente F(S) du sémaphore S
en réalisant le relâchement de ce sémaphore (cf. chapitre 4). Cette opération est réalisée par
l’insertion du descripteur de la tâche concernée dans la liste des tâches prêtes. L’algorithme de
choix de l’allocateur du processeur peut être déclenché afin de vérifier si la tâche débloquée ne
nécessite pas une exécution immédiate.
· ENVOYER (Message, BaL) : permet de mettre en place un mécanisme de communication

indirecte entre tâches par boîtes aux lettres. La tâche exécutant cette procédure envoie un
message ou l’adresse d’un message (précisé par le paramètre Message) dans la boîte aux lettres
précisée par le paramètre BaL (cf. chapitre 4).
· RECEVOIR (Message, BaL) : permet à une tâche de recevoir un message qui lui a été
envoyé par une autre tâche dans une boîte aux lettres. De la même manière qu’avec la primitive
ENVOYER, le paramètre Message peut contenir Soit le Message à transférer, soit son adresse,
et le paramètre BaL représente la boîte aux lettres supportant la communication.
Les primitives de synchronisation permettent de réaliser une synchronisation pure entre plusieurs tâches
ou de forcer le changement d’état des tâches. Néanmoins, il est rare qu’un mécanisme de
communication ne sollicite pas une synchronisation (rigoureuse ou non) entre les émetteurs et les
récepteurs. Ainsi, les primitives de communication permettent aussi aux tâches de se synchroniser et
d’échanger des informations.

Les mécanismes permettant aux tâches de coopérer sont, dans la majorité des cas associés à des
procédures de haut niveau trop nombreux pour être énumérées ici. Ces procédures, du type
CREER_SÉMAPHORE, CREER_BOITES_AUX_LETTRES, TEST_AND_SET, BLOQUER, E
VEILLER, DEPOSER, RETIRER, RvRENVOI, RvRECEPTION, RvREPONSE... sont nécessaires à
la création des structures de données qu’elles utilisent et à leur mise en oeuvre.
Les procédures de haut niveau sont principalement utilisées par les concepteurs d’applications temps-
réel pour lesquelles les problèmes de synchronisation et de communication sont primordiaux et
cruciaux. Leur utilisation est précisée et détaillée au cours du chapitre 4 qui aborde les problèmes liés à
la coopération entre tâches.

1.3. / LA GESTION DES INTERRUPTIONS

Lorsque l’unité centrale d’une machine est en marche, elle exécute des instructions sans jamais s’arrêter.
Lorsqu’elle n’a aucune tâche à exécuter, le système d’exploitation lui fait exécuter une boucle d’attente
jusqu’à ce qu’il ait quelque chose à lui proposer. Ainsi, lorsqu’une machine est contrôlée par un système
d’exploitation, elle doit donc toujours exécuter des instructions. Le problème se pose alors de savoir à
quel moment l’unité centrale va prendre en compte les événements extérieurs à la séquence
d’instructions qu’elle exécute un utilisateur a frappé une touche sur un clavier, une imprimante vient de
terminer l’impression d’une page, un capteur envoie un signal... A chacun de ces événements
correspond un certain travail à exécuter par l’unité centrale. Le traitement spécifique à l’événement est
réalisé par une tâche ou par un ensemble de tâches. Ces tâches doivent être exécutées par l’unité
centrale le plus rapidement possible pour que les échanges d’informations avec l’extérieur se fassent
dans les délais les plus brefs ou que les incidents dus à des défaillances matérielles et/ou logicielles soient
pris en compte instantanément. Pour cela, elles sont pratiquement toujours d’un niveau de priorité élevé
par rapport aux autres tâches (du système ou de l’utilisateur) de manière à ce que le système puisse
suivre rapidement les évolutions de son environnement sans perte d’information. Mais en contre partie
elles doivent être extrêmement courtes pour ne pas saturer le processeur.
Pour résoudre le problème de la réponse à ces événements, les noyaux des systèmes d’exploitation
dispose d’un gestionnaire d’interruption. Chaque événement se traduit par une interruption du travail en
cours d’exécution par l’unité centrale au profit de l’exécution de la tâche de traitement de cette
interruption.
1.3.2. / NOTION D’INTERRUPTION
Une interruption est un événement permettant d’arrêter provisoirement le déroulement d’une tâche
active pour prendre en compte un événement extérieur nécessitant l’exécution d’un programme
considéré comme prioritaire. Déclenchée par une cause extérieure au déroulement de l’instruction en
cours d’exécution, elle se traduit par une rupture de séquence provoquée par la commutation de
contexte d’un processeur (cf. figure 3.1). Physiquement, une interruption est générée par un signal
envoyé au processeur. Ce signal peut provenir d’un autre processeur, d’un organe d’entrées-sorties ou
de tout procédé physique extérieur au système informatique. Il permet de forcer le processeur à
suspendre, dès le premier point interruptible, l’exécution d’un programme afin d’exécuter une tâche
prédéfinie.
La rupture de séquence doit avoir lieu dans un temps raisonnablement court (on ne peut pas attendre la
fin de l’exécution du programme en cours pour envoyer la page suivante à l’imprimante ou pour traiter
un événement relatif à une alarme).
De plus, l’état de l’événement signalé par une interruption n’est pas toujours durable. Le processeur
doit donc, dés l’apparition d’une interruption, réagir très vite afin de prendre en compte aussi
rapidement que possible les évolutions de l’environnement du système informatique et/ou d’en optimiser
le fonctionnement. Pour cela, le traitement d’une interruption est en général prioritaire par rapport à
l’exécution des tâches et des programmes d’application.

Figure 3. 1 : Ruptures de séquence provoquées par un événement extérieur
Une des caractéristiques principales d’une interruption est son aspect asynchrone. Effectivement, une
interruption étant générée par l’environnement du système informatique, elle peut se produire à
n’importe quel moment, sans forcément qu’il y ait une relation directe avec la séquence en cours
d’exécution qu’elle va temporairement interrompre. Ce phénomène donc pose le problème de la
reconnaissance de l’événement.
1.3.3. / DIFFERENTES CAUSES D’INTERRUPTION
Selon la provenance de l’événement et la nature du traitement qui lui est lié, on est amené distinguer
deux types d’interruptions: les interruptions internes et les interruptions externes.
1.3.3.1./ Les interruptions internes
Les interruptions internes sont des événements provenant de l’unité centrale du système informatique.
Elles peuvent être de plusieurs origines :
· Les interruptions de l’horloge temps-réel : permettant la gestion du temps par le système

d’exploitation. Leur fréquence est programmable. Le système d’exploitation utilise ces
interruptions pour tenir à jour les temps d’attente des différentes tâches, lancer des tâches
cycliquement..., et bien évidemment pour comptabiliser le temps passé par un programme dans
la machine (constituant un des composants de la facturation des services).
· Les interruptions dues aux erreurs (EXCEPTION) : permettant de protéger le système

d’exploitation et les applications des utilisateurs contre les erreurs et le fonctionnement
erratique, voire même volontairement hostile, d’une des applications. Parmi les erreurs donnant
lieu à ce type d’interruption, on trouve : la violation d’accès à la mémoire, l’exécution d’une
instruction non conforme (division par zéro...), l’utilisation d’une instruction privilégiée
réservée au système d’exploitation (appel à des primitives de base...). Ce type d’interruption est
appelé également déroutement (trap) ou exception.

· Les interruptions logicielles : permettant à un programme de faire une requête au système

(par exemple pour faire une demande d’opération d’entrées-sorties) en exécutant une
instruction d’appel au superviseur (SVC. SuperVisor Call). Cette instruction effectue
explicitement le lancement d’une fonction du système d’exploitation. Lorsqu’une tâche exécute
une requête, cela provoque sa démission et consécutivement l’élection de la tâche exécutant le
service demandé. Ce service n’est réalisé qu’après vérification des arguments d’appel, afin
d’éviter des tentatives de pénétration frauduleuse à l’intérieur du système.
1.3.3.2./ Les interruptions externes
Les interruptions externes proviennent des périphériques ou d’éléments extérieurs au système

informatique (lors de la commande de procédés physiques). Elles sont toutes de même type mais de
nature très diverse et concerne en général principalement le gestionnaire d’entrées-sorties du système :
· La mise en service d’un périphérique (mise sous tension) provoque une interruption de
demande de travail,
· Après la fin de la frappe d’une ligne ou d’une page, l’imprimante envoie une interruption pour
signaler qu’elle est prête à recevoir la ligne ou la page suivante,
· Le retour chariot d’un clavier provoque une interruption signalant la présence dune ligne de
texte dans une zone tampon,
· Un contrôleur de disques signale par une interruption que le travail préalablement demandé a
été accompli,
· Dans un contexte de contrôle de procédés, les phénomènes physiques sont signalés par
interruptions (atteinte de butée génération d’une alarme, envoi d’une mesure...) qui
proviennent des différents capteurs mis en place sur l’application...
1.3.4. / MODE SYSTEME ET MODE UTILISATEUR
Le traitement d’un événement ainsi que la nature prioritaire de ce traitement engendre des risques non
négligeables pour le système d’exploitation et les programmes d’application. A ce titre les opérations
d’entrées-sorties sont particulièrement critiques (effacement une bande magnétique ou d’une partition
sur un disque appartenant à un autre utilisateur, modification du contenu d’une adresse dans une zone
de mémoire appartenant à un autre utilisateur...). Il est donc nécessaire de les contrôler très
soigneusement.
Pour protéger le système d’exploitation, ainsi que les différentes tâches d’application, contre des
programmes erratiques ou inamicaux, il est crucial qu’une tâche d’application ne puisse pas influer (de
manière malveillante ou maladroite) sur l’exécution du système d’exploitation lui-même ou sur
l’exécution d’une tâche d’un autre utilisateur. Pour cela, certaines instructions, telles que les opérations
d’entrées-sorties ne sont jamais exécutées directement par une tâche d’application, mais sont exécutées
par une tâche du système d’exploitation pour le compte et à la demande d’un programme utilisateur.
Ces instructions, appelées instructions privilégiées sont totalement interdites aux programmes des
utilisateurs.

Afin qu’un utilisateur quelconque ne puisse accéder à des zones de mémoire ou à des registres
particuliers propres au système, une unité centrale devant supporter un système d’exploitation doit avoir
la propriété essentielle de pouvoir fonctionner selon deux modes d’exécution :
· Le mode superviseur, appelé aussi mode système ou mode maître les tâches s’exécutant dans
ce mode peuvent utiliser n’importe quelle instruction (privilégiées ou non),
· Le mode utilisateur, appelé aussi mode esclave les tâches s’exécutant dans ce mode ne peuvent
pas exécuter les instructions privilégiées.
Dans ces conditions, les instructions privilégiées ne sont exécutables que si le système est en mode
superviseur. Ainsi, la protection du système et de son environnement dès l’apparition d’une interruption
est réalisée par la commutation automatique du processeur en mode superviseur. L’implantation de ces
deux modes et de ces deux sous-ensembles d’instructions nécessite un bit spécial, dans le format des
instructions, indiquant si elles sont ou non utilisateurs, indique le mode courant d’exécution. Avant
chaque exécution d’une instruction (prélude d’exécution) un test, réalisé en général par le matériel,
permet de vérifier la conformité des deux bits :
· Bits conformes l’exécution est autorisée et s’effectue normalement,
· Bits non conformes un signal d’interruption est émis par le matériel et provoque l’arrêt de la
tâche en cours et l’exécution de la routine d’interruption qui lui est associée.
1.3.5. / LE MECANISME D’INTERRUPTION
Le mécanisme de traitement d’une interruption externe est généré directement, au niveau matériel, par
les circuits de traitement.
Routine d’interruption
Début
Masquer les interruptions

Acquitter les interruptions
Tant que il reste une interruption non traitée

Faire Identifier la source de l’interruption
Traiter l’interruption
FinTantque
Démasquer les interruptions
Fin
Figure 3.2 : Exemple de traitement d’une routine d'interruption

Ce sont eux qui lancent la routine d’interruption (interrupt handier), c’est-à-dire la procédure à mettre
en oeuvre pour prendre en compte une interruption, reconnaître la source qui l’a émise et la traiter.
Dés que l’occurrence d’une interruption est détectée au niveau matériel, le fonctionnement normal du
processeur est arrêté. La tâche active doit alors perdre la main au profit de la routine d’interruption.
Son contexte ainsi que le mot d’état sont sauvegardés. La copie dans le mot d’état d’une valeur
adéquate permet ensuite de commuter le système en mode supervision. Un code correspondant au type
de l’interruption est ensuite affiché à l’entrée des circuits responsables du traitement. Ces Circuits
utilisent ce code pour générer l’adresse physique de la routine d’interruption qui a été programmée pour
traiter le type de l’interruption détectée. Cette adresse est alors copiée dans le compteur ordinal.
L’écriture automatique d’une nouvelle valeur dans le compteur ordinal provoque un branchement à
cette adresse, et donc l’exécution de l’instruction qu’elle mémorise. Par cette méthode, le système
reprend automatiquement la main.
Toutes ces opérations sont enchaînées automatiquement par le matériel, ce qui permet une réaction très
rapide du système. Chaque type d’interruption peut faire l’objet d’un traitement différent. La figure 3.2
donne un exemple de traitement d’une routine d’interruption externe. Lorsqu’une interruption se
produit, le système doit être capable de répondre à un certain nombre de questions concernant la mise
en oeuvre du traitement correspondant :
· Quand et comment le processeur reconnaît-il qu’une interruption est arrivée ?
· Quelle est la source responsable de l’interruption ?
· Quelle action entreprendre ?
· Comment reprendre la tâche interrompue ?
L’activation d’une interruption pendant l’exécution d’un programme au niveau des instructions
s’effectue pendant la période transitoire nommée ‘prélude de l’instruction’ comme le montre la figure
suivante :
Instruction 1
Instruction 2
Instruction 3
Instruction 4 Préludes des instructions : temps transitoires pendant
lequel on vérifie si :
- 1- Il y a une interruption.
- 2- L’instruction à exécuter est en mode
système ou utilisateur.
- 3- Le processeur est en mode système
ou utilisateur.

1.3.5.1./ Le masquage des interruptions
Dans le cas où le système gère un grand nombre d’interruptions, plusieurs indicateurs d’événements
correspondant à des causes distinctes peuvent être modifiés en même temps. Il se produit alors un
conflit lors du choix de la routine d’interruption à exécuter. Ce conflit est souvent réglé en fixant un
ordre de priorité à chaque interruption. Néanmoins, en gérant plusieurs niveaux de priorité
d’interruption, le système s’expose au risque de n’exécuter que des routines d’interruption et des
changements de contextes (dans la mesure où, une routine peut être Interrompue par une autre, puis
une autre, puis une autre...).
De plus, il peut être utile de protéger l’exécution d’une suite instructions contre certaines interruptions
et cela quel que soit le niveau traité. Par exemple, pendant l’exécution d’une partie vitale de la routine
d’interruption, il est nécessaire d’empêcher que le traitement puisse être interrompu une nouvelle fois :
· Avant d’avoir pu mémoriser la première interruption,
· Lors de la sauvegarde du contexte de la tâche interrompue,
· Lors du transfert du contrôle du processeur à la routine d’interruption...
Il est donc crucial de pouvoir inhiber, c’est-à-dire retarder, voire même annuler, la prise en compte d’un
signal d’interruption. Le retard dans la prise en compte d’une interruption d’un niveau donné est réalisé
par le masquage d’un ou plusieurs niveaux d’interruption. Cette opération est automatiquement réalisée
au niveau matériel.
En pratique, le système positionne un indicateur, appelé masque d’interruption. Cet indicateur est
constitué d’un ensemble de bits de masquage, à raison d’un bit par niveau d’interruption. Une fois que le
bit de masquage relatif à un niveau est positionné à 1, le niveau est dit masqué. Ce bit est consulté avant
tout essai de prise en compte d’une interruption. Le masque d’interruption fait partie du mot d’état du
processeur et peut ainsi être modifié à chaque commutation de ce mot. Ce procédé permet à toute
routine d’interruption de masquer d’autres niveaux d’interruption que celui en cours de service.
Il est évident que le masquage d’une interruption doit être très court. Effectivement, lorsque des
interruptions sont masquées, c’est une partie du système ou de son l’environnement qui est cachée. Le
masquage des interruptions ainsi que le niveau de priorité alloué à chaque événement. doivent donc faire
l’objet d’études approfondies afin d’être certain qu’aucun événement important. lié à l’évolution du
comportement du système, ne sera perdu. La levée d’inhibition, appelée démasquage, est alors réalisée
par la commutation du mot d’état produit après la restauration du contexte de la tâche qui avait été
interrompue. Cette opération consiste à autoriser de nouveau les interruptions.
Pour supprimer complètement la prise en compte d’un niveau d’interruption, le système peut mettre en
oeuvre un processus de désarmement. Tout se passe alors comme si la cause de l’interruption était
supprimée. Pour rendre de nouveau sensible le niveau désarmé il suffit au système de le réarmer.
L’armement et le désarmement sont réalisés par la modification d’un indicateur du mot d’état.

Masquer une interruption c’est ne pas tenir compte de celle ci. Démasquer, c’est autoriser une
interruption (en tenir compte) par exemple après le traitement de celle ci. Plusieurs IT peuvent être
masquées en même temps. On traite les IT dans le registre d’IT par ordre de priorité du MSB au LSB.
IT1
IT2 ITi ITn
Registre E/S :
permet
1
d’identifier
l’IT.
MSB LSB
≠ 0 : bit d’IT passe à 1 on a
une ou plusieurs IT.
& = 0 : Il n’y a pas d’IT.
Registre de
masquage
= 0 : IT masquée.
= 1 : IT non masquée.
1 Registre d’IT
@IT1
@ITi @ITn
@IT2
1 Vecteur d’@
des IT (ou
vecteur
d’Interruption)
@ de la routine à exécuter
lors de l’activation de l’IT.
L’@ de l’IT est alors
chargé dans le compteur
ordinal du
microprocesseur.

1.3.5.2./ Reconnaissance d’une interruption
Suivant le type de l’interruption (interne ou externe) la reconnaissance de son occurrence aura lieu à des
moments différents. Pour les interruptions externes, le processeur possède un bit spécial, appelé bit
d’interruption, qui est mis à 1 par le matériel lorsque se produit un événement externe. Ce bit
d’interruption est testé dans le prélude de chaque instruction (cf. figure 3.3) afin de savoir si une
interruption s’est produite au cours de l’exécution de l’instruction précédente.
Reconnaissance d ‘une interruption
Début
Si (bit d’interruption =1) ET (interruption non masquée)

Alors Lancer la routine d’interruption
Sinon Poursuivre la séquence en cours
FinSi
Fin
Figure 3.3 : Algorithme de reconnaissance d’une interruption
La reconnaissance d’un signal d’interruption est réalisée au niveau matériel, à l’aide de deux lignes de
commande:
· Les périphériques signalent leurs requêtes en activant la ligne IRQ (interrupt request),
· Lorsque le processeur reçoit cette requête, il positionne ensuite la ligne ITA (interrupt
acknowledge) pour acquitter l’interruption, c’est-à-dire signaler au périphérique la prise en
compte de l’interruption qu’il a générée.
Ainsi, une interruption externe n’est donc traitée qu’en début de l’instruction suivante de la tâche active
(le processeur termine d’abord l’instruction en cours). Ceci n’est évidemment pas le cas d’une
interruption interne du type exception, puisque l’interruption est alors déclenchée afin que l’instruction
erronée ne s’exécute pas complètement. La reconnaissance de ce type d’interruption est réalisée lors de
l’opération de déroutement (cf. §7.2 de ce chapitre).
1.3.5.3./ Identification de la source
Pour traiter une interruption, il est nécessaire d’en connaître la source, c’est-à-dire d’identifier le
périphérique qui l’a émise. La manière d’effectuer cette identification dépend à la fois du matériel
concerné, du mécanisme d’identification, des niveaux d’appréhension d’un événement et enfin de
l’inhibition ou non de ces niveaux. Ces différentes méthodes d’identification ont conduit les
constructeurs à concevoir plusieurs mécanismes de gestion d’interruption suivant le compromis
coût/performance approprié.

1.3.5.3.1./ Identification directe
Ce mode d’identification est utilisé principalement sur les systèmes de type temps-réel où il est très
important d’identifier rapidement les interruptions. La méthode ]a plus élémentaire consiste à disposer
d’un registre d’interruption, dont chaque bit correspond à un événement externe. Il suffit alors,
d’examiner ce registre pour savoir d’où vient l’interruption à traiter. Dans le cas où plusieurs
interruptions se seraient produites chacun des bits de ce registre associé à l’événement prend la valeur 1.
Identification directe
Début
TantQue Registre d’interruption <> 0

Faire • Trouver un bit du registre d’interruption à 1
• Traiter l’interruption correspondante
• Mettre le bit à 0
FinTantque
Fin
Figure 3.4 : Algorithme d’identification directe
L’algorithme de la figure 3.4 est un exemple de traitement d’identification directe d’une source
d’interruption. La boucle de test de cet algorithme considère l’ensemble des interruptions qui se sont
produites à un instant donné et accepte même les interruptions qui arrivent au cours du traitement d’une
interruption. Il est également possible de prendre en compte les niveaux de priorité des interruptions, en
affectant à chaque bit d’interruption une place dans le registre d’interruption en fonction de la priorité
de l'événement qui lui est associé, et en parcourant ce registre dans l'ordre adéquat.
1.3.5.3.2./ Identification par scrutation
Ce mode d’identification tien est utilisé dans des systèmes de type micro-ordinateur pour lesquels
l'amélioration des performances provenant de l‘utilisation d’un registre d’interruption ne justifie pas son
coût. Dans le cas d’une identification par scrutation (“polling") le système interroge individuellement
chaque source possible d'interruption. Cette méthode permet de faire tout ce que permet l’utilisation
d'un registre d’interruption, mais de manière moins rapide.
1.3.5.3.3./ Reprise de la tâche interrompue
Lorsqu'une routine d'interruption est déclenchée, la tâche active Tj perd le contrôle du processeur. Le
traitement d’une interruption ne doit en aucun cas affecter le fonctionnement de cette tâche. La reprise
de son exécution doit ainsi se faire à partir de la sauvegarde de son état au moment de son interruption.
C’est pour cette raison qu'en général les routines d’interruption effectue la sauvegarde du contexte de la
tâche interrompue (cf figure 3.2)

Figure 3.5 : Sauvegarde et restauration de contexte lors du traitement d'une interruption
Par contre, une fois la tâche d’interruption terminée et s’il n’y a plus d’autre interruption à traiter (le
registre d’interruption vaut zéro), la reprise de La tache interrompue Ti peut être effectuée. Cette
reprise s'effectue par l’exécution d’une instruction spéciale RFI (Return From Interrupt) qui restaure
non seulement le contexte de cette tâche (cf figure 3.5) mais également le mot d'état remettant ainsi le
processeur en mode utilisateur. Lors de la restauration du contexte de la tache Ti, l’adresse pointée par
le compteur ordinal et qui avait été sauvegardée par la routine d’interruption, est recopiée dans le
compteur ordinal, Cette copie provoque automatiquement un branchement à l'instruction de la séquence
de Ti précédemment interrompue. C’est ainsi que Ti reprend la main. La reprise de Ti s’effectue alors
au bon endroit dans sa séquence d’instructions. c'est-à-dire à l’endroit où celle-ci avait été interrompue.
Il est à noter que si le traitement l’interruption a provoqué une modification dans l’ordre de la liste des
tâches prêtes, et que a tâche Ti qui avait été interrompue n’est plus en tête de cette liste ou plus dans la
liste, l'exécution de l' instruction RFI provoquera la restauration du contexte de la tâche en tête de la
liste des tâches prêtes
1.3.6. / NOTION DE NIVEAU D'INTERRUPTION
Les différentes causes d'interruption nécessitent l'exécution de tâches d'interruption on différentes. La

plupart des mécanismes de gestion des interruptions permettent de distinguer ces causes en mettant en
oeuvre la notion de niveau d’interruption. Cette notion permet une hiérarchisation du traitement des
interruptions. Ainsi, lors du traitement d’une interruption IT de niveau ni, si L une interruption ITp de
ni veau supérieur se produit, le traitement de IT pourra être interrompue afin de traiter l’interruption
ITp (cf. figure 3.6). A la fin du traitement d’ITp, le traitement d'IT pourra être repris, à condition
qu’aucune autre interruption de niveau supérieur à ni et inférieur à celui d’ITp ne soit intervenu pendant
le traitement d’ITp.
Figure 3.6 : Ruptures de séquences provoquées par des événements hiérarchisés

La routine d’interruption est alors traitée soit par un programme unique Soit par un programme distinct
associé à chacun des niveaux. L’occurrence d’un événement est indiquée soit par un seul indicateur, soir
par plusieurs indicateurs (un par niveau).
L'utilisation de plusieurs indicateurs permet alors d'augmenter l'efficacité du gestionnaire d'interruption

qui peut ainsi déclencher directement la routine correspondant au niveau traité.
1.3.6.1./ Niveau unique à priorité unique
Certains systèmes informatiques ne permettent de traiter qu’un seul niveau d’interruption. Dans ce cas,
toutes les lignes d'interruption provenant chacune d’un périphérique différent, sont réunies par un OU
logique câblé sur une bascule (flip-flop) (cf figure 3.7).
Cette bascule est directement connectée au bit d'interruption de l’unité centrale par la ligne IRQ. Son
changement d’état provoque le déclenchement de la routine d’interruption. Celle-ci va alors tester la
ligne de chaque périphérique pour identifier la source qui a provoqué l'interruption.
Figure 3.7: Système d’interruption à niveau unique et priorité unique
Avec cette structure, l’algorithme de traitement de la routine d’interruption doit traiter les différents
périphériques équitablement (sans priorité), par exemple en ne commençant jamais le test des lignes
d’interruption dans le même ordre.
1.3.6.2./ Niveau unique à priorités multiples
Avec ce montage, les périphériques sont chaînés en guirlande (daisy chain) sur une seule ligne
d’interruption par ordre de priorité. Ils sont connectés par un OU logique câblé sur la ligne IRQ, elle-
même reliée à une bascule connectée au bit d’interruption (cf. figure 3.8). Par contre, la ligne ITA se
connecte sur chacun des périphériques.

Ainsi, les interruptions du périphérique Pi ne sont prises en compte que si les périphériques précédents
P1, P2... ne sont pas en cours de service. De plus, lorsqu’il sert une interruption générée par le
périphérique Pi, le système peut être interrompu par une interruption provoquée par P1 ou P2 il peut
alors traiter complètement celle-ci qui est de niveau plus élevé pour revenir ensuite au traitement de P.
Une requête d’interruption générée sur la ligne IRQ peut être activée par plusieurs périphériques en
même temps. Le processeur recevant une requête active alors la ligne ITA pour acquitter cette
demande. Dès que le signal ITA atteint un périphérique ayant fait une requête, sa propagation est
arrêtée. Le périphérique envoie alors sur le bus de données du système un numéro d’identification qui
permet d’accéder à une table de vecteurs d’interruption.
Ce numéro correspond, par exemple, à un index de cette tablé. Cette table contient pour toutes les
interruptions traitées par le système l’adresse de la tache d’interruption à exécuter. Il suffit alors de
commuter le contexte de cette tache pour lancer le traitement relatif à la requête formulée.
Cette méthode, dite des interruptions vectorisées, résout à la fois le problème de l’identification de
l’interruption et celui des conflits d’accès, puisque le système ne prend en compte qu’une interruption et
une seule à la fois, même si plusieurs requêtes sont effectuées simultanément.
Figure 3.8 . Principe du chaînage daisy chain
Le périphérique servi le premier est celui qui est plus proche du processeur sur la ligne ITA. Les
priorités sont ainsi allouées par la position physique des périphériques le plus proche du processeur
étant alors le plus prioritaire. Toutefois, cette méthode est moins souple que la précédente puisqu’elle
ne permet pas de modifier les priorités des interruptions par programme.
1.3.6.3./ Niveaux multiples à priorités multiples
Lorsque le système comporte un grand nombre de périphériques, il est généralement nécessaire de

combiner plusieurs techniques permettant de mettre en oeuvre plusieurs niveaux d’interruption. De plus,
chaque niveau doit permettre de distinguer les périphériques par ordre de priorité. On rencontre
plusieurs configurations matérielles mettant en oeuvre ce principe, selon que le processeur possède une
ou plusieurs lignes d’interruption.

1.3.6.3.1./ Systèmes à une ligne d’interruption
Avec ce montage, les différents niveaux d’interruption sont mis en oeuvre par un chaînage du type
guirlande. Chaque chaînage est réuni sur un OU logique câblé. Ce dernier est connecté une bascule qui
est elle-même reliée au bit d’interruption. Un décodeur permet au système de sélectionner les niveaux
d’interruption selon leur priorité (cf. figure 3.9). Cette sélection est réalisée de manière programmée.
Lorsqu’une interruption se produit, le processeur envoie sur le bus un code indiquant au décodeur le
niveau d’interruption sur lequel ce dernier doit envoyer un signal ITA. Ce code peut être variable ce qui
offre un grand nombre de combinaisons de sélection du premier niveau d’analyse. Le signal ITA se
propage ensuite dans la chaîne jusqu’à ce que le périphérique émetteur de l’interruption soit atteint, de
la même manière qu’avec un chaînage en guirlande classique.
Figure 3.9.: Système à ligne d’interruption unique
Si ce périphérique ne se trouve pas sur le niveau sélectionné, un nouveau code est généré par le
décodeur afin de sélectionner le niveau suivant. Dès que [a source d’interruption est atteinte, le
traitement est alors le même que pour un chaînage en guirlande le périphérique place sur le bus son
numéro d’accès à la table des vecteurs d’interruption dans laquelle se trouve l’adresse de la tâche de
traitement de l’interruption qui peut alors prendre le contrôle.

1.3.6.3.2./ Systèmes à lignes d’interruption multiples
Certains processeurs possèdent plusieurs lignes d’interruption IRQ et ITA. Chaque niveau est mis en
oeuvre par un chaînage du type guirlande. Chacun des chaînages en guirlande est connecté sur une ligne
IRQ (cf. figure 3.10). Les lignes d’interruption multiples sont souvent spécialisées. Ainsi, certains
processeurs (tels que les processeurs MOTOROLA) comportent trois lignes d’interruption
· La ligne NMI (Non Masquable Interrupt) réservée à des interruptions de très haute priorité
signalant en général une anomalie. Les interruptions générées sur cette ligne ne peuvent pas
être masquées par le processeur,
· La ligne FIRQ (Fast Interrupt Request) réservée aux interruptions devant être traitées très
rapidement. Avant de traiter une interruption générée sur cette ligne, seul le Compteur ordinal
et le mot d’état sont sauvegardée automatiquement.
· La ligne IRQ (Interrupt Request) correspondant aux interruptions classiques pour lesquelles le
processeur sauvegarde automatiquement tous les registres au moment de la prise en compte
d’une interruption.
Figure 3. 10 Système à lignes d’interruption multiples
Chaque niveau est traité indépendamment. Dès qu’une interruption est détectée sur un des niveaux, le
mécanisme d’identification et de traitement des chaînages en guirlande est alors lancé sur le niveau
correspondant.

1.3.6.3.3./ Notion de contrôleur d’interruption
Pour les systèmes devant gérer un nombre élevé de périphériques, le nombre de lignes d’interruption
disponibles au niveau du processeur devient vite insuffisant. Il est alors nécessaire de déplacer une partie
importante de la logique d’interruption en dehors du processeur en la disposant au niveau d’une ou de
plusieurs unités séparées (cf. figure 3.11), appelées contrôleur d’interruption (P.I.C. : Programmable
Interrupt Controler). Leur rôle est de décharger le processeur des Opérations de masquage et
d’identification des sources d’interruption. Un contrôleur d’interruption est composé de plusieurs
registres configurables. C’est la configuration de ces registres qui permet la programmation de la
routine d’interruption. Ainsi, selon les valeurs contenues dans ces registres, le programme
d’identification mettra en oeuvre une technique de scrutation de type polling ou encore une technique
d’identification directe permettant ou non de considérer chaque ligne d’interruption avec le même
niveau de priorité. Néanmoins, en plus des registres de programmation, la plupart des contrôleurs
comportent au moins deux registres :
· Un registre d’interruption permettant d’identifier les interruptions,
· Un registre de masquage permettant d’inhiber les interruptions de manière sélectives.
Figure 3.11 Système d’interruption utilisant un contrôleur d’interruption
Chaque niveau d’interruption (ou chaque ligne d’interruption) est lié à un bit du registre d’interruption.
Ce registre est testé bit à bit lors d’une modification de sa valeur afin de déterminer la source de
l’interruption. Dés que celle-ci est identifiée, le bit qui la représente dans le registre d’interruption est
comparé au bit qui lui est symétrique dans le registre de masquage. Selon le résultat de ce test,
l’interruption sera masquée ou au contraire traitée. Si l’interruption n’est pas masquée, le contrôleur
peut mettre en oeuvre un mécanisme du même type que celui qui est réalisé avec une structure en
guirlande simple ou complexe en utilisant ou non un décodeur. Le lancement effectif de la tâche de
traitement associée à l’interruption est effectué par le forçage de son adresse de base dans le registre
compteur ordinal.

La mise en oeuvre des algorithmes d’identification et de gestion des niveaux de priorité est réalisée de
manière câblée ce qui a pour effet d’augmenter considérablement la vitesse de traitement des
interruptions. De plus, en donnant la possibilité de traiter ces différentes opérations de manière
programmée, les structures utilisant des contrôleurs d’interruption offrent une grande souplesse de mise
en oeuvre et d’utilisation.
1.3.7. / TRAITEMENT DES INTERRUPTIONS INTERNES
Contrairement à une interruption externe, une interruption interne est un événement provoqué
directement par l’instruction en cours d’exécution par le processeur. Cet événement peut intervenir lors
d’une demande d’exécution d’une procédure système formulée par la tâche en cours ou encore lors
d’une anomalie de fonctionnement du système.
1.3.7.1./ Les appels au superviseur
Un appel au superviseur (SVC : SuperVisor Call) est une instruction mise à la disposition des
utilisateurs pour leur permettre, à partir de leurs programmes d’application d’effectuer un appel à une
procédure du système d’exploitation exigeant des droits étendus. Ces droits concernent généralement le
passage du processeur du mode utilisateur au mode superviseur, le masquage d’interruptions ou de
niveaux d’interruption, les droits d’accès...
Lorsqu’une tâche exécute une instruction d’appel au superviseur, cela a pour effet de provoquer une
commutation du contexte du processeur. Le mécanisme de commutation permet d’assurer la protection
de certaines ressources matérielles et logicielles (zones mémoires, registres, instructions privilégiées...).
Cette protection est réalisée en imposant des conditions d’entrée dans la procédure appelée. Pour cela :
· Le nouveau contexte (mode, masquage...) remplace celui de la tâche effectuant l’appel dans le
mot d’état logé dans une zone mémoire inaccessible aux utilisateurs,
· La routine de traitement de la requête d’appel au superviseur commence par une séquence de

vérification des droits de l’utilisateur à exécuter cet appel et de la validité des paramètres
transmis,
· En fin de traitement, le contexte de l’utilisateur est restitué par une simple permutation avec le
contexte spécifique de la routine qui vient d’être exécutée.
Chaque instruction SVC d’appel au superviseur représente en fait une macro-instruction. Cette macro-
instruction permet de choisir les différentes procédures accessibles par un appel au superviseur. Le
choix de la procédure est réalisé à l’aide d’un paramètre. Ce mécanisme est mis en oeuvre
principalement dans les couches de gestion des entrées-sorties et de gestion de fichiers d’un système
d’exploitation dont les fonctions sont en général accessibles que par l’intermédiaire d’un appel au
superviseur.

1.3.7.2./ Les déroutements
Un déroutement (trap) correspond au traitement d’une interruption interne signalant une anomalie dans
le déroulement d’une instruction. Cette anomalie empêche un déroulement normal de l’exécution de
cette instruction. Les déroutements peuvent être classés en fonction de leurs causes qui peuvent être
diverses :
· Données incorrectes rendant impossible l’exécution correcte de l’instruction (division par zéro,
débordement arithmétique...)
· Tentatives d’exécution d’une instruction interdite par un dispositif de protection (violation de

protection de mémoire, exécution d’une instruction privilégiée en mode utilisateur...)...
· Instruction non exécutable (code de l’opération non affecté, adresse hors de la mémoire
existante, utilisation d’une ressource absente sur la configuration utilisée...).
Selon leur cause, certains déroutements peuvent être supprimés (les erreurs arithmétiques ou les
lectures de fichiers au-delà de leur limite peuvent être signalées par une valeur de retour d’un
paramètre). Toutefois, le caractère strictement synchrone des déroutements interdit leur retard de prise
en compte, comme cela est possible lors du traitement d’interruptions externes. Ainsi, la notion de
masquage ne peut pas s’appliquer aux déroutements.

1.4. / LA GESTION DU PARALLÉLISME ET DE LA COOPÉRATION ENTRE LES

TÂCHES
Les interruptions et autres phénomènes externes se produisent dans un ordre et avec un minutage
aléatoires. Le système d’exploitation doit donc être capable d’accepter ces signaux à tout moment, en
s’assurant qu’aucune confusion n’est possible. De plus, dans le cas de la multiprogrammation et des
systèmes temps-réel, les tâches ne sont jamais totalement indépendantes plusieurs d’entre elles désirent
par exemple agir sur une même variable ou accéder à un même périphérique. Cependant, quel que soit le
système informatique considéré (monoprocesseur ou multiprocesseur), il ne peut y avoir à un instant
donné qu’une seule tâche ou un nombre limité de tâches actives en même temps. Mais, sur une période
de temps de quelques millisecondes, la plupart des tâches prêtes ou en attente peuvent devenir actives et
prendre possession du processeur à un instant ou à un autre.
Ce type de traitement ne poserait pas de problème si les tâches étaient totalement indépendantes (sur un
système monoprocesseur il pourrait être résolu par un simple multiplexage). En pratique les tâches sont
bien indépendantes pour une bonne part de leur déroulement (ce qui justifie leur existence en tant
qu’entités distinctes) mais elles doivent généralement être capables d’interagir en certains points de leur
exécution, pour des opérations nécessitant le partage de ressources ou encore pour des opérations de
communication et de synchronisation très fréquentes dans le cadre d’applications temps-réel.
Pour résoudre les problèmes posés par les relations entre les différentes tâches d’une marne application,
les systèmes d’exploitation mettent à la disposition des développeurs, des outils et des méthodes de
communication et de synchronisation qu’il met, d’autre part, lui-marne en oeuvre pour gérer les
relations entre ses propres tâches et celles des utilisateurs. Ces problèmes délicats de relations inter-
tâches ne peuvent être résolus correctement que par des approches bien structurées que nous allons
étudier dans ce chapitre.
1.4.2. / L’EXCLUSION MUTUELLE
Le problème de l’exclusion mutuelle (mutual exclusion) se pose lorsque plusieurs tâches veulent se
partager une même ressource qui ne peut être utilisée que par une seule tâche ou un nombre limité de
tâches (cf. figure 4.1). Lorsqu’une imprimante est partagée entre toutes les tâches traitées par le
système d’exploitation et lorsque l’une d’elles a commencé à imprimer ses résultats, il faut que le
processus d’impression se déroule jusqu’à sa fin. Dans le cas contraire, les résultats listés seraient
inexploitables.
Figure 3.1 : partage d’une ressource commune

Prenons un autre exemple considérons un local dans lequel des individus entrent et sortent par une porte
d’entrée et une porte de sortie. L’entrée dans le local déclenche une l’interruption ITE et la sortie du
local déclenche l’interruption ITS (cf. figure 4.2).
Figure 3.2 : Exemple d’exclusion mutuelle
On désire compter le nombre d’individus présents en même temps dans le local à l’aide du compteur N.
Le traitement des interruptions ITE et ITS peut alors se faire à l’aide des deux procédures suivantes (cf.
figure 4.3) :
Traitement ITE Traitement ITS

Début Début
Charger (N) à Accumulateur Charger (N) à Accumulateur
Accumulateur + 1 à Accumulateur Accumulateur - 1 à Accumulateur
Charger (Accumulateur) à N Charger (Accumulateur) à N
Fin Fin
Figure 4.3 : Exemple d’algorithme pour ITE et ITS
Si on décide que l’interruption ITS est prioritaire par rapport à l’interruption ITE, le processeur arrête
le traitement de l’interruption ITE au moment où se produit une interruption ITS pour exécuter le
traitement de ITS. Le traitement de ces deux interruptions consécutives sera alors le suivant (cf. figure
4.4) :
Figure 3.4: Exemple de traitement d'ITE et ITS

La valeur finale du compteur N est alors erronée car en traitant ITS dès qu’elle se produit. on fait une
modification de sa valeur alors que la modification précédemment commencée, lors du traitement
d’ITE, n’a pas été achevée. Chacune des deux routines d’interruption a besoin de la ressource N. Si
l’une des routines interrompt l’autre, des risques d’incidents sur N sont probables. La variable N est
donc une ressource critique qu’il faut partager et donc protéger. Ceci signifie que lorsqu’une tâche
utilise déjà la variable N, elle doit interdire aux autres tâches de venir utiliser dans le même temps cette
variable pour ne pas engendrer d’erreurs.
On définit alors des sections critiques pour désigner la partie de code du code d’une tâche dans lequel la
tâche accède à une ressource critique (cf. figure 4.5). Ces sections critiques représentent l’ensemble des
instructions d’une tâche qui à l’instant considéré nécessitent l’utilisation de la ressource critique. A
chaque instruction ou bloc d’instructions nécessitant l’utilisation d’une ressource critique, est associée
une section critique.
Ressource critique : ressource acceptant
un nombre limité de tâche.
Figure 4.5 : Ressource Critique et Sections Critiques
Pour qu’une tâche puisse utiliser une ressource critique et à chaque fois qu’elle voudra y accéder, elle
devra mettre en oeuvre deux types de primitive, signifiant :
· « Puis-je entrer en section critique ? » c’est à dire exécuter les instructions composant la
section critique et utilisant donc la ressource critique.
· « J'ai fini avec la ressource critique » : pour poursuivre le déroulement de la tâche par les
instructions qui suivent la section critique, c’est à dire sortir de section critique.
Certaines règles doivent être respectées pour gérer correctement ce type de problème :
· Une tâche qui entre en section critique doit interdire aux autres tâches d’y entrer.
· Une tâche qui attend pour entrer en section critique doit être bloquée.
· Une tâche qui sort d’une section critique doit autoriser les autres tâches à entrer en section
critique et doit, éventuellement, débloquer une tâche bloquée.

Ces impératifs nécessitent la mise en place de mécanismes dits d’exclusion mutuelle tels que l’attente
active et le sémaphore
1.4.2.1./ Le mécanisme d’attente active
Le mécanisme d’attente active nécessite l’utilisation d’une variable booléenne « V» appelée Verrou qui
prend la valeur 0 lorsque l’entrée en section critique est autorisée et la valeur i dans le cas contraire. La
protection de la section critique est réalisée par une primitive appelée TAS (Test And Set) qui effectue
de manière indivisible le test du Verrou et sa modification.
L’algorithme de cette primitive est présenté figure 4.6. L’appel de la primitive TAS doit être situé à
l’entrée de la section critique de toutes les tâches désirant se partager et protéger la ressource critique
(cf. figure 4.7). Cet appel constitue la demande d’entrer en section critique du type Puis-je entrer en
section critique ? Chaque tâche désireuse d’exécuter une section critique demandera l’autorisation de le
faire par l’intermédiaire de la primitive TAS qui consultera alors la variable «verrou ».
Primitive TAS (V: booleén)
Début
Lire le contenu de la variable verrou “V’

Si V=0
Alors Vß1
Compteur Ordinal ß Compteur Ordinal + 1
FinSi
Fin
Figure 4.6 : Algorithme de la primitive TAS
Dans le cas où la section critique serait libre (V = O), la primitive TAS positionne le verrou à la valeur 1
(V = 1) ce qui a pour effet de bloquer l’entrée de la section critique aux autres tâches. L’autorisation de
poursuivre l’exécution en section critique est ensuite donnée à la tâche par l’incrémentation de son
compteur ordinal. Cette incrémentation a pour effet de «sauter»l’instruction de saut et donc de
positionner le compteur ordinal de la tâche à l’adresse de la première instruction de la section critique.
Dans le cas où la ressource critique serait occupée (V = 1), la primitive TAS provoque un bouclage sur
son propre appel. Ceci est réalisé par la non-modification de la valeur du compteur ordinal de la tâche
demandant de poursuivre son exécution en section critique. Ainsi. l’instruction qui sera exécutée par la
tâche après l’exécution de la procédure TAS est une instruction de branchement à l’appel de la
procédure TAS. A chaque nouvel appel. TAS se contente de tester la valeur de la variable verrou
jusqu’à ce que celui prenne pour valeur 0.

La sortie de la section critique est effectuée par une remise à 0 de la variable verrou et constitue
l’information «j’ai fini avec la ressource critique». L’inconvénient majeur de ce mécanisme réside dans
le fait que lorsqu’une ressource critique est occupée par une tâche, les autres tâches en attente pour
entrer en section critique sont toujours prêtes. Elles peuvent donc être activées et exécutent alors en
permanence une boucle sur l’appel à la primitive TAS chaque fois qu’elles le sont. Ce qui conduit à un
gaspillage du temps processeur. De plus, l’utilisation de ce mécanisme n’est pas souhaitable.
Lorsqu’une section critique est longue, car le processeur est alors monopolisé par les attentes actives
Dans le cas de système temps-réel, car lorsqu’une tâche est activée, c’est en général parce qu’elle est la
plus prioritaire, à l’instant considéré. Si elle entre alors dans un processus d’attente active, le processeur
ne fera que boucler sur l’appel de la primitive TAS et aucune autre tâche ne pourra être exécutée.
Figure 4. 7 : Utilisation du mécanisme d’attente active
Par contre, son utilisation est encore répandue dans les systèmes multitâches multiutilisateurs. En effet,
ces systèmes fonctionnant en général en temps partagé toutes les tâches sont exécutées et si l’une
d’elles entre en attente active, elle ne bouclera que pendant la période de temps qui lui est allouée.
Ainsi, la tache utilisant la ressource critique pourra continuer en section critique, lorsque sa tranche de
temps lui sera allouée et pourra alors libérer la ressource critique attendue.
1.4.2.2./ Le Sémaphore
Le mécanisme de sémaphore a été développé dés 1968 par DIJKSTRA. Il est basé sur l’idée simple
qu’il est inutile d’activer une tâche en attente pour entrer en section critique tant que la ressource
critique correspondante n’est pas disponible. De plus la libération de la ressource critique peut être mise
à profit pour débloquer une des taches en attente de celle-ci.

A chaque ressource critique est associé un sémaphore permettant le partage et la protection de la

ressource. Un sémaphore est constitué d’une structure de données qui comporte :
· Une variable entière Mutex, appelée jeton de sémaphore.
· Une file d’attente F(Mutex).
Cette structure de données ne peut être manipulée que par les primitives ATTENDRE (wait) et
SIGNALER (signal) qui sont généralement représentées par les symboles P(Mutex) et V(Mutex) et
signifiant respectivement « Puis-je entrer en section critique ? » pour P(Mutex) et « j’ai fini avec la
ressource critique pour V(Mutex) » (cf. figure 4.8).
P (Mutex) V (Mutex)
Début Début
Mutex ß Mutex - 1 Mutex ß Mutex + 1
Si Mutex <O Si Mutex <= 0
Alors Alors
• Enlever la tâche active de la liste des tâches prêtes • Enlever la tâche en tête de la file d’attente F (Mutex)
• Mettre la tâche active dans la file d’attente F (Mutex) • Mettre cette tâche dans la liste des tâches prêtes
FinSi FinSi
Fin Fin
Figure 4.8 : Algorithmes des primitives P(Mutex) et V(Mutex)
Les interruptions sont inhibées pendant le temps d’exécution de P(Mutex) et de V(Mutex). Ainsi, ces
deux primitives sont ininterruptibles mais pour un temps très court ce qui ne porte pas préjudice à
l’exécution des applications en cours. De la même manière que celle utilisée pour l’attente active,
l’implémentation de l’exclusion mutuelle par sémaphore est réalisée en plaçant (cf. figure 4.9) :
· La primitive P(Mutex) à l’entrée de la section critique de chaque tâche utilisant la ressource

critique considérée.
· La primitive V(Mutex) à la sortie de la section critique de chaque tâche utilisant la ressource

critique considérée.
Pour bien comprendre le mécanisme d’exclusion mutuelle par sémaphore, il faut noter que la variable de
sémaphore Mutex représente le nombre de droits d’entrée (ou de jetons d’accès) en section critique
lorsqu’elle est positive ou nulle. Sa valeur absolue représente le nombre de tâches présentes dans la file
d’attente du sémaphore lorsqu’elle est strictement négative. Cette caractéristique permet ainsi de gérer
des ressources critiques conçues de telle sorte qu’elles peuvent être affectées à plusieurs tâches en
même temps, jusqu’à un maximum de N tâches.

Ainsi, l’initialisation de la structure de données associée constituant le sémaphore se fera toujours de la

manière suivante :
· La variable de sémaphore Mutex doit être initialisée à une valeur > 0 représentant le nombre de
tâches pouvant être traitées en même temps par la ressource critique.
· La file d’attente F(Mutex) doit être vide à l’initialisation.
Figure 4.9 : Exclusion mutuelle par sémaphore
Le test sur le signe de Mutex permet de déterminer immédiatement si des tâches sont en attente de la
ressource critique associée au sémaphore. Le rôle de la primitive P(Mutex) est de donner des droits
d’accès aux tâches le demandant, tant qu’il en reste (on dit aussi que la tâche prend un jeton de
sémaphore). Le rôle de la primitive V(Mutex) apparaît alors clairement puisque l’incrémentation de
Mutex correspond au rétablissement d’un droit de passage (la tâche rend un jeton de sémaphore). De
plus, les tâches qui tentent d’entrer en section critique lorsque tous les droits d’accès ont été distribués,
sont automatiquement bloquées et mises dans une file d’attente, ce qui évite qu’elles n’encombrent le
processeur pour effectuer des tentatives inutiles.
Elles seront immédiatement libérées dés que la ressource critique sera libérée et qu’elles se trouveront
en tête de la file d’attente du sémaphore concerné. Par contre lorsqu’on utilise des sémaphores il est
important de ne pas détruire les tâches qui se trouvent en section critique afin d’éviter un blocage fatal
si une tâche est détruite alors qu’elle est en section critique, elle ne pourra pas exécuter V(Mutex) et
rendre le droit d’accès qui lui a été accordé afin qu’une autre tâche puisse à son tour entrer en section
critique. La ressource critique sera dans ce cas inutilisable par aucune tâche.
1.4.3. / SYNCHRONISATION ENTRE TACHES
Dans le cas d’applications indépendantes traitées par un système d’exploitation multiutilisateurs, la

synchronisation entre tâches n’est pas une préoccupation majeure pour le système d’exploitation (elle
revient la plupart du temps à mettre en place un des mécanismes d’exclusion mutuelle, vu
précédemment).

Par contre, la notion de synchronisation entre tâches prend toute son importance dans le cas
d’applications traitées en temps réel par un système d’exploitation temps-réel. D’une manière générale,
la vitesse d’exécution de deux tâches est imprévisible puisque cela dépend d’une part de la fréquence
des interruptions pouvant intervenir au cours du déroulement de chaque tâche ainsi que de la durée et
de l’importance du travail exécuté et d’autre part de la fréquence d’attribution du (ou des) processeur(s)
aux tâches.
Les tâches se déroulent donc de manière asynchrone les unes par rapport aux autres. Toutefois, pour
assurer une certaine coopération, elles doivent synchroniser leurs activités à certains moments du
traitement lorsqu’une tâche ne peut se poursuivre avant qu’une autre n’ait achevé son traitement.
Lorsque plusieurs tâches sont interdépendantes, elles doivent donc être capables d’interagir pour
synchroniser leur déroulement. Sous sa forme la plus simple, la synchronisation de plusieurs tâches
entre elles nécessite l’utilisation de mécanismes permettant à une tâche :
· D’activer une autre tâche en lui transmettant éventuellement des informations,
· De se bloquer elle-même ou de bloquer une autre tâche en attendant un signal provenant d’une
autre tâche et l’informant de la réalisation d’un événement attendu,
· D’envoyer un signal permettant de débloquer une ou plusieurs tâches lorsque l’événement lié à
la nécessité de synchronisation s’est produit.
Lorsqu’une tâche est encore active au moment de la synchronisation, le signal d’arrivée de l’événement
peut être mémorisé jusqu’à ce qu’elle en ait besoin (ce qui n’est généralement pas le cas dans les
applications temps-réel où les signaux se périment rapidement).
1.4.3.1./ Mécanisme d’action directe
Dans le cas de la synchronisation directe, une tâche agit directement sur une autre tâche. Ce type de
synchronisation peut être très utile pour bloquer, par exemple, une tâche qui boucle indéfiniment. Ce
mode de synchronisation implique que le nom (ou l’adresse) de la tâche àsynchroniser, soit connu de la
tâche qui a le contrôle.
La synchronisation est réalisée à l’aide de deux primitives BLOQUER (NomTâche) et EVEILLER

(NomTâche) dont les algorithmes sont présentés figure 4.10 et qui agissent sur deux variables
booléennes.
BLOQUER (Nom Tâche) EVEILLER (Nom Tâche)

Début Début
Si FANION (NomTâche) = 1 Si ETAT (NomTâche) = 0
Alors FANION (Nom Tâche) ß 0 Alors • ETAT (Nom Tâche) ß 1
Sinon • Mettre NomTâche dans la liste des tâches prêtes
• ETAT (NomTâche) ß 0
• Mettre NomTâche dans la liste des tâches en attente Sinon FANION (NomTâche) ß 1
FinSi FinSi
Fin Fin
Figure 4. 10 : Algorithme des primitives de contrôle du mécanisme d’action directe

Ce mécanisme met en oeuvre deux variables booléennes
- ETAT (NomTâche): qui prend la valeur 1 ou 0 selon que la tâche Nom Tâche est éveillée ou
bloquée et qui est initialisée à 1,
- FANION (NomTâche) : qui prend la valeur 1 lorsqu’un signal d’éveil a été envoyé à la tâche
NomTâche, et la valeur 0 dans le cas contraire et qui est initialisée à 0.
La mise en oeuvre de ce mécanisme (cf. figure 4.11) est réalisée par la tâche qui a le contrôle (en
occurrence la tâche A). La tâche contrôlée (en occurrence la tâche B) subit la synchronisation sans
intervenir à aucun moment dans le mécanisme.
Figure 4.11 : Mise en oeuvre de l’action directe
L’exécution de la primitive BLOQUER(B) provoque la mise en attente de la tâche B si et seulement si

la variable FANION(B) vaut zéro (aucun signal d’éveil n’a déjà été envoyé à la tâche B). L’exécution de
la primitive EVEILLER(B) provoque l’éveil de la tâche B si et seulement si la variable ETAT(B) vaut
zéro (la tâche B est bloquée). Sinon, la variable FANION(B) est mise à 1, ce qui donne un droit de refus
de blocage lors de la commande de blocage suivante qui pourra donc s’effectuer que si la variable
FANION(B) vaut zéro.
1.4.3.2./ Mécanismes d'action indirecte
Les mécanismes d’action indirecte fonctionnent par l’intermédiaire d’objets qui peuvent être des
événements ou des sémaphores. Ces objets servent d’intermédiaire entre les tâches ce qui rend les
mécanismes de synchronisation plus souples et leur mise en place plus aisée.

1.4.3.3./ Synchronisation par événements
La synchronisation par événement constitue le mécanisme de synchronisation le plus simple à mettre en

oeuvre. L’événement est représenté par une variable booléenne dont la valeur synchronise à l’aide d’une
instruction ATTENTE (événement) qui la bloque si la variable événement est égale à 0. Elle reste
bloquée jusqu’à ce qu’une autre tâche mette la variable événement à la valeur 1 (cf. figure 4. 12). La
tâche est dans une liste d’attente avec une gestion de délai.
Figure 4.12 : Synchronisation par événements
1.4.3.4./ Synchronisation par sémaphores
Les sémaphores utilisés pour la mise en oeuvre d’une synchronisation entre plusieurs tâches sont
appelés Sémaphores Privés: on dit qu’un sémaphore Sp est un sémaphore privé d’une tâche T, si et
seulement si seule la tâche T peut exécuter la primitive P(Sp). Les autres tâches ne peuvent agir sur S
qu’à l’aide de la primitive V(Sp). Les algorithmes mis en oeuvre par les primitives P(Sp) et V(Sp) sont
identiques à ceux mis en oeuvre par les sémaphores d’exclusion mutuelle et présentés par la figure 4.8
du §2.2 de ce chapitre.
Figure 4.13 : Synchronisation par sémaphore

En initialisant la variable de sémaphore Sp avec la valeur zéro, une tâche dont l’évolution est
subordonnée à l’émission d’un signal par une autre, se bloque au moyen de la primitive P(Sp). Elle sera
débloquée par l’exécution de la primitive V(Sp) commandée une autre tâche.
L’exemple présenté par la figure 4.13 permet de synchroniser la tâche A avec la tâche B. Pour exécuter
l’instruction ai de la tâche A, après l’instruction bj de la tâche B, il suffit de faire précéder l’instruction
ai de la tâche A par un appel à la primitive P(Sp) et de placer un appel à la primitive V(Sp)
immédiatement après l’instruction b de la tâche B. Avec Sp initialisée avec la valeur zéro, la tâche A est
immédiatement mise dans F(Sp) si elle exécute P(Sp) avant que la tâche B ait exécuté V(Sp).
Figure 4.14 : Synchronisation de type OU entre 3 tâches
Une synchronisation peut être réalisée sur des conditions dépendant de plusieurs tâches, plus complexes
que celles vues précédemment (cf. figure 4.13) et présentées par les figures 4.14 et 4.15. Le type de
synchronisation obtenu dépend alors de l’initialisation des variables de sémaphores et du placement des
appels aux primitives P(S) et V(S) dans l’algorithme des tâches concernées
Dans l’exemple de la figure 4.14, le problème consiste à exécuter l’instruction ai de la tâche A après
l’exécution d’au moins une des deux instructions bj ou Ck appartenant respectivement aux tâches B et
C. La synchronisation est dite synchronisation de type OU.
Dans l’exemple de la figure 4.15, le problème consiste à exécuter l’instruction ai de la tâche A

seulement après l’exécution de deux autres instructions l’instruction bj de la tâche B et l’instruction ck
de la tâche C. La synchronisation est dite alors synchronisation de type ET.
Dans le cas d’une synchronisation de type OU, on peut noter qu’un seul sémaphore est nécessaire S,
alors que dans le cas d’une synchronisation de type ET, il faut autant de sémaphores que de conditions
de déblocage Sb et Sc.

Figure 4.15: Synchronisation de type ET entre 3 tâches
Qu’il soit utilisé pour l’exclusion mutuelle ou pour mettre en oeuvre une synchronisation pure entre
plusieurs tâches, le mécanisme de synchronisation par sémaphore est le même, La différente
fondamentale existant entre ces deux mécanismes réside dans la valeur d’initialisation de la variable de
sémaphore :
· Utilisée pour réaliser une exclusion mutuelle, une variable de sémaphore doit être initialisée
avec une valeur strictement positive,
· Utilisée pour mettre en oeuvre une synchronisation entre plusieurs tâches, une variable de
sémaphore peut être initialisée avec n’importe quelle valeur positive, négative ou nulle.
Figure 4.16: Exemple de blocage entre deux tâches (interblocage)

L’étude de la synchronisation entre tâches doit être effectuée avec soin. En effet, lorsque la
synchronisation est complexe, on peut facilement trouver des cas d’interblocage où les tâches se
bloquent mutuellement sans possibilité de réactivation, sauf par synchronisation directe. La figure 4.16
est un exemple de blocage (deadlock) de deux tâches entre elles.
Les deux tâches A et B s’attendent mutuellement pour achever une séquence. Il est à noter que ce type
de blocage, appelé aussi étreinte fatale peut se produire quelle que Soit la valeur d’initialisation des
variables de sémaphore Sa et Sb.
1.4.4. / LA COMMUNICATION ENTRE TACHES
Afin d’assurer la coopération entre tâches, il est nécessaire que celles-ci puissent échanger des
informations sous la forme de messages. Ces messages peuvent contenir directement les données
transmises entre les tâches ou bien servir de pointeur vers des messages plus importants. Nous allons
développer ici trois mécanismes de communication parmi les plus intéressants et les plus utilises.
1.4.4.1./ Communication par variables communes
A chaque tâche est, en général, associée une zone mémoire qui leur est propre. Le principe du
mécanisme de communication par variables communes, consiste à affecter une zone de mémoire
commune à l’ensemble des tâches et à loger dans cette zone tous les messages pouvant être échangés.
Zone
Figure 4. 17 : communication par variables communes Critique

Ces messages sont représentés par des variables appelées variables communes. Ce mécanisme de
communication fait alors intervenir à la fois la notion de sémaphore d’exclusion mutuelle [Exmu] et la
notion de sémaphores privés [Sb et Sc] (cf. figure 4.17) :
· Le sémaphore d’exclusion mutuelle permet aux tâches de protéger et de se partager l’accès à la

zone mémoire commune (un sémaphore d’exclusion mutuelle par zone commune).
· Les sémaphores privés permettent aux tâches de se synchroniser afin que les tâches devant
recevoir des données puissent attendre l’émission de celles-ci.
La communication réalisée à l’aide de ce mécanisme, est qualifiée de communication directe, pour les
raisons suivantes :
· Ce mécanisme fait appel à aucun objet intermédiaire (les messages sont directement envoyés
d’une tâche à une autre).
· Pour le mettre en oeuvre les sémaphores privés, il est nécessaire de connaître les tâches à
synchroniser de manière à placer correctement les primitives P(S) et V(S) dans le code de
chaque tâche concernée.
1.4.4.2./ Communication par boîtes aux lettres
Lors de la communication par boîtes aux lettres l’échange de messages s’effectue de manière indirecte
par l’intermédiaire d’une mémoire tampon (buffer) appelée boîte aux lettres (mailbox) organisée sous la
forme d’une file d’attente. Ce mécanisme de communication fonctionne selon le modèle
Producteur/Consommateur (cf. figure 4. 1 8) avec une mémoire tampon d’une capacité maximum de N
messages. En général, les informations échangées entre tâches sont constituées de messages de type et
de nature quelconques mais de taille fixe. De plus. le nombre de messages à transmettre est indéterminé.
Figure 4.18 : le modèle Producteur/Consommateur
La communication entre deux tâches A et B est alors réalisée selon le principe suivant :
· La tâche A produit un message et le dépose dans une boîte aux lettres commune aux deux
tâches A et B.
· La tâche B prélève le message de la même boîte et l’utilise.

La mémoire tampon est alimentée par des tâches productrices et elle est vidée par des tâches
consommatrices dans l’ordre où les messages ont été déposés. Les tâches produisent les messages à
l’aide d’une primitive du type DEPOSER (Message, NomBaL) et consomment les messages à l’aide
d’une primitive RETIRER (Message, NomBaL) qui effectuent le dépôt ou le retrait d’un Message de la
boîte aux lettres NomBaL. Toutefois, un certain nombre de règles doivent être respectées pour éviter
des incidents de synchronisation :
· Un message déposé dans une boîte aux lettres ne doit pas être consommé simultanément (il
faut attendre qu’il soit entièrement transmis).
· Une tâche productrice doit être mise en attente si elle veut déposer un message lorsque la boîte
aux lettres est pleine.
· Une tâche consommatrice doit être mise en attente si elle veut retirer un message lorsque la
boîte aux lettres est vide.
· Une tâche productrice en attente pour déposer un message doit être débloquée dès qu’une
tâche consommatrice prélève un message (puisque à ce moment là la boîte aux lettres n’est plus
pleine).
· Une tâche consommatrice en attente pour retirer un message doit être débloquée dès qu’une
tâche productrice dépose un message (puisque à ce moment là la boîte aux lettres n’est plus
vide).
Ces problèmes de synchronisation sont très simplement résolus à l’aide des notions de sémaphores
d’exclusion mutuelle et de sémaphores privés : En effet, pour ce qui concerne le point n0 1, un
mécanisme d’exclusion mutuelle sur le message suffira à protéger ce dernier d’une écriture et d’une
lecture simultanée. Il est à noter qu’actuellement dans la majeure partie des systèmes cette exclusion
mutuelle est réalisée par un sémaphore protégeant l’accès à la boîte aux lettres concernée et que la mise
en place de ce mécanisme est en général intégrée au sein même des deux primitives DEPOSER et
RETIRER (ce qui dispense le concepteur de l’application de s’en préoccuper). D’autre part, pour ce qui
concerne les points 2, 3, 4 et 5, le problème de la synchronisation peut être résolu de manière simple à
l’aide de deux sémaphores privés : l’un qu’on appellera PlacesLibres, l’autre qu’on nommera Messages
:
· La variable de sémaphore PlacesLibres doit être initialisée avec le nombre de positions libres
dans la boîte aux lettres susceptibles de recevoir un message (c’est à dire N).
· La variable de sémaphore Messages doit être initialisée avec le nombre de messages

disponibles dans la boîte aux lettres et susceptibles d’être consommés (c’est à dire zéro).
· Dans les deux cas, les files d’attente F(PlacesLibres) et F(Messages) doivent, bien entendu,
être vides à l’initialisation.

On peut alors définir deux procédures capables de mettre en oeuvre une telle synchronisation (cf. figure
4.19). Ainsi, toute tâche désireuse de déposer un message dans une boîte aux lettres doit pour cela faire
appel à la procédure ENVOYER ayant pour paramètres: le message à proprement dit (Mess) et le nom
de la boîte aux lettres concernée (BaL). De même, toute tâche désireuse de retirer un message d’une
boîte aux lettres, doit pour cela utiliser un appel à la procédure RECEVOIR ayant les mêmes paramètres
que la procédure ENVOYER, à savoir: le message Mess et le nom de la boîte aux lettres BaL.
Dans la procédure ENVOYER la primitive DEPOSER est protégée par un appel à la primitive
P(PlacesLibres). Ainsi, tant que la boîte n’est pas pleine, c’est à dire tant qu’il reste des places libres
dans la boîte aux lettres (PlacesLibres > 0), les tâches désireuses de déposer un message prendront un
droit d’accès à la boîte BaL et pourront y déposer leur message. Par contre, dès que la boite BaL est
pleine (PlacesLibres ≤ O), l’appel à la primitive P(PlacesLibres) interdira tout dépôt de message en
provoquant la mise en attente, dans la file d’attente F(PlacesLibres), des tâches qui exécuteront alors
cette primitive.
Figure 4.19 : Utilisation et algorithmes des procédures ENVOYER et RECEVOIR
De la même manière, la primitive RETIRER se trouvant dans la procédure RECEVOIR est protégée
par un appel à la primitive P(Messages). Ainsi, tant qu’il y a un message à consommer (Messages > 0),
les tâches désireuses d’en retirer un prendront un droit d’accès aux messages et pourront alors retirer le
leur. Par contre, dès qu’il n’y a plus de messages dans la boîte aux lettres (Messages ≤ 0), l’appel à la
primitive P(Messages) interdira tout retrait de message en provoquant la mise en attente, dans la file
d’attente F(Messages), des tâches qui exécuteront alors cette primitive.

D’autre part, lorsqu’une tâche vient de déposer un message dans une boîte elle le signale grâce à la
primitive V(Messages) placée juste en sortie de la procédure ENVOYER. Ainsi, si la variable de
sémaphore Messages est inférieure ou égale à zéro, ce qui signifie donc qu’il existe des tâches en attente
dans la file d’attente du sémaphore F(Messages), la primitive V(Messages) débloquera
automatiquement la tâche se trouvant en tête de cette file et qui pourra alors recevoir le message. De la
même manière, lorsqu’une tâche vient de retirer un message d’une boîte aux lettres, elle le signale à
l’aide de la primitive V(PlacesLibres) placée juste en sortie de la procédure RETIRER. Ainsi, si la
variable de sémaphore PlacesLibres est inférieure ou égale à zéro, la primitive V(PlacesLibres)
débloquera automatiquement la tâche se trouvant en tête de la file d’attente F(PlacesLibres) (s’il en
existe une) qui pourra alors déposer un message à l’emplacement libéré.
Avec cette méthode de communication, les tâches peuvent ainsi prendre et mettre des messages dans
une boîte aux lettres sans se bloquer, sauf lorsque la boîte est pleine ou vide. Le mécanisme de
synchronisation entre les tâches qui communiquent est alors réduit au minimum.
1.4.4.3./ Communication par Rendez-vous
Le mécanisme de communication par Rendez-vous met en oeuvre une communication entre deux tâches
de manière directe. Il est basé sur une synchronisation rigoureuse entre l’émetteur du message et le
récepteur du message. Ainsi, lorsque deux tâches doivent échanger un message, elles doivent chacune
s’arrêter en un point convenu pour que la transmission puisse avoir lieu. Ce point d’arrêt est appelé
point de rendez-vous. Il est symbolisé sur la figure 4.20 par les appels aux procédures d’échange et
marqué par deux points.
Ce type d’échange est réglé par trois primitives :
· RvENVOI (Message, Récepteur, Réponse),
· RvRECEPTION (Message, Emetteur).
· RvREPONSE (Message’, Emetteur),
Où les paramètres sont les suivants :
· Le paramètre Récepteur représente le nom (ou l’adresse logique) de la tâche à qui le message
est adressé,
· Le paramètre Emetteur représente le nom (ou l’adresse logique) de la tâche qui envoie le
message,
· Le paramètre Message représente enfin l’information échangée,
· Le paramètre Réponse est du type booléen et représente le fait que la tâche émettrice doit ou
non attendre une réponse de la tâche réceptrice,
· Le paramètre Message’ représente la réponse du récepteur à l’émetteur.

Ainsi, lorsque la tâche émettrice fait appel à la primitive RvENVOI, elle doit se bloquer en ce point de
rendez-vous jusqu’à ce que la tâche réceptrice exécute l’appel à la primitive RvRECEPTION, si cela
n’est pas déjà fait. De même, lorsque la tâche réceptrice fait appel à la primitive RvRECEPTION, elle
doit se bloquer en ce point jusqu’à ce que la tâche émettrice exécute l’appel à la primitive RvENVOI (si
cela n’est pas déjà fait).
Figure 4.20 : Mise en oeuvre d’une communication pur Rendez-vous
Lorsque les deux tâches ont atteint chacune le point de rendez-vous, l’échange du message se produit.
Après l’échange deux cas peuvent alors se présenter :
· La tâche émettrice n’a pas besoin d’une réponse du récepteur : à la fin de l’échange du
Message les deux tâches reprennent alors simultanément leur exécution,
· La tâche émettrice a besoin d’une réponse du récepteur : à la fin de l’échange la tâche

réceptrice reprend son exécution alors que la tâche émettrice reste bloquée au point de rendez-
vous. Elle reprendra son exécution seulement lorsque la tâche réceptrice exécutera l’appel à la
primitive RvREPONSE qui constitue un point de rendez-vous « auxiliaire ». La réponse
attendue (Message’) sera alors transmise à la tâche émettrice ce qui aura pour effet de
débloquer celle-ci.

1.5. / LA GESTION DE LA MÉMOIRE

Un programme ne peut être exécuté que si ses instructions et ses données sont en mémoire physique. Si
l’on désire exécuter plusieurs programmes simultanément, il faut donc que chacun soit chargé en
mémoire (même partiellement). Le système d’exploitation doit alors allouer à chaque programme des
zones de la mémoire. Chaque fois qu’un utilisateur demande le lancement d’un programme, le système
doit trouver une place en mémoire pour le charger. Cette allocation pose un certain nombre de
problèmes tous les programmes n’ont pas la même taille, ils sont lancés par les utilisateurs et se
terminent à des moments que le système ne connaît pas à l’avance...
Le concept de multiprogrammation implique donc que les programmes d’application soient chargés
dans des zones de la mémoire dont la localisation n’est décidée qu’au moment de leur chargement. Le
gestionnaire de mémoire d’un système d’exploitation prend en charge la gestion de la mémoire centrale,
il assure sa protection et fournit les informations qui permettent à chaque programme d’être exécuté
sans savoir à l’avance dans quelle zone de la mémoire il sera logé au moment de son exécution (cette
zone pouvant d’ailleurs changer entre deux exécutions, voire même en cours d’exécution). Le rôle de la
gestion de mémoire (memory management) consiste à donner à chaque utilisateur l’illusion qu’il a la
totalité de la mémoire à sa disposition et même parfois qu’il dispose d’une mémoire virtuellement
supérieure à la mémoire réelle. Le but des fonctions de gestion de la mémoire est d’augmenter le
rendement global du système en permettant l’exécution performante des programmes. L’accès d’un
programme à une information se traduit par l’accès du processeur à un emplacement de mémoire
adressable par ce processeur.
Dans ces conditions, la mémoire d’un calculateur est une ressource critique au même titre que le
processeur. Cet organe est si important pour les ordinateurs actuels, que la plupart en sont dotés de
plusieurs types, de différentes tailles et de différentes vitesses. Bien entendu, la taille d’une mémoire et
sa vitesse d’accès conditionnent fortement les performances globales d’une machine et son prix. La
plupart des gestionnaires de mémoire utilisent des fonctions de gestion basées sur deux principes
généraux :
- Le partage de l’espace : qui consiste à affecter à chaque utilisateur des zones différentes de la
mémoire. Cette technique pose le problème de la capacité mémoire.
- Le partage du temps: qui consiste à allouer la mémoire à l’utilisateur dont le programme est
en cours d’exécution par le processeur. Cette technique pose le problème du temps de gestion
puisqu’elle met en oeuvre des mécanismes de sauvegarde et de restauration de données entre la
mémoire centrale et la mémoire de masse.
La meilleure utilisation de la mémoire réside donc d’un compromis entre l’espace mémoire offert aux
utilisateurs et le temps d’exécution qui s’allongera si les sauvegardes et les restaurations des données
sont trop fréquentes.

1.5.2. / HIERARCHIE DES MEMOIRES
Les concepteurs de machines informatiques ont toujours déployé des trésors d’imagination afin de doter
leurs machines de mémoires rapides, tout en évitant d’augmenter le prix de façon trop importante. C’est
ainsi qu’au milieu des années 80 est apparue une véritable hiérarchie des mémoires
1.5.2.1./ Les registres
Les registres sont des mémoires extrêmement rapides et donc très chères. On les trouve en petit nombre
(en général inférieur à 100) dans une machine. Ils sont immédiatement accessibles par le processeur (en
général en 1 cycle).
1.5.2.2./ La mémoire cache
Les mémoires du type cache ou antémémoire (cache memory) sont des mémoires accessibles en 1 à 10
cycles. Elles contiennent quelques dizaines de milliers de mots (quelques Ko). Leur fonction consiste à
accélérer les accès à la mémoire par l’unité centrale. Elles jouent le rôle de mémoire tampon entre la
mémoire centrale et les registres.
1.5.2.3./ La mémoire centrale
La mémoire centrale (main memory) est accessible en 5 à 20 cycles. Elle est composée de circuits
intégrés de type DRAM (Dynamic Random Access Memory) pouvant contenir chacun de 64 Kbits à I
Mbits. La taille d’une mémoire centrale peut varier de 1 à plusieurs centaines de Mo. Les circuits utilisés
nécessitent un rafraîchissement périodique des données. Ce rafraîchissement est dû à la technologie
utilisée qui est à base de transistors MOS dont la capacité de grille se décharge dans le temps et qu’il
faut donc maintenir. Il est réalisé soit par l’unité centrale (cas des microprocesseurs), soit par un
contrôleur de mémoire qui décharge ainsi totalement l’unité centrale de cette tâche auxiliaire (cas des
mini-ordinateurs ou des grosses machines).
1.5.2.4./ La mémoire d’arrière-plan
La mémoire d’arrière plan (background memory) se trouve aujourd’hui sur certaines machines. Elle est
constituée de circuits semi-conducteurs de faible vitesse (vitesse d’accès variant entre 20 et 100 cycles)
et de faible prix. Les mémoires d’arrière-plan sont généralement connectées de la même manière qu’un
disque magnétique. Elles jouent le rôle de mémoire tampon entre la mémoire centrale et la mémoire de
masse.

1.5.2.5./ La mémoire de masse
La mémoire de masse (mass storage) d’un ordinateur est constituée de supports magnétiques du type
disque, disquette, bande magnétique, disque optique... Ces mémoires sont permanentes (les
informations restent valides lorsqu’on coupe l’alimentation). Elles peuvent être de très grande capacité
1 Go à 100 Go pour les disques et 2 Go à 20 Go pour les bandes et les disques optiques. Par contre leur
vitesse d’accès est élevée et varie de quelques milli-secondes à 50 ms pour les disques. Elle est encore
bien supérieure pour les bandes magnétiques qui en raison de leur nature nécessitent obligatoirement un
accès séquentiel ce qui engendre donc des temps de recherche élevés.
Pour cette raison, avec les systèmes informatiques modernes, les bandes magnétiques ne servent qu’à
l’archivage ou au stockage de grands ensembles d’informations manipulées de manière ordonnée.
1.5.3. / ESPACE PHYSIQUE ET ESPACE VIRTUEL
L’espace mémoire virtuel est le nombre de cases de mémoire qu’un programme peut adresser
directement. Ce nombre dépend du nombre de bits dans une adresse, c’est à dire de la taille des mots de
la mémoire qui contiennent les adresses. Par exemple :
- Sur une machine à mots de 16 bits (où les adresses sont codées sur 16 bits) on peut adresser
216 positions mémoires. Si l’unité d’adressage est l’octet, on dispose donc d’un espace virtuel
de 64 Ko (ou 32 Kmots de 16 bits).
- Sur une machine 32 bits, on peut adresser 232 positions. Si l’unité est l’octet, l’espace
accessible sera alors de 4 Go.
La mémoire physique disponible sur une machine peut avoir une taille différente de l’espace virtuel
disponible pour chaque programme. Deux cas peuvent se présenter : soit l’espace physique est
supérieur à l’espace virtuel, soit il lui est inférieur.
1.5.3.1./ Espace physique supérieur à l’espace virtuel
On rencontre ce type de configuration lorsque l’espace virtuel est « petit » (cas des machines 16 bits).
Dans ce cas, plusieurs programmes ou plusieurs modules d’un même programme pourront être chargés
à la fois. Par exemple, avec une mémoire de 1 Mo sur une machine 16 bits, chaque programme ne
pourra accéder individuellement qu’à 64 Ko de mémoire (du fait des adresses codées sur 16 bits). Par
contre, l’exécution de plusieurs tâches ou de plusieurs programmes pourra s’enchaîner immédiatement,
sans avoir à attendre le chargement de la tâche ou du programme devant être exécuté. L’unité centrale
doit donc être capable de générer des adresses physiques comportant un plus grand nombre de bits que
les adresses virtuelles. Cette génération d’adresses est réalisée par le gestionnaire de mémoire, souvent
aidé par un mécanisme matériel spécial du type M.M.U. (Management Memory Unit), constitué de
circuits intégrant directement des fonctions de gestion de mémoire.

La méthode la plus courante pour gérer ce type de mémoire est celle des registres de base (base
register). Ce mécanisme est le suivant (cf. figure 5.1) :
- Les programmes sont relogeables et toutes les adresses sont logiques (relatives à l’adresse zéro
correspondant au début de l’espace virtuel du programme),
- Un registre spécial de l’unité centrale, appelé registre de base, contient l’adresse physique du
début du programme dans la mémoire,
- Chaque accès à la mémoire s’effectue en ajoutant à l’adresse virtuelle trouvée dans le

programme le contenu du registre de base associé.
L’adresse physique du mot désigné dans le programme par son adresse virtuelle est calculée
dynamiquement (pendant l’exécution du programme). Le mécanisme de gestion de la mémoire doit faire
l’opération :
Adresse logique + (Registre de base) = Adresse physique
Ainsi, si le gestionnaire de mémoire désire changer la localisation mémoire d’une tâche, il lui suffira de
mettre, la nouvelle adresse physique du début de la zone mémoire qui lui est allouée, dans le registre de
base et de continuer l’exécution. Ce changement de place sera alors totalement transparent pour la
tâche.
Figure 5.1 : Principe de l’adressage par registre de base
Le registre de base fait partie du contexte d’un programme : les programmes qui sont en mémoire, mais
pas en cours d’exécution, ont une copie de leur registre de base dans leur descripteur. Cette copie est
chargée dans le registre physique de l’unité centrale, en même temps que les registres généraux, dès que
le système donne la main au programme.

1.5.3.2./ Espace physique inférieur à l’espace virtuel
On rencontre ce type de configuration actuellement dans la plupart des machines 32 bits (ou plus),
puisque pratiquement aucune machine ne dispose de 4 Go de mémoire physique.
Figure 5.2 : Principe de la mémoire virtuelle
Ainsi, pour permettre une utilisation efficace de la mémoire centrale, la plupart des machines qui
disposent d’un espace virtuel très grand ont actuellement recours à une technique de gestion de
mémoire virtuelle (cf. figure 5.2), non seulement pour des raisons de prix mais également pour des
raisons d’efficacité du partage de la mémoire. Le principal intérêt de cette méthode réside dans le fait
que l’on peut exécuter un programme dont la taille est supérieure à la taille de la mémoire physique
disponible. Puisque tout le programme ne peut pas être logé en mémoire, le mécanisme de gestion de
mémoire doit être capable de charger, à un moment donné, les parties du programme nécessaires à son
exécution.
Deux mécanismes de gestion de mémoire virtuelle, rendant ce chargement automatique, ont été
développés la pagination et la segmentation. Ces deux mécanismes seront présentés de manière détaillée
dans ce chapitre (cf. §5 de ce chapitre).
1.5.4. / LES FONCTIONS DE BASE
Quelle que soit la méthode de gestion de la mémoire d’un calculateur, les techniques utilisées font appel
à cinq fonctions de base.
1.5.4.1./ Transformation adresses logiques / adresses physiques
Afin d’éviter que l’utilisation de la mémoire soit figée, les adresses manipulées directement par
l’utilisateur sont des adresses logiques (nom de variables, symboles...) et non des adresses physiques
(adresses réelles). Pour faire l’opération de transformation des adresses logiques en adresses réelles, le
gestionnaire de mémoire utilise une carte de la mémoire (memory mapping) ou des registres de base.
Ainsi, les adresses physiques peuvent être fixées :

- Quand des modules compilés séparément sont traités par un éditeur de liens (linker) pour
produire du code exécutable,
- Quand le programme (code relogeable utilisant des adresses logiques) est chargé en mémoire à
partir de la mémoire de masse (loader) en vue de son exécution (translation d’adresses
statiques),
- Quand le programme est en cours d’exécution (translation dynamique) pour lui permettre une
gestion dynamique de données ou lors de l’exécution par le gestionnaire de mémoire de
fonctions spécifiques de récupération d’emplacements libres...
1.5.4.2./ Partage de la mémoire physique
Le problème du partage de la mémoire physique se pose lorsqu’un module logiciel doit être partagé
entre plusieurs utilisateurs ou bien lorsque plusieurs tâches doivent se partager une structure de données
qui leur est commune. Dans le premier cas, le problème peut être résolu simplement en effectuant une
duplication du module concerné. Chaque utilisateur possède alors une copie de ce module dans l’espace
mémoire qui lui est alloué. Dans le cas d’une structure de données partagée, une duplication n’est pas
possible. Il faut donc que les taches se synchronisent entre elles pour que la structure de données reste
cohérente. Des mécanismes de synchronisation tels que ceux que nous avons développés au cours du
chapitre 4, peuvent alors être utilisés afin de gérer l’utilisation de la structure au moyen de sections
critiques, par exemple.
1.5.4.3./ Allocation de la mémoire
L’allocation de la mémoire consiste à allouer des blocs de la mémoire physique aux tâches des divers
utilisateurs. Cette allocation peut être statique ou dynamique
1.5.4.3.1./ Allocation statique
Lorsque l’allocation de la mémoire est statique, une zone de mémoire est affectée à un utilisateur une
fois pour toutes, pendant toute son activité. Un utilisateur ne peut pas déborder de sa zone même si les
autres utilisateurs n’utilisent pas toute la mémoire qui leur a été allouée. La traduction des adresses
logiques en adresses physiques est alors réalisée au moment du chargement du programme.
1.5.4.3.2./ Allocation dynamique
Lorsque l’allocation de la mémoire est dynamique, un bloc de mémoire n’est alloué à une tâche que
lorsque celle-ci en a réellement besoin. Les blocs ne sont pas toujours de taille fixe. Suivant leur
disposition en mémoire, une quantité de mémoire plus ou moins grande sera morcelée et deviendra
inutilisable pour être allouée sous la forme de bloc.

Ainsi, pendant le déroulement de la tâche, le gestionnaire de mémoire peut être amené àdéplacer un bloc
alloué d’une adresse physique à une autre pour optimiser l’utilisation de la mémoire (dynamic relation).
L’allocation dynamique et le déplacement de blocs ne sont possibles que lorsque le système
informatique dispose d’unité de gestion de la mémoire du type M.M.U. Dans le cas contraire, les temps
de gestion deviendraient prohibitifs.
1.5.4.4./ La protection
Lorsque plusieurs tâches se partagent la mémoire, il est essentiel pour leur intégrite qu’aucune d’entre
elles ne puisse altérer les zones de la mémoire allouées aux autres tâches. Le problème de la protection
des espaces mémoire présente deux aspects :
- Le système doit être capable de détecter la pénétration (accidentelle ou malveillante) d’un

espace mémoire alloué à une tâche par une tâche étrangère,
- Le système doit être capable de traiter et de maîtriser une pénétration une fois qu’elle a eu lieu
et bien avant qu’elle ait des conséquences néfastes et définitives.
La protection des espaces traitée de manière logicielle est pratiquement impossible à cause des temps de
gestion démesurés qui seraient ajoutés au temps d’exécution des tâches. Néanmoins, certaines
protections peuvent être effectuées lors des translations d’adresses logiques en adresses physiques. Elles
ne peuvent être réalisées que si le système informatique dispose de l’aide de circuits du type M.M.U.
pour cette tâche et à condition qu’en plus des tables d’allocation. les droits d’accès des tâches aux blocs
de mémoire soient spécifiés.
1.5.4.5./ Extension de l’espace mémoire
Lorsque la mémoire réelle formée par l’ensemble de l’espace adressable (extensions physiques
comprises) est insuffisante pour l’application que l’on désire traiter, deux options sont possibles :
- Soit le système d’exploitation offre à l’utilisateur des primitives lui permettant de découper son
application afin qu’elle puisse être au moins partiellement logée en mémoire centrale,
- Soit il met en oeuvre un mécanisme transparent à l’utilisateur afin que celui-ci travaille sur une
mémoire virtuelle plus grande que la mémoire réelle en prenant totalement en charge ce
découpage.
Parmi les principales techniques de découpage d’une application offertes par les systèmes
d’exploitation, nous en avons retenu trois que nous allons définir ici, avant d’aborder dans les
paragraphes suivants les mécanismes de gestion de la mémoire virtuelle.

1.5.4.5.1./ Technique de l’overlay
Avec cette technique, appelée également segmentation manuelle, le programme principal ainsi que
toutes les variables globales sont présents en mémoire centrale. Par contre, les procédures dont il a
besoin ne sont chargées que pour leur exécution. Le découpage du programme est un découpage
logique.
Supposons que l’on dispose de 10 Ko de mémoire et que la compilation séparée d’un programme
principal A et des modules B, C, D, E et F donne les tailles suivantes d’occupation mémoire A (4 Ko) +
B (1 Ko) + C (3 Ko) + D (3 Ko) + E (2 Ko) + F (1 Ko), soit 14 Ko au total. Dans ce cas, le programme
A sera chargé en mémoire et les routines B, C, D, E, et F seront stockées en mémoire de masse. Elles
seront chargées lorsque le programme en aura besoin et enlevées de la mémoire pour y faire de la place
quand le programme n’en aura plus besoin.
1.5.4.5.2./ Technique du chaining (ou pagination manuelle)
Cette technique permet de découper une application dans le temps. Dans ce cas, seules les variables
globales sont présentes en mémoire centrale. Le programme est découpé en blocs de taille identique
chargés en séquence au fur et à mesure de leur exécution. Le découpage du programme est un
découpage physique. La mise en oeuvre de ce mécanisme est identique celle de l’overlay.
1.5.4.5.3./ Technique du swapping
Cette technique, dite du va et vient, est la plus couramment utilisée dans les systèmes multitâches. Elle
consiste à suspendre temporairement certaines tâches en sauvegardant en mémoire de masse tout
l’espace mémoire qui leur a été attribué, afin d’allouer cet espace aux autres tâches. Dans le cas d’un
seul utilisateur, ce mécanisme impose de découper l’application en tâches autonomes. D’autre part, la
sauvegarde et la restauration des espaces mémoire sont très coûteuses en temps dès que la taille des
tâches augmente. Ainsi, dans certains cas, une telle démarche est impossible dans les systèmes temps-
réel.
Lorsque le système met en oeuvre de manière transparente à l’utilisateur la gestion d’un espace
adressable logique (adresses virtuelles) supérieur à un espace physique (adresses réelles). nous avons vu
qu’il devait offrir un mécanisme de gestion de mémoire virtuelle. Ce sont ces mécanismes que nous
allons maintenant détailler.
1.5.5. / LA MEMOIRE VIRTUELLE
Un programme n’a pas besoin d’être entièrement en mémoire à tout instant: la partie active d’un
programme est souvent petite par rapport à sa longueur totale. En disposant d’un mécanisme permettant
de charger en mémoire physique que la partie active de chaque programme (qui change au fur et à
mesure de son déroulement) une place importante en mémoire serait gagnée. D’autre part, si de tels
mécanismes étaient disponibles, l’exécution de programmes plus gros que la mémoire physique
disponible ou encore celle d’un grand nombre de programmes (concurrents ou non) serait possible.

Les mécanismes de mise en oeuvre et de gestion de la mémoire virtuelle que nous allons décrire ici,
répondent à ces objectifs de manière transparente pour l’utilisateur. Ils se distinguent par leur façon
d’aborder à la fois le problème du découpage de l’espace virtuel (programme et données) et de l’espace
réel (mémoire physique). La notion de ressource virtuelle conduit à séparer les problèmes d’utilisation
d’une ressource particulière, des problèmes d’allocation de cette ressource. Pour une tâche, la mémoire
virtuelle est le support de l’ensemble des informations potentiellement accessibles, c’est-à-dire
l’ensemble des emplacements dont l’adresse peut être engendrée par le processeur. L’allocation de la
mémoire consiste à concrétiser cette mémoire virtuelle par des supports physiques d’informations, tels
que la mémoire principale, les disques magnétiques... L’accès d’une tâche à une information se traduira
de toute manière toujours par l'accès d’un processeur à un emplacement de mémoire adressable par ce
processeur.
1.5.5.1./ Les informations accessibles à une tâche
Les informations auxquelles une tâche peut avoir accès sont définies par l’ensemble des informations
désignables dans son programme : les objets, l’ensemble des informations de désignation : les noms et la
mise en correspondance noms/objets. Dans un programme écrit en langage évolué, les noms et les
objets sont définis par le langage lui-même. Ils sont différents de ceux que manipule le processeur.
Le programme doit donc subir une série de transformations, appelée liaison. Cette série comporte :
- Une étape de traduction : qui met en correspondance des objets avec les emplacements
mémoire et des noms avec les adresses relatives correspondantes,
- Une étape d’édition de liens : qui réalise la liaison entre des modules et des programmes
traduits séparément ainsi qu’avec les bibliothèques du langage,
- Une étape de chargement: qui opère une fixation définitive des adresses (définies jusque là, à
une translation près).
Figure 5.3 : Séparation des problèmes de désignation et d’allocation
La figure 5.3 est une schématisation de la séparation conceptuelle des problèmes de désignation et
liaison, d’une part, et des problèmes d’allocation, d’autre part.

1.5.5.2./ Organisation de la mémoire virtuelle
Les organisations de la mémoire virtuelle que l’on rencontre le plus souvent sont fonction, à la fois de la
structure et de l’organisation physique de la mémoire, ainsi que des algorithmes la réalisation de cette
de gestion. Néanmoins les deux plus courantes sont les suivantes.
1.5.5.2.1./ Mémoire virtuelle linéaire
Une mémoire virtuelle linéaire est constituée d’une suite d’emplacements identiques appelés mots,
organisés séquentiellement et désignés par des entiers consécutifs appelés adresses virtuelles.
Un objet est alors une information occupant un ou plusieurs mots consécutifs, désignée par l’adresse
virtuelle du premier mot. Cette organisation est donc identique à celles des emplacements d’une
mémoire physique.
1.5.5.2.2./ Mémoire virtuelle segmentée
Une mémoire virtuelle segmentée est constituée d’un ensemble d’emplacements de taille variable
constitués d’une suite de mots et regroupant des informations de même nature. Les mots contenus sont
désignés par des entiers consécutifs appelés déplacements (offset). L’adresse virtuelle d’un mot, alors
appelée adresse segmentée, est relative à l’adresse virtuelle de son segment.
1.5.5.3./ La segmentation
La segmentation est un mécanisme de gestion de la mémoire virtuelle qui consiste à découper l’espace
adressable d’un programme en segments qui n’ont aucun besoin d’occuper des emplacements contigus
en mémoire.
Les segments correspondent à une division logique d’un programme en modules, sous programmes,
données globales, données locales... Ils sont donc implicitement définis par l’utilisateur lors de la phase
de conception du programme et dépendent du niveau de modularité de ce dernier.
Les segments regroupent en général des éléments de même nature segments de code, segments de
constantes ou de variables, segments contenant des structures, des tableaux ou encore des fichiers...
Ils sont logés en mémoire centrale ou en mémoire de masse. Le mécanisme de gestion (cf. figure 5.4)
qui permet alors de passer d’une adresse logique à une adresse physique est basé sur l’utilisation d’une
table des segments.

Figure 5.4 : Principe d’une mémoire segmentée
1.5.5.3.1./ La table des segments
A chaque segment est associé un descripteur qui contient l’ensemble des informations nécessaires à son
identification et à son utilisation par le gestionnaire de mémoire. Ces informations sont en général
regroupées en deux champs distincts :
· Le champ Bits de contrôle indiquant si le segment est présent ou non en mémoire principale,
s’il a été modifié, ses autorisations de lecture et/ou d’écriture...,
· Le champ Adresse donnant au gestionnaire de mémoire la position effective du segment en

mémoire principale, si le segment y est chargé, ou permettant sa localisation en mémoire
auxiliaire dans le cas contraire.
A chaque programme est associée une table des segments regroupant l’ensemble des descripteurs de
segment. Cette table est le dispositif qui permet de relier l’espace logique d’un programme segmenté et
la mémoire physique. L’adresse physique du début de cette table est indiquée par le registre de base de
la table des segments RTS (cf. figure 5.5).

@ réelle du mot.
offset
@ de
base @ des
de la segments
table. en Mem
taille C
@ du
segment
dans la
table.
Figure 5.5 : Adressage dans une mémoire segmentée
RTS
1 L1 @B1
2 L2 @B2 Système
tâches
3 L3 @B3
@B1
S1
L1
@
@B2
S2 N° du segment Offset (d)
L2
@B3 RTS
S3
L3
1 L3 @B3
d
S3

1.5.5.3.2./ Adressage d’une mémoire virtuelle segmentée
Le principe de l’adressage d’une mémoire segmentée est représenté par la figure 5.5. Pour adresser une
information dans ce type d’organisation, le gestionnaire de mémoire d’un système d’exploitation utilise
la table des segments, le registre de base RTS et l’adresse logique du mot adressé. Cette adresse logique
est composée de deux parties :
- Un Numéro de segment qui sert d’index dans la table des segments,
- Un Déplacement qui donne la position effective du mot dans le segment.
Le Numéro de segment est ajouté au contenu du registre RTS. Cette opération permet de calculer
l’adresse du descripteur du segment contenant le mot adressé, dans la table des segments. Cette adresse
permet d’identifier l’entrée et d’accéder ainsi aux bits de contrôle du segment concerné. Le gestionnaire
de mémoire peut alors tester le bit de contrôle de présence du segment. Deux cas peuvent alors se
présenter :
- Le segment est présent en mémoire centrale : dans ce cas, la valeur du champ Adresse
comporte deux parties nécessaires pour son repérage : une partie Limite renseignant sur la
longueur effective du segment et une partie Base contenant l’adresse de base du segment,
- Le segment est absent de la mémoire centrale : dans ce cas, une interruption appelée faute de
segment ou défaut de segment (segment fault) est générée. Le champ Adresse contient alors
les informations permettant de localiser le segment en mémoire auxiliaire.
Lorsque le segment est présent en mémoire principale, l’adresse physique du mot adressé est calculée en
ajoutant à l’adresse de Base du segment, contenue dans le descripteur, la valeur du Déplacement,
contenu dans l’adresse logique. Dans le cas contraire, l’interruption défaut de segment signale au
gestionnaire que le segment n’est pas chargé. Le gestionnaire fait alors appel à une fonction de
chargement du segment en mémoire centrale, qui va utiliser l’information se trouvant dans le champ
Adresse du descripteur de segment pour aller chercher le segment concerné sur disque, puis le copier
dans un espace libre de la mémoire physique. Les bits de contrôle ainsi que le champ Adresse du
descripteur du segment concerné sont alors mis à jour. Il suffit ensuite d’ajouter la valeur du
Déplacement à l’adresse de Base du segment, nouvellement calculée, pour obtenir l’adresse physique du
mot en mémoire centrale.
On peut noter qu’en dehors des vérifications pouvant être réalisées par l’utilisation des bits de contrôle,
une protection supplémentaire peut être mise en oeuvre lors de l’adressage d’un mot l’évitement de la
pénétration de l’espace mémoire d’un segment voisin. Cette protection est réalisée en général
directement au niveau matériel par l’unité de gestion de mémoire (M.M.U.) qui compare la valeur du
champ Déplacement de l’adresse logique d’un mot avec la valeur du champ Limite du descripteur de
segment qui contient ce mot :
Si Déplacement ≤ Limite Alors l’adresse est correcte
Si Déplacement > Limite Alors il y a violation de l’espace voisin

1.5.5.3.3./ Traitement d’un défaut de segment
Lorsqu’une interruption défaut de segment est générée, le gestionnaire de mémoire doit alors trouver un
emplacement en mémoire physique susceptible de recevoir le segment concerné. Dans ce cas, deux
possibilités sont envisageables il existe ou non un emplacement libre et non attribué de taille
suffisamment importante pour y loger le segment. S’il en existe un, le gestionnaire mettra alors en
oeuvre un mécanisme de copie du segment de la mémoire auxiliaire à la mémoire principale. S’il n’en
existe pas, le gestionnaire de mémoire doit alors choisir de libérer une partie de la mémoire pour y loger
le segment. Il peut alors faire appel à des algorithmes plus ou moins complexes (cf. §5.6 de ce chapitre)
réalisant la libération des segments les plus anciennement chargés en mémoire ou encore la libération de
ceux qui sont les plus rarement utilisés.
Si le gestionnaire dispose de l’aide d’un circuit spécialisé du type M.M.U., il peut aussi mettre en
oeuvre un mécanisme permettant de regrouper des espaces libres afin d’en constituer un de taille
suffisamment importante. Une fois qu’une partie de la mémoire eut été libérée, le segment pourra alors
y être chargé à partir de la mémoire auxiliaire.
Nous avons vu qu’un segment correspondait à une entité de longueur variable. Sa taille dépend dans une
large mesure de la taille des éléments elle contient et donc des habitudes de programmation des
programmeurs et du découpage logique de leurs applications. Cette propriété peut amener à un
gaspillage de l’espace mémoire résultant d’un phénomène de fragmentation de celui-ci. En effet,
lorsqu’un programme se termine, l’espace mémoire qui lui avait été alloué est récupéré par le système
pour pouvoir être affecté, par la suite à d’autres applications. La mémoire peut ainsi être très vite
morcelée en fragments difficilement utilisables du fait de leur trop petite taille. Il deviendra alors difficile
de loger dans ces espaces de nouveaux segments.
Le problème de la fragmentation de la mémoire qui était pratiquement transparent sur les processeurs
16 bits du fait d’une limitation de 64 Ko par segment, prend toute son importance sur les processeurs
32 bits où la taille des segments n’est alors limitée qu’à 4 Go. Avec ce type de processeur, la taille des
segments peut donc être très grande et surtout beaucoup plus élevée que celle de la mémoire réelle. Le
découpage logique des applications peut alors entraîner la conception des segments de taille supérieure
à la celle de la mémoire réelle. Il devient alors impossible d’exécuter des applications comportant des
segments de grande taille simplement avec une mémoire segmentée. C’est pour ces raisons que les
mécanismes de pagination et de segmentation paginée ont été développés.
1.5.5.4./ La pagination
La pagination est un mécanisme de gestion de la mémoire virtuelle qui permet un découpage de la

mémoire de manière uniforme. Pour cela, l’espace logique de chaque programme est découpé en pages
de même taille. L’espace physique de la mémoire est quant à lui découpé en blocs de même taille que la
taille des pages de l’espace logique. Chaque bloc peut alors contenir physiquement une page. Le
mécanisme de gestion (cf. figure 5.6) qui permet de passer d’une adresse logique à une adresse physique
est semblable à celui de la segmentation. Il est basé sur l’utilisation d’une table des pages.

Figure 5.6 : Principe d’une mémoire virtuelle paginée
1.5.5.4.1.La table des pages
A chaque page est associé un descripteur de page qui contient l’ensemble des informations nécessaires à
son identification et à son utilisation par les fonctions du gestionnaire de mémoire :
· Les Bits de contrôle indiquant si la page est oui ou non présente, Si elle a été modifiée ou non,
les autorisations de lecture et/ou d’écriture...
· Le champ Adresse qui contient l’adresse effective d’un bloc si la page est présente ou une
information permettant la localisation d’un bloc en mémoire auxiliaire (en général un disque)
dans le cas contraire.
La table des pages est le dispositif regroupant l’ensemble des descripteurs de page. Elle permet la
relation entre l’espace logique d’un programme et la mémoire physique. Il y a une table des pages pour
chaque programme (ou tâche). L’adresse de rangement du début de cette table est indiquée par un
registre de base RTP (cf. figure 5.7).

Figure 5.7 : Mécanisme d’adressage d’un mot dans une mémoire paginée
1.5.5.4.2./ Adressage d’une mémoire virtuelle paginée
Le mécanisme d’adressage d’une information dans une mémoire paginée (cf. figure 5.7) est semblable à
celui que nous avons vu lors de l’adressage dans une mémoire segmentée. Le gestionnaire de mémoire
d’un système d’exploitation utilise la table des pages, un registre de base RTP et l’adresse logique de
l’information. Cette adresse est composée de deux parties :
· Un Numéro de page qui sert d’index dans la table des pages,
· Un Déplacement dans la page qui sera ajouté à l’adresse du bloc physique contenant la page
virtuelle.
Le Numéro de page est ajouté au contenu du registre RTP. Cette opération permet de calculer l’adresse
de l’entrée correspondante dans la table des pages. Cette adresse permet d’accéder aux Bits de contrôle
de la page. Le gestionnaire de mémoire teste le bit de contrôle de présence de la page. Deux cas
peuvent alors se présenter :

- La page est présente en mémoire centrale dans ce cas, la valeur du champ Adresse contient le
numéro du bloc physique dans laquelle se trouve la page virtuelle cherchée,
- La page est absente de la mémoire centrale : dans ce cas, une interruption appelée faute de
page ou défaut de page (page fault) est générée.
Lorsque la page est présente, le gestionnaire assemble l’adresse du début du bloc dans laquelle se trouve
la page avec le Déplacement pour obtenir l’adresse réelle complète. Lorsque la page n’est pas présente
en mémoire centrale, une interruption « défaut de page » signalant au gestionnaire que la page n’est pas
chargée, est alors générée. Le gestionnaire de mémoire doit alors charger la page en mémoire centrale à
partir de la mémoire auxiliaire.
1.5.5.4.3./ Traitement d’un défaut de page
Lorsqu’une interruption défaut de page est générée et qu’il n’existe pas de bloc libre en mémoire
principale, le gestionnaire de mémoire doit alors choisir d’en libérer un. Ce choix peur faire appel à des
algorithmes plus ou moins complexes (cf. §5.6 de ce chapitre) du même type que ceux rencontrés lors
de la gestion d’une mémoire segmentée, et réalisant la libération de la page la plus anciennement
chargée en mémoire ou encore la libération de celle qui est le plus rarement utilisée. Le choix effectif est
mis en oeuvre par la tâche de traitement de l’interruption défaut de page dont le but est de réaliser lé
chargement en mémoire centrale à partir de la mémoire auxiliaire de la page manquante nécessaire au
déroulement de la tâche en cours.
Le mécanisme de chargement de page est similaire à celui mis en oeuvre lors du traitement d’une
interruption défaut de segment : le gestionnaire de mémoire utilise l’information se trouvant dans le
champ Adresse de la table des pages pour aller chercher la page sur le disque de pagination (mémoire
auxiliaire), puis la copier dans un bloc de la mémoire physique. L’adresse physique de ce bloc est
ensuite inscrite dans le champ Adresse de la table de page et le bit de contrôle c/e présence est mis à
jour. Il suffit alors d’assembler cette adresse avec le la valeur du Déplacement pour obtenir l’adresse
physique cherchée.
1.5.5.4.4./ Notion d’espace de travail
Lorsque la mémoire virtuelle (le nombre de pages) est beaucoup plus grande que la mémoire physique
disponible (nombre de blocs), la probabilité d’apparition d’interruptions défaut de page augmente de
manière importante. En conséquence, le nombre de recopies en mémoire de masse des blocs libérés,
ainsi que le nombre de chargements de pages augmentent proportionnellement, ce qui a pour effet
d’augmenter fortement le temps de gestion de la mémoire. Cet état peut entraîner une situation
d’effondrement (thrashing) lorsque le temps de gestion devient supérieur au temps de traitement des
programmes en concurrence.
La notion d’espace de travail (working set) permet d’évaluer a priori le nombre de pages dont une tâche
doit disposer en mémoire pour d’éviter ces problèmes d’effondrement. Par définition, un espace de
travail correspond au plus petit ensemble de pages qui doit résider en mémoire principale pour assurer à
une application (ou programme) une certaine efficacité quant à son taux d’exécution. Si le nombre de
blocs disponibles est insuffisant pour charger l’espace de travail d’une tâche, cette dernière sera
temporairement suspendue.

1.5.5.5./ Segmentation paginée
Les mécanismes de segmentation et de pagination mettent en oeuvre des fonctions de gestion de la

mémoire virtuelle opérant suivant le même principe mais procédant de façon différente :
- Avec la segmentation le découpage du programme est logique et donc pas entièrement

transparent à l’utilisateur (aux méthodes et techniques qu’il utilise ainsi qu’à ses habitudes de
programmation), alors qu’avec la pagination ce découpage est physique et reste complètement
transparent,
- La dimension des segments est variable et elle est fortement liée à la nature des programmes et
des modules, alors que les pages et les blocs sont de taille fixe de dimension établie à partir de
contraintes matérielles.
L’association de ces deux techniques permet d’une part, de bénéficier du découpage logique des
applications afin de respecter les habitudes de programmation des utilisateurs et de mettre en oeuvre les
techniques de programmation structurée, et d’autre part, d’éviter le problème de la fragmentation de la
mémoire afin qu’elle soit utilisée au mieux. Avec un mécanisme de gestion de la mémoire virtuelle
segmentée et paginée, la mémoire physique est découpée en blocs, les programmes et les modules sont
découpés de manière logique en segments et chaque segment est lui-même découpé en pages. Le rôle
du gestionnaire de mémoire du système d’exploitation est de gérer ensuite les changements de pages
afin de diminuer le plus possible la fragmentation. Le mécanisme permettant la traduction d’adresses
logiques en adresses physiques dans une mémoire segmentée et paginée est basé sur l’utilisation
combinée de tables des segments auxquels sont associées des tables des pages.
1.5.5.5.1./ Association des tables des segments et des tables des pages
A chaque segment est associé un descripteur de segment ainsi qu’une table de descripteurs de page. Les
descripteurs de segment et les descripteurs de page contiennent le même type d’informations que celui
rencontré lors des techniques de segmentation seule (cf. §5.3.1. de ce chapitre) ou de pagination seule
(cf. §5.4.1 de ce chapitre). Ainsi, les descripteurs de segment contiennent des bits de contrôle (bits de
présence de segment, bits de protection...) et un champ Adresse contenant l’adresse de base de la table
des descripteurs de page (BTP) associée au segment ainsi que le nombre de pages composant le
segment. De même, les descripteurs de page contiennent des bits de contrôle (bits de présence, bits de
modification, bits d’autorisation...) ainsi qu’un champ Adresse contenant l’adresse physique du bloc qui
reçoit la page ou la localisation de celui-ci en mémoire de masse. L’ensemble des descripteurs de
segment est regroupé dans la table des descripteurs de segment qui est utilisée par les fonctions du
gestionnaire de mémoire lors d’une opération d’adressage.

1.5.5.5.2./ Adressage d’une mémoire segmentée et paginée
Le principe de l’adressage d’une mémoire segmentée et paginée (cf. figure 5.3) met en oeuvre la table
des descripteurs de segment, les tables de pages associées aux segments ainsi que le registre de base de
la table des descripteurs de segments (RTS).
Figure 5.8 : Adressage d’une mémoire segmentée paginée
Les adresses logiques sont composées de trois parties :
- Le Numéro du segment qui sert d’index dans la table des descripteurs de segment
- Le Numéro de la page qui sert d’index dans la table des descripteurs de page
- Le Déplacement qui donne la position effective du mot adressé dans le bloc

L’adresse dans la table des segments du descripteur du segment contenant le mot adressé est obtenue en
ajoutant au Numéro du segment contenu dans l’adresse logique, la valeur du registre de base RTS. Le
champ Base de ce descripteur contient l’adresse de la table des pages associée à ce segment (BTP). En
ajoutant à BTP, le Numéro de la page contenu dans l’adresse logique, le système accède alors au
descripteur de la page contenant le mot adressé. Il lui suffit alors d’ajouter à l’adresse de base du bloc
(@) trouvée dans ce descripteur la valeur du Déplacement pour accéder à l’adresse physique du mot
adressé.
Dans le cas où la page ne serait pas chargée en mémoire, une interruption « défaut de page » est
générée. La procédure de traitement d’un défaut de page et les algorithmes mis en oeuvre sont les
mêmes que ceux exposés précédemment (cf §5.4.3. de ce chapitre).
1.5.5.6./ Algorithmes de remplacement
Nous avons vu qu’un programme ne peut exécuter une instruction que si le segment ou la page qui la
contient est présente dans la mémoire physique. Pour cela le système peut mettre en oeuvre deux
politiques de chargement différentes
Le pré-chargement (prepaging) qui consiste à amener une page virtuelle en mémoire centrale
avant qu’il y soit fait référence. Il est évidemment très difficile d’anticiper le comportement des
programmes. Toutefois, lorsque l’exécution d’un programme provoque une interruption défaut de
page (ou défaut de segment), il est possible de charger, en plus de la page demandée, les quelques
pages qui lui sont contiguës, en espérant que les programmes aient un comportement
raisonnablement séquentiel.
Le chargement à la demande (demand paging) qui consiste à amener une page en mémoire
seulement à la demande du programme. Ce mode de chargement est le plus utilisé à l’heure
actuelle.
Plusieurs algorithmes de pagination ont été proposés pour répondre au problème du choix des pages qui
seront retirées de la mémoire et copiées sur disque pour faire de la place
1.5.5.6.1./ Algorithme aléatoire (random)
Le principe de cet algorithme consiste à choisir de façon aléatoire la page à expulser. En pratique, la
notion d’aléatoire le système ne va pas utiliser un générateur de nombres aléatoires pour choisir la page
à vider il s’agit en fait de ne pas appliquer de stratégie particulière. En général le système choisira de
vider les pages dans l’ordre, ce qui revient à vider la plus ancienne. Cet algorithme est très simple mais
peu efficace.

1.5.5.6.2./ Algorithme PEPS
Le principe de l’algorithme PEPS Premier Entré Premier Sorti (FIFO : First In, First Out) est basé sur
l’expulsion de la page qui fut la première à être chargée en mémoire. Il suffit pour cela d’une liste des
pages. Les pages sont ajoutées à la fin de cette liste et retirées à partir du début de la liste. Le vidage des
pages est réalisé alors de manière circulaire dans l’ordre de leurs adresses.
L’inconvénient majeur de cet algorithme est qu’il marche très mal lorsque le système devient
relativement chargé. En effet, la page la plus ancienne n’est pas nécessairement la moins utile. D’autre
part, si l’on peut considérer que les références à un programme sont à peu près séquentielles (le code est
exécuté «ligne par ligne »), il n’en est pas de même pour les références aux données. Bien qu’attirant
par sa simplicité, l’algorithme PEPS a de sérieuses limitations de performances, qui font qu’il est assez
peu utilisé dans sa forme pure.
1.5.5.6.3./ Algorithme MRU
L’algorithme MRU Moins Récemment Utilisé (LRU : Last Recently Used) est basé sur l’expulsion de la
page dont l’utilisation est la plus ancienne dans le temps. Cet algorithme suppose que si une page a été
maintes fois référencée, elle le sera probablement encore. Inversement, une page qui est ignorée est
candidate au remplacement. Cet algorithme utilise une table contenant une entrée pour chaque page
virtuelle du programme présente en mémoire. Cette entrée contient un bit de marquage et un compteur.
Chaque fois qu’une page est référencée, le système met à 1 le bit de marquage. A la fin de chaque
intervalle de temps, toutes les pages qui n’ont pas été utilisées durant cet intervalle (bit de marquage à
zéro) ont leur compteur augmenté d’une unité, alors que toutes les autres ont leur compteur remis à
zéro. Les bits de marquage de toutes les pages sont alors remis à zéro pour l’intervalle suivant. Pour
retirer une page, le système consulte alors cette table et retire la page dont le compteur est le plus élevé.
Cette méthode est connue pour bien fonctionner dans la plupart des cas. Pour cette raison elle est donc
souvent rencontrée, surtout dans l’une ou l’autre des approximations simplifiées présentées ci-dessus.
1.5.5.6.4./ Algorithme MFU
L’algorithme MFU Moins Fréquemment Utilisé (LFU : Last Frequently Used) expulse la page qui a été
la moins souvent utilisée pendant le dernier intervalle de temps. Sa mise en oeuvre nécessite, comme
pour l’algorithme MRU, un bit d’utilisation et un compteur pour chaque page. Le principe de
fonctionnement est alors le même mais dans ce cas le compteur mémorise le nombre d’intervalles de
temps durant lesquels il y a eu des références.
L'inconvénient de cette méthode est que la page la moins utilisée jusqu’à maintenant n’est pas forcément
celle qui le sera le moins dans un futur proche. Cet algorithme est par conséquent moins efficace et
moins utilisé que le MRU.

1.6. / LA GESTION DES ENTRÉES/SORTIES

Le processeur et la mémoire centrale constituent la partie principale d’un ordinateur, puisque le

traitement de l’information est effectué essentiellement entre ces deux unités. Toutefois, pour traiter les
applications des utilisateurs, le processeur doit être capable de recevoir de l’extérieur des programmes
et leurs données à travers des dispositifs d’entrées. Il doit aussi être capable de retourner aux utilisateurs
les résultats du traitement effectué à travers des dispositifs de sorties. De plus, nous avons vu que les
mécanismes de gestion de la mémoire virtuelle utilisent les mémoires de masse, externes au système,
afin d’étendre la capacité de la mémoire centrale. Il faut donc connecter au processeur et la mémoire
centrale, des mémoires de masse telles que des disques ou des unités à bandes. Un dispositif capable de
transférer de l’information depuis ou vers un support externe est appelé périphérique.
Pour tous les systèmes d’exploitation, la gestion de ces différents mécanismes d’entrée/sorties a
toujours été une tâche fondamentale. Cette tâche est d’autant plus fastidieuse dans les systèmes temps-
réel destinés au contrôle de processus ou à l’automatisation, que ces systèmes comportent en général un
très grand nombre de capteurs et d’actionneurs qui sont des périphériques analogiques et numériques
permettant le suivi et le pilotage du procédé. La grande différence de vitesse de fonctionnement entre
l’unité centrale (environ un million d’opérations àla seconde) et les périphériques (taux de transfert
beaucoup plus long) est à l’origine même des premiers systèmes d’exploitation. Dans les systèmes
modernes, l’ensemble des dispositifs d’entrées-sorties a pris une très grande importance et il n’est pas
rare que l’investissement en unités d’entrées-sorties Soit égal, voire parfois supérieur à celui de l’unité
centrale. La communication entre le système informatique et le monde extérieur ne se peut se faire qu’à
deux conditions :
· Qu’il existe une entité, appelée interface, capable de transformer la vision du monde extérieur
en informations utilisables par le système informatique,
· Qu’il existe au niveau du système informatique des instructions dites d’entrées-sorties,

permettant de récupérer les informations venant ou allant vers cette interface.
1.6.2. / ORGANISATION GENERALE DES ENTREES/SORTIES
Un organe d’entrées-sorties est donc un dispositif capable de transférer des informations entre le
processeur et un support d’information externe. Ce transfert est commandé par une procédure d’entrée-
sortie. Dans le cas le plus simple, cette procédure est réalisée par une instruction spéciale du processeur
qui permet de transférer l’information entre le support externe et le processeur qui est alors occupé
pendant toute la durée du transfert. Dans un souci de meilleure utilisation du processeur, l’autonomie
des organes d’entrées-sorties a été augmentée et des fonctions de plus en plus complexes
d’enchaînement et de commande leur ont été confiées. Dans ces conditions le processeur ne garde plus
que l’initiative du lancement et le contrôle des opérations ce qui le rend plus disponible. Un souci
d’économie conduit alors à séparer les organes périphériques proprement dits et leurs unités de
commande afin de pouvoir partager ces derniers entre plusieurs dispositifs d’entrées-sorties.

1.6.2.1./ Les périphériques d’entrées-sorties
Les périphériques d’entrées-sorties sont généralement catégorisés en deux groupes :
· Les périphériques « bloc » mémorisant les informations à transférer dans des blocs de taille fixe
disposant chacun d’une adresse propre. Ils permettent la lecture ou l’écriture d’un bloc
indépendamment de tous les autres (une tâche peut, à tout moment lire ou écrire n’importe
quel bloc). Les disques sont des périphériques « bloc ».
· Les périphériques « caractère » acceptant un flot de caractères sans se soucier de leur

organisation. Les informations ainsi transmises ne peuvent pas être adressées indépendamment
et aucune fonction de recherche n’est alors possible. La plupart des périphériques qui ne se
comportent pas comme des disques (terminaux, imprimantes, cartes perforées, interfaces de
réseaux, souris, traceurs...) peuvent être considérés comme des périphériques « caractère ».
1.6.2.2./ Les interfaces
Une interface est une carte électronique permettant de connecter un périphérique au système
informatique. Elle peut comprendre une zone de mémoire tampon et des bits de contrôle bit d’état
(prête ou occupée), bit de commande (lecture ou écriture). C’est en fait une boite noire qui transforme
les informations extérieures en signaux acceptés par le système informatique et inversement. Ces
signaux sont des suites de bits, symbolisés par des 0 ou des 1, généralement groupes par ensemble de 8
appelés caractère (ou octet). Ces bits sont représentés par deux signaux électriques (ou deux états de la
ligne de communication) normalisés, pour un même type d’ordinateur ou pour une famille d’ordinateurs
compatibles entres eux.
Il existe des équipements que l’on rencontre plus particulièrement dans les installations de contrôle de
processus, mettant en oeuvre des applications temps-réel et qui permettent d’acquérir des valeurs
analogiques. Avec ce type d’équipement, les interfaces doivent alors convertir des données analogiques
en données numériques ou des données numériques en données analogiques.
On distingue trois méthodes principales de commande des interfaces d’entrées-sorties l’utilisation

d’instructions spéciales, la cartographie mémoire et la programmation des entrées-sorties par
interruption.
1.6.2.2.1./ Les instructions spéciales
Cette méthode de programmation des interfaces n’est principalement utilisée que sur les micro-
ordinateurs. Avec cette technique, l’unité centrale génère un signal indiquant que le cycle qui débute
concerne une entrée-sortie. Ce signal est utilisé par un circuit spécial qui va aiguiller les données issues
de l’unité centrale vers une interface d’entrées-sorties plutôt que vers la mémoire.

1.6.2.2.2./ La cartographie mémoire
Avec cette méthode, également appelée méthode des entrées-sorties programmées avec attente de
disponibilité, l’interface possède des registres d’interface (device registers) situés à des adresses
consécutives un registre tampon et un registre de commande. La programmation (ou la commande)
d’une interface à partir de l’unité centrale se fait par l’écriture et la lecture de données à ces adresses.
L’unité centrale écrit les données à transférer (en sortie) ou lit les données transférées (en entrées) à
l’adresse indiquée dans le registre tampon et écrit les valeurs conventionnelles destinées à donner les
ordres à l’interface (par exemple exécuter une entrée ou exécuter une sortie) dans le registre de
commande. Après la lecture ou l’écriture de chaque information, l’unité centrale doit attendre que
l’interface soit de nouveau prête pour exécuter la lecture ou l’écriture d’une autre information. Ce qui a
pour inconvénient majeur d’occuper le processeur à un travail peu utile. Pour éviter cela la méthode la
plus couramment utilisée consiste à endormir la tâche effectuant une entrée ou une sortie et d’attendre
pour la reprendre que l’interface signale, en général par la génération d’une interruption, qu’elle est
prête.
1.6.2.2.3./ Les entrées-sorties contrôlées par interruptions
Une façon d’annuler l’attente de disponibilité consiste à faire en sorte que le processeur initialisant le
dispositif d’entrées-sorties, le configure pour qu’il transmette une interruption dès qu’il est prêt à
dialoguer. Ce mode de programmation des entrées-sorties est lié au mode de pilotage dit asynchrone
(cf. §3.3 de ce chapitre). Ainsi, en positionnant à 1 le bit d’autorisation d’interruption d’un registre du
dispositif d’entrées-sorties, le processeur sait qu’il sera interrompu lorsque le périphérique sera prêt
pour l’échange. La gestion d’interruption (cf. Chapitre 3) dans une machine est une tache délicate, qu’il
faut prendre en compte bien avant la programmation des entrées-sorties. Elle doit être menée avec
attention. En effet, s’il est nécessaire d’émettre une interruption à chaque caractère échangé, il y a une
forte perte d’efficacité du processeur, car l’exécution d’une interruption est néanmoins coûteuse en
temps de traitement.
Il existe d’autres modes d’échange qui permettent d’éviter une séquence répétée d’interruptions de
programme. Ces autres modes consistent à faire en sorte que le processeur n’est plus à se préoccuper de
la programmation des entrées-sorties pour la sous-traiter à un dispositif spécialisé du type contrôleur
d’entrées-sorties, contrôleur DMA ou encore canal, dont c’est le rôle essentiel.
1.6.2.3./ Les contrôleurs de périphériques
L’équipement périphérique a son propre rythme de travail différent de celui de l’unité centrale. Il est
donc nécessaire à l’interface d’établir un dialogue entre le système informatique et l’équipement
périphérique et de gérer le flux d’informations entre ces deux entités. Les constructeurs ont alors été
amenés à installer une logique de gestion câblée ou micro programmée selon les besoins de l’application.
Une telle interface, appelée contrôleur ou encore unité de commande (peripheral control unit) décharge
l’unité centrale d’une partie importante du travail de contrôle et d’exécution des entrées-sorties. Son
rôle consiste à piloter un périphérique et à gérer l’accès au bus pour permettre au système et au
périphérique de communiquer.

Par exemple, un contrôleur d’écran effectue une lecture en mémoire des octets contenant les caractères
à afficher et génère des signaux pour moduler le faisceau d’électrons qui dessine les caractères à l’écran
ou pour repositionner ce faisceau au début de la ligne suivante à la fin de chaque ligne ou bien en haut
de l’écran lorsque tout l’écran a été rempli. Sans lui, le programmeur d’un système d’exploitation aurait
à programmer directement le balayage du tube cathodique, alors qu’il suffit au système d’exploitation
d’initialiser le contrôleur avec quelques paramètres (nombre de caractères par ligne, nombre de lignes à
l’écran...) pour qu’il se charge de diriger le faisceau.
Chaque contrôleur est très lié au type d’équipement qu’il contrôle (une carte contrôleur possède en
général un connecteur qui permet de la relier aux périphériques). On trouve ainsi des contrôleurs de
bandes magnétiques (tape controller), de disques (disk controller), d’écran (displav controller),
d’imprimante (printer controller), de télécommunications (communication control unit)...
Un ensemble contrôleur/périphérique est défini par une interface, souvent de très bas niveau, qui
comprend des fonctions d’entrées-sorties et une voie de communication servant au transfert de
l’information. L’autonomie d’un contrôleur est limitée à quelques opérations élémentaires enchaînement
et synchronisation des opérations, envoi des signaux de fin de transfert ou d’incident...
Figure 6.1 : Organisation des entrées-sorties mettant en oeuvre des contrôleurs
Ce type d’organisation (cf. figure 6.1) se rencontre fréquemment sur des systèmes informatiques de type
mini-ordinateur ou micro-ordinateur. Le principal intérêt de séparer contrôleur et périphérique est de
pouvoir connecter ainsi plusieurs périphériques de même type à un contrôleur unique (de nombreux
contrôleurs acceptent deux, quatre et même huit périphériques identiques). Dans ce cas, un seul
périphérique à la fois peut transférer de l’information. Il est toutefois possible d’exécuter simultanément
sur les autres périphériques des opérations qui n’impliquent pas de transfert d’information déplacement
du bras d’un disque. rembobinage d’une bande magnétique...

1.6.2.3.1./ L’accès direct à la mémoire
Certains contrôleurs (en particulier ceux des périphériques « bloc ») permettent de transférer une
information directement de la mémoire à un périphérique ou inversement, sans que celle-ci transite par
le processeur. Ces contrôleurs particuliers qui effectuent des opérations d’accès direct à la mémoire sont
plus connus sous l’acronyme DMA (Direct Memory Access). Ils possèdent une électronique élaborée
qui leur permet de générer successivement toutes les adresses concernées par le transfert, de lire le
contenu de chacune d’elle et d’écrire ce contenu sur le périphérique concerné, ou inversement. Le bus
sert aussi bien aux contrôleurs qu’au processeur lorsqu’ils dialoguent avec la mémoire.
Sachant qu’une seule communication peut être engagée sur un bus, que se passe-t-il lorsque le
processeur et un contrôleur veulent utiliser le bus simultanément ? Un dispositif particulier, appelé
arbitre de bus, analyse les demandes de bus et décide qui en sera l’allocataire. En général, en cas de
conflit avec le processeur. la préférence est donnée au contrôleur d’entrées-sorties. En effet, un
équipement de type disque (ou du même genre) ne peut s’arrêter lorsqu’il est lancé à pleine vitesse
(obliger un disque à attendre le bus entraîne alors une perte d’informations). Lorsque aucune opération
d’entrée-sortie n’est engagée, le processeur utilise le bus quand il le souhaite. En revanche, dès qu’une
opération d’entrée-sortie est en cours, le contrôleur transmet une requête de bus à l’arbitre et obtient le
bus en cas de conflit :
· Soit en priorité lorsque le transfert d’informations est considéré comme prioritaire. Dans ce cas
le processeur est bloqué pendant toute la durée du transfert. Cette technique est dite de mise
en veille du processeur.
· Soit de façon alternée avec le processeur ce qui a pour effet de ralentir faiblement le processeur
dans l’exécution de sa tâche en cours. Cette technique est appelée vol de cycle (cycle stealing
),
· Soit de manière transparente au processeur, en autorisant les accès aux bus uniquement lorsque
le processeur n’y accède pas. Dans ce cas la priorité est donnée au traitement des informations
et non aux transferts. Cette technique est dite du DMA multiplexé.
Les ordinateurs de grande puissance (ordinateurs universels ou mainframes) disposent de nombreux bus
pour tenter de minimiser le nombre de vol de cycles afin d’éviter une baisse de performance de l’unité
centrale, mais ce n’est pas toujours suffisant. De plus, il peut se produire un problème de partage de
ressources lorsque l’unité centrale et un contrôleur DMA qui peuvent agir en parallèle, décident
d’adresser simultanément (en lecture ou en écriture) la même cellule mémoire. Une solution à ce
problème est d’interdire par exclusion mutuelle les accès simultanés à une même cellule mémoire. Dans
la pratique, cette exclusion mutuelle ne se fait pas par logiciel, ce qui serait trop coûteux en temps
d’exécution, mais physiquement à l’aide d’une bascule qui interdit au processeur d’accéder à une cellule
pendant l’accès direct.

1.6.2.3.2./ Programmation d’un contrôleur
Chaque contrôleur communique avec le processeur par l’intermédiaire de quelques registres. Le

système d’exploitation effectue des entrées-sorties en écrivant les commandes et leurs paramètres dans
les registres du contrôleur. Dès qu’une commande est acceptée le processeur peut alors effectuer un
autre travail le contrôleur s’acquittant seul de la commande. Lorsque la commande est réalisée, le
contrôleur envoie une interruption au processeur pour lui signaler la fin de l’opération. Le processeur
peut alors récupérer des résultats et obtenir l’état du périphérique en lisant les registres du contrôleur.
Figure 6.2 : Organisation des entrées-sorties mettant en oeuvre un accès direct à la mémoire
L’initialisation des registres d’un contrôleur est réalisée soit au coup par coup avec les paramètres
d’appel de l’instruction d’entrée-sortie exécutée par l’unité centrale, soit lors de la configuration du
système ce qui permet de diminuer les temps de transfert. Ainsi, pour effectuer un transfert de données
par DMA, une seule instruction est nécessaire. Elle est exécutée par l’unité centrale avec comme
paramètres l’adresse en mémoire centrale du début de la zone à transférer et sa taille. Le transfert est
réalisé alors sans le concours de l’unité centrale, cellule mémoire par cellule mémoire, jusqu’à ce que la
taille de la zone soit atteinte. La programmation d’un contrôleur DMA se fait, comme pour une
interface, par l’écriture de données dans au moins trois registres (cf. figure 6.2) :
· Un registre Adresse qui est un pointeur contenant l’adresse du mot mémoire à transférer et
initialisé avec l’adresse du début de la zone de mémoire à transférer,
· Un registre Longueur qui est un compteur contenant le nombre de données restant a transférer
et initialisé avec la longueur de la zone mémoire à transférer,
· Un registre Commande qui est un mot d’état contenant la commande issue de l’unité centrale
et qui spécifie l’opération souhaitée (sens du transfert (précisant si les données doivent être
lues à l’extérieur ou écrites vers l’extérieur), désignation du périphérique concerné...).

Pour réaliser une opération d’écriture (de sortie) d’un bloc de données situé en mémoire vers un
périphérique donné, le processeur initialise ces registres avec les paramètres de l’instruction de sortie
exécutée. Une fois ces registres initialisés, le processeur peut alors reprendre son fonctionnement
normal.
Le contrôleur effectue alors une requête de bus pour réaliser la lecture du mot mémoire situé à l’adresse
fournie par le registre Adresse. Le mot reçu est ensuite transmis à l’interface ou au contrôleur du
périphérique concerné par l’échange. Le contrôleur DMA incrémente alors d’une unité le registre
Adresse et décrémente d’une unité le registre Longueur. Ce processus se poursuit tant que le registre
Longueur n’est pas égal à zéro. Dés que le compteur de mot est à zéro, le contrôleur DMA a terminé
l’échange et transmet une interruption au processeur pour le lui signaler.
1.6.2.4./ Les canaux d’entrées-sorties
Dans le cas des ordinateurs de grande puissance (souvent appelés mainframe), les échanges avec des
périphériques rapides, tels que les disques, sont si nombreux que la technique de vol de cycle conduirait
à une saturation du bus. A tel point que sur ce type de machine les constructeurs ont préféré aux circuits
DMA traditionnels, de véritables processeurs d’entrées-sorties appelés canaux d’entrées-sorties
Figure 6.3 : Organisation des entrées-sorties d’un ordinateur de grande puissance
Un canal (channel) d’entrées-sorties est un processeur spécialisé dans les opérations d’entrées-sorties
fonctionnant comme un dispositif DMA partagé entre plusieurs interfaces. Il peut donc commander un
périphérique unique de débit élevé (tel qu’un disque) ou être multiplexé entre plusieurs périphériques de
débit plus faible.

Il ne peut être lancé que par un processeur central et possède un répertoire restreint d'instructions qui
lui permet d’actionner les contrôleurs et les périphériques qui lui sont connectés. Lorsque le processeur
doit effectuer une opération d’entrée-sortie, il la sous-traite au canal associé au périphérique. Il lui
transmet alors les informations nécessaires à la réalisation de l’opération et lui demande de l’exécuter.
Ces informations sont préparées sous la forme d’un programme, appelé programme canal, et dépendant
de l’opération d’entrée-sortie souhaitée. Un tel programme est de complexité bien plus élevée qu’un
simple échange en mode DMA. Les canaux sont souvent capables d’enchaîner une série de transferts, et
même d’aller plus loin en optimisant, par exemple, les mouvements de têtes de lecture/écriture des
disques. Le canal traite alors complètement ce programme qui lui est soumis de manière autonome, sans
aucune relation avec le processeur central. Une fois le programme de transfert terminé le canal envoie
éventuellement une interruption au processeur central qui a pour effet d’arrêter le traitement courant du
processeur pour l’inciter à lui prêter attention.
Ce mode de travail décharge le processeur des opérations d’entrées-sorties qui sont souvent mal
adaptées à sa vitesse de traitement (il y a effectivement toujours une lenteur relative de réaction du
périphérique vis-à-vis du processeur). En outre, ce mode de fonctionnement offre l’avantage d’une
simultanéité de traitement du processeur et des canaux, conduisant à une amélioration sensible des
performances du système.
La mise en place d’un tel dispositif sur les ordinateurs de grande puissance nécessite une architecture
matérielle (cf. figure 6.3) s’appuyant au moins sur trois bus afin d’optimiser leurs performances :
- Le bus «mémoire » permet aux canaux de lire et d’écrire directement des données en mémoire,
- Le bus « d’entrées-sorties » assure au processeur la faculté de communiquer aisément avec les

canaux d’entrées-sorties (transmission de commandes, transmission d’interruptions...),
- Un troisième bus permet enfin au processeur d’échanger des informations (programmes et

données) avec la mémoire.
Selon leur structure et leur complexité, on peut distinguer trois types de canaux.
1.6.2.4.1./ Le sélecteur
Un sélecteur (selector) est un canal spécialisé, dédié aux périphériques rapides à haut débit (disques,
bandes...). Il sélectionne un seul périphérique à la fois (cf. figure 6.4). Quand une opération est
commencée, elle continue jusqu’à sa fin. Pendant tout le temps d’exécution, le canal est dit occupé
(busy).
La sélection du périphérique est effectuée à l’aide d’un registre contenant l’adresse du périphérique
concerné. Deux autres registres de commande contenant respectivement la longueur et l’adresse de la
zone mémoire indiquent au module de contrôle du canal la zone de mémoire contenant les données à
transférer.

Figure 6.4 : Structure d’un canal sélecteur
1.6.2.4.2./ Le multiplexeur par octet
Dans ce type de canal, les circuits sont partagés entre plusieurs sous-canaux (cf. figure 6.5). Ainsi,
plusieurs périphériques à faible vitesse de transfert (tels que les terminaux) peuvent être alors contrôlés
simultanément. Chaque sous-canal possède sa propre paire de registres de commande (Adresse et
Longueur) leur indiquant la zone de mémoire contenant les données à transférer.
Figure 6.5 : Structure d'un canal multiplexeur par octet

Si. par exemple, le canal reçoit trois ordres d’entrées-sorties simultanément : écrire A0. A1. A2 sur le
périphérique A. B0, B1 et B2 sur le périphérique B et C0, Cl, C2 sur le périphérique C. Il pourra
exécuter ses ordres dans l’ordre : A0, B0, C0, A1, Bl, Cl,... ou alors si C’est un périphérique beaucoup
plus lent que A et B, il pourra entrelacer l’exécution : A0. B0, C0, puis A1, B1, A2, B2, Cl, C2.
1.6.2.4.3./ Le multiplexeur par bloc
Un canal multiplexeur par bloc est une combinaison d’un sélecteur et d’un multiplexeur par octet.
Lorsqu’un périphérique est autorisé à prendre le canal pour lui seul pendant une courte période, on dit
que celui-ci peut fonctionner en mode rafale (burst mode). Lorsqu’il travaille en rafale, il est équivalent
à un sélecteur. Lorsqu’il travaille en mode multiplexeur, les octets sont remplacés par des blocs d’octets.
1.6.2.4.4./ Programmation d’un canal
Pour réaliser un transfert de données sur un ordinateur doté de canaux d’entrées-sorties, le processeur
commence par créer en mémoire principale un programme, appelé programme canal, dans le langage du
canal qui effectuera le transfert. Bien entendu, il ne s’agit pas pour le processeur d’écrire un programme
dans le sens classique du terme, mais de prendre, dans une bibliothèque de programmes, la maquette du
programme correspondant au transfert demandé et d’y insérer les paramètres appropriés, tels que :
· L’opération demandée (lecture, écriture, positionnement...),
· L’adresse du début de la zone mémoire où se trouvent les données à transférer,
· La longueur de cette zone,
· L’identification du périphérique concerné par l’échange,
· Les numéros de piste et de secteur lorsqu’il s’agît d’un disque...
Après avoir préparé le programme canal, le processeur exécute une instruction d’initialisation de
l’échange (du type START I/O sur les ordinateurs IBM) pour définir et initialiser le canal et le
périphérique concernés. Le canal peut alors mener à bien le transfert sans l’aide du processeur qui peut
reprendre alors son fonctionnement normal en parallèle avec le canal. Ce dernier extrait d’un
emplacement mémoire connu à l’avance l’adresse du programme canal qu’il doit exécuter. Il range cette
adresse dans son propre compteur ordinal, puis exécute en séquence les instructions du programme
canal. Comme les canaux travaillent en parallèle avec le processeur central, il y a concurrence entre eux
pour accéder à la mémoire centrale. En effet, les canaux doivent lire et écrire dans la même mémoire
que celle utilisée par l’unité centrale pour l’exécution des tâches en cours. Les canaux doivent alors, de
la même manière qu’un contrôleur de type DMA, dérober des cycles d’accès à la mémoire au
processeur central.

1.6.3. / PILOTAGE DES PERIPHERIQUES
Le programme qui commande le fonctionnement élémentaire d’un périphérique est appelé conducteur
de périphérique (device driver). Ce programme gère directement l’interface du contrôleur du
périphérique, traite les interruptions émises par celui-ci, détecte et traite les cas d’erreurs. Il est
généralement transparent aux utilisateurs qui accèdent aux fonctions d’entrée/sorties au moyen de
services de plus ou moins haut niveau, réalisés par des appels au superviseur.
1.6.3.1./ Notion de conducteur de périphérique
Pour pouvoir écrire des programmes qui peuvent fonctionner sur n’importe quelle machine, sans
recourir à des modifications, il est nécessaire de parvenir à un maximum d’indépendance entre le logiciel
et le matériel. Pour exécuter une entrée-sortie sur un périphérique, le gestionnaire d’entrées-sorties du
système a besoin de connaître son « adresse» dans la machine. Ainsi, les programmes exécutent leurs
entrées-sorties en indiquant simplement au système un « nom logique » pour désigner le périphérique
concerné par l’échange. Le système maintient une table interne de correspondance entre les noms
logiques et les adresses physiques des périphériques. Le gestionnaire d’entrées-sorties dirige ensuite
chaque requête vers un programme spécial, appelé conducteur de périphériques (ou conducteur
d’interfaces ou encore pilote de périphériques) (device driver), qui est le seul dans le système à
connaître l’emplacement physique (l’adresse réelle) du périphérique dans la machine. En outre, seul le
conducteur connaît les particularités du périphérique qu’il contrôle, telles que les adresses des différents
registres de commandes ou les bits à positionner pour effectuer chaque opération.
Un conducteur de périphériques est constitué de quelques routines qui s’appellent les unes les autres.
L’écriture de ces routines est soumise à des contraintes fortes de réentrance. En effet, lorsqu’un
conducteur est chargé de contrôler plusieurs entrées-sorties simultanément, il doit pouvoir être
interrompu par une interruption qui provoquera sa propre exécution. Il doit donc être capable de
s’exécuter en parallèle avec lui-même et donc être entièrement ré-entrant. Parmi les routines
constitutives, on trouve presque toujours celles présentées par la figure 6.6
1. Une routine de pré-traitement qui vérifie que l’opération demandée est possible (par exemple
qu’on ne demande pas une lecture sur une imprimante). Si la demande est correcte, cette
routine appelle la routine de lancement,
2. Une routine de lancement qui est chargée d’initialiser l’interface et de commander le transfert
de la première donnée. Après l’exécution de cette commande, cette routine effectue un
branchement sur la routine d’attente,
3. Une routine d’attente des entrées-sorties qui sauvegarde l’adresse de la routine de continuation
dans le paquet associé à l’entrée-sortie en cours, puis rend la main au système,
4. Le système d’interruption du matériel,

5. Une routine de traitement d’interruption qui est exécutée par le système lorsque le périphérique
contrôlé par le conducteur envoie une interruption. Elle appelle une routine de mise en file qui
enregistre l’interruption pour différer son traitement complet et rend la main au système afin de
ne pas bloquer les autres interruptions qui pourraient survenir,
6. Lorsque le système n‘a plus de routines d’interruption à exécuter, l’interruption logicielle

provoquée par une des routines d’interruption d’un contrôleur d’interfaces va provoquer
l’exécution d’une routine d’exploration de la file des entrées-sorties en attente de
continuation. Pour chacune d’elle, cette routine va appeler la routine de continuation
conducteur correspondant,
7. Une routine de continuation de l’entrée-sortie en cours qui est appelée par la routine de sortie
de file pour poursuivre l’entrée-sortie. Si l’entrée-sortie est terminée, elle appelle une routine
de post-traitement du système. Sinon, elle lance le transfert de la donnée suivante et se branche
sur la routine d’attente,
Figure 6.6 : Schéma d’un conducteur de périphériques

8. Une routine de post-traitement de l’entrée-sortie qui est appelée à sa fin et qui va mettre le
paquet de l’entrée-sortie dans la file de post-traitement et déclencher un événement post-
traitement. Ainsi, le traitement correspondant sera remis à plus tard lorsque toutes les
entrées/sorties en attente auront été relancées.
L’enchaînement des appels aux routines pour une entrée-sortie est donc le suivant :
Démarrage de l’entrée-sortie
Continuation
…
Fin de l’entrée-sortie
La séquence (3) (4) (5) (6) (7) est exécutée pour chaque interruption. Par exemple, dans le cas d’une
écriture sur un périphérique asynchrone, elle sera exécutée une fois pour chaque caractère écrit.
1.6.3.2./ Pilotage d 'entrées-sorties synchrones
Lorsqu’un programme fait une demande d’entrée-sortie, celle-ci est, en général, exécutée en mode
synchrone, c’est à dire que le système ne rend la main à la tâche qui a demandé l’opération d’entrée-
sortie qu’une fois celle-ci terminée. En mode synchrone, il n’y a donc aucun parallélisme possible entre
le traitement d’une tâche et le transfert d’informations. Pendant toute la durée de l’opération d’entrée-
sortie, la tâche en cours qui a généré la demande est bloquée dans un état en attente, la main passant
alors à un autre programme (cf. figure 6.7). L’opération de base est le transfert d’une information
élémentaire entre un emplacement mémoire et un périphérique. La taille de cette information est fixe et
dépend du périphérique considéré (nous la supposerons égale à un octet). L’état de l’ensemble
contrôleur/périphérique est défini par un mot d’état contenu dans le contrôleur. Ce mot d’état comporte
un ensemble d’indicateurs booléens parmi lesquels on trouve en général :
· Prêt: signale que le périphérique est prêt à fonctionner (le détail des conditions à remplir
dépend du périphérique),
· Fini: indique que le transfert est terminé. Le périphérique est alors prêt à transférer un nouveau
caractère,
· Erreur: signale qu’une erreur s’est produite au cours du transfert. Sa nature est précisée par
un code qui fait partie du mot d’état.
Figure 6.7 : Entrée-Sortie synchrone

Le contrôleur est commandé par le processeur au moyen de trois instructions :
· ENTRER (@mem, @périph) demande le transfert d’un caractère en entrée,
· SORTIR (@mem, @périph) demande le transfert d’un caractère en sortie,
· TEST (@périph) copie le mot d’état dans un registre pour consulter les indicateurs.
On a @mem et @périph qui désignent respectivement les adresses de l’emplacement mémoire et du

périphérique.
Figure 6.8 : Exemple de pilote d’entrées-sorties synchrones
La figure 6.8 est un exemple de programme pilote d’entrées-sorties en mode synchrone et permettant de
sortir une suite de n caractères contenus dans un tableau T[0..n-1]. La tâche « Active » qui a la main
exécute une instruction d’affichage qui déclenche alors un appel au superviseur. Cet appel va réaliser le
blocage de la tâche " Active " (mise en attente de "Active" ) et le lancement de la tâche « pilotage
synchrone » qui, elle, va réaliser le transfert effectif en sortie du tableau T[0...n-1]. Le transfert du
caractère T[i] ne pouvant être effectif qu’à la fin du transfert du caractère T[i-1], un test est itéré sur
l’indicateur Fini (attente active) avant le transfert de chaque caractère. Une fois le transfert des n
caractères terminé, la tâche « Pilotage synchrone » débloque la tâche « Active» qui pourra alors
reprendre son exécution quand son tour viendra.
Les entrées-sorties synchrones sont très utilisées sur les micro-ordinateurs les plus simples et dans tous
les cas où le processeur ne peut être utilement employé pendant le transfert (enregistrement de mesures,
chargement initial d’un système...).

1.6.3.3./ Pilotage d’entrées-sorties asynchrones
Il est toujours possible pour une tâche de demander au système d’exécuter des entrées-sorties de façon
asynchrone. Dans ce cas, le système lance l’opération d’entrée-sortie et redonne tout de suite la main à
la tâche. Celle-ci peut alors reprendre son déroulement en parallèle avec le déroulement de l’entrée-
sortie. Le système la prévient de la fin de l’opération d’entrée-sortie, soit par le positionnement d’un
drapeau (flag) que la tâche ira tester, soit par l’exécution d’une routine particulière, dont la tâche a
fourni l’adresse au système lors du lancement de l’opération d’entrée/sortie (cf. figure 6.9). L’intérêt de
cette routine est qu’elle est décrite par le concepteur du programme. En contre partie l’écriture du
programme doit tenir compte du caractère asynchrone de cette routine (il n’est pas possible de savoir à
l’avance à quel moment il sera interrompu, lors de son exécution, par la fin de l’opération d’entrée-
sortie). La figure 6.10 est un exemple de pilotage d’entrées-sorties en mode asynchrone permettant à
une tâche de sortir une suite de n caractères contenus dans un tableau T[0...n-1] et de poursuivre en
parallèle son déroulement.
Figure 6.9 : Entrées-Sorties asynchrones
Dans cet exemple, le transfert est demandé par la tâche active qui exécute une instruction de sortie.
Cette instruction fait appel au superviseur en lui passant comme paramètres :
· L’adresse du périphérique concerné par le transfert,
· L’adresse d’origine du premier caractère à transférer,
· Le nombre total de caractères à transférer,
· Un indicateur booléen «Terminé », dont la mise à vrai signale la fin du transfert.
L’appel au superviseur a pour objet d’initialiser l’opération d’entrée-sortie et d’amorcer le processus

par le transfert du premier caractère (SORTIR (T[0], @périph)). La fin du transfert de chaque caractère
T[i] est signalée par une interruption. Le traitement de cette interruption consiste à lancer le transfert du
caractère suivant (SORTIR (T[i], @périph)), tant qu’il reste des caractères à transférer (i < n-1).

Figure 6.10 : Exemple de pilote d’entrées-sorties asynchrones
Dès que l’opération est amorcée, la tâche « Active » reprend son traitement en parallèle avec
l’opération de Sortie et peut tester la fin de transfert afin de lancer alors une procédure adéquate ou
demander un autre transfert de données en entrée comme en sortie. Le traitement parallèle de tâche «
Active » et de la tâche de traitement des interruptions n’est en fait qu’un enchevêtrement de l’exécution
de ces deux tâches (cf. Figure 6.11). La tache «Active» prend la main dès qu’un transfert est lancé. A
chaque interruption provenant du périphérique et signalant la fin du transfert commandé, le système
reprend la main pour traiter l’interruption et continuer l’opération d’entrée ou de sortie en commandant
un nouveau transfert. En fait, la tâche « Active » s’exécute pendant les temps d’attente des interruptions
(correspondant à près de 90% du temps total de l’entrée-sortie).
Instructions de requêtes aux périphériques.
Exécution des requêtes pour

le périphérique en parallèle.
Figure 6. 11 : « Parallélisme » entre tâche et entrée-sortie

La mise en oeuvre du mécanisme de pilotage d’entrées-sorties asynchrones est une extension du

mécanisme de pilotage d’entrées-sorties synchrones le passage à vrai de l’indicateur Fini provoque une
interruption sur le niveau associé au périphérique considéré. Le choix entre le mode synchrone et le
mode asynchrone (donc par interruption) est commandé par l’armement ou le désarmement de ce
niveau.
1.6.4. / PRINCIPE DU GESTIONNAIRE D’ENTREES/SORTIES
Le module de gestion des entrées-sorties d’un système d’exploitation a pour rôle de prendre en charge
les transferts de données entre la mémoire centrale et les périphériques, et d’isoler l’utilisateur des
spécificités du matériel. Les gestionnaires d’entrées-sorties (IOM : Input-Output Manager) permettent
ainsi aux utilisateurs de voir les mécanismes d’entrées/sorties de manière virtuelle (cf. figure 6. 12).
Les tâches d’application peuvent alors communiquer de manière standard avec des entrées/sorties
logiques. Ce principe de terminal virtuel permet d’éviter qu’un programme qui effectue une opération
d’entrées/sorties (beaucoup plus lente qu’une opération de l’unité centrale) ne monopolise le processeur
pendant tout un temps inutilement long, d’assurer le partage des unités périphériques entre les différents
utilisateurs et leurs applications, d’éviter des erreurs et enfin d’utiliser les unités avec toute l’efficacité
voulue. Du côté matériel, les gestionnaires d’entrées/sorties doivent se connecter aux gestionnaires des
unités périphériques (device management ou device driver) qui s’occupent des transferts des données
physiques sur les divers périphériques consoles, imprimantes, disques, bandes... Ces derniers sont très
spécialisés et liés du matériel.
Figure 6. 12 : Principe de la gestion des entrées/sorties
Le problème dû à la différence de vitesse de travail entre l’unité centrale et les unités périphériques est
en général résolu à l’aide d’un gestionnaire de tampons. Le gestionnaire d’entrées/sorties d’un système
d’exploitation sert donc d’interface entre la vision logique qu’a un utilisateur des Unités périphériques
(nom, type...) et la vision physique qu’a le système de ces unités (adresses réelles, vitesse de
transfert...), à travers un ensemble de services auxquels l’utilisateur peut accéder.

1.6.4.1./ Structure du gestionnaire d’entrées/sorties
Nous avons vu (cf. figure 6.12) qu’une manière de standardiser l’interface entre les tâches d’application
et les gestionnaires d’entrées/sorties est de considérer ces derniers comme des fichiers spéciaux
(input/output files) dans lesquels les tâches lisent et écrivent.
Figure 6. 13 Structure d’un Gestionnaire d’entrées/sorties.
La conception de tels gestionnaires est ainsi liée au niveau supérieur du système d’exploitation
concernant la gestion des fichiers. Lorsqu’un utilisateur a ouvert un fichier ou déclaré qu’il voulait
utiliser une unité d’entrées-sorties (ouverture d’un fichier spécial, du type fichier INPUT ou fichier
OUTPUT), c’est ensuite le gestionnaire d’entrées-sorties qui contrôle et gère toutes les demandes
d’opérations (tant en lecture qu’en écriture) sur ce fichier.
Un gestionnaire d’entrées/sorties est constitué de deux niveaux (cf. figure 6.13) : l’un prend en charge
la manipulation des données logiques et l’autre s’occupe du traitement des données physiques. Entre ces
deux niveaux, une interface transforme les données logiques en données physiques et inversement. Les
données, dites données logiques, proviennent des tâches utilisateur. Quant aux données physiques, elles
sont produites directement par le niveau physique du gestionnaire vers les dispositifs d’entrées/sorties.
1.6.4.2./ Le LIOCS
Le LIOCS (Logical Input-Output Control System) permet de considérer que les données à transférer
sont présentées sous la forme d’enregistrements logiques (records) stockés dans des fichiers. Ce niveau
du gestionnaire d’entrées/sorties gère les accès à ces fichiers du côté des utilisateurs en utilisant des
tampons (buffers) pour optimiser l’utilisation du processeur, c’est à dire faire en sorte que les tâches
soient le moins souvent possible mises en attente lorsqu’elles effectuent des demandes d’entrées/sorties.
Il comprend un module de contrôle de la stratégie d’utilisation des unités physiques qui permet, par
exemple, de grouper des demandes multiples à une même unité périphérique.

1.6.4.3./ Le PIOCS
Le PIOCS (Physical Input-Output Control System) travaille sur des adresses réelles. Les données
physiques qu’il contrôle, sont envoyées en direction des unités d’entrées/sorties et permettent leur
commande effective en tenant de leurs caractéristiques physiques (adresses réelles, vitesse de travail...).
Pour cela, il comprend un module de contrôle des entrées/sorties (device handier) en relation directe
avec le gestionnaire de périphériques (device driver) et le gestionnaire d’interruption (interrupt
manager) du système.
1.6.4.4./ Le gestionnaire de tampons
La fonction des mémoires tampon (buffer) est double :
- Servir d’adaptateur entre l’unité centrale et les unités périphériques qui travaillent à des vitesses
différentes et ainsi optimiser les temps de transfert,
- Résoudre les problèmes d’adaptation des données logiques au support matériel, liés aux
différences de taille et de structure entre les enregistrements logiques (visibles aux utilisateurs)
et les enregistrements physiques (visibles aux unités d’entrées-sorties).
Lorsqu’une unité d’entrées/sorties est allouée à une tâche, un ensemble de tampons lui est associé.
L’utilisation de ces tampons est dynamique. Il existe trois méthodes principales pour la gestion de ces
tampons
1.6.4.4.1./ Le double tampon
Le mécanisme de gestion d’un double tampon est le mécanisme le plus simple. Un groupe de deux
tampons est associé à l’unité d’entrées/sorties. Pendant qu’une tâche utilisateur travaille avec un des
deux tampons par l’intermédiaire du LIOCS, l’unité d’entrées/sorties travaille avec l’autre par
l’intermédiaire du PIOCS (cf. figure 6.14).
Figure 6. 14 : Principe d’utilisation d’un mécanisme double tampon

Quand l’un des tampons est vide et l’autre rempli, ils sont alors échangés. L’inconvénient de ce
mécanisme réside dans le fait que si la tâche utilisateur (niveau logique) est très rapide par rapport à
l’unité périphérique, elle sera souvent bloquée en attente de la disponibilité du deuxième tampon.
1.6.4.4.2./ Le tampon circulaire
Un tampon circulaire correspond à une zone mémoire égale à un multiple de la dimension d’un
enregistrement physique. On accède à cette zone par l’intermédiaire de deux pointeurs début et Fin. A
l’état initial ces deux pointeurs pointent sur la même adresse.
Le PIOCS écrit des enregistrements physiques à partir de l’adresse pointée par Fin et repositionne ce
pointeur à la fin du dernier enregistrement physique écrit. Le LIOCS quant à lui lit les enregistrements
logiques à partir de l’adresse pointée par Début. Après chaque lecture. Début est repositionné au début
du premier enregistrement logique à lire. Entre Début et Fin, on trouve donc les informations produites
par le PIOCS et non encore utilisées par le LIOCS. Alors que de Fin vers Début on trouve l’espace
disponible dans lequel le PIOCS peut écrire. D’une certaine manière le LIOCS voit des tampons dont la
dimension est celle d’un enregistrement logique (une ligne par exemple) alors que le PIOCS voit des
tampons dont la taille correspond à celle des enregistrements physiques (blocs de 128 octets, par
exemple).
Figure 6.15 : Principe d’un tampon circulaire
Dans l’exemple de la figure 6.15-a, la zone occupée, c’est-à-dire celle contenant des informations
produites par le PIOCS mais pas encore consommée, est contiguë, alors que dans la figure 6.15-b, bien
que du point de vue logique rien ne change, l’adresse physique de Fin précède celle de Début.

1.6.4.4.3./ Le pool de tampons
Lors de l’allocation d’une unité d’entrées/sorties à une tâche, un ensemble de tampons est réservé dans
l’espace libre de la mémoire. Chaque tampon a une dimension qui correspond à la taille d’un
enregistrement physique. A chacun de ces tampons est associé un descripteur de tampon (buffer control
block). Ces descripteurs sont chaînés entre eux et contiennent en général les éléments suivants :
· La dimension logique du tampon qui peut être différente de sa dimension physique qui est en
général un multiple de la taille d’un bloc mémoire,
· Un index qui donne la page mémoire réelle contenant le tampon,
· Le statut du tampon qui indique si le tampon est plein, donc disponible pour être lu, ou vide et
alors disponible pour être écrit,
· Un pointeur vers le descripteur suivant qui assure le chaînage des tampons.
La gestion de ces tampons peut alors être réalisée à l’aide de deux boîtes aux lettres (cf. figure 6.16) qui
sont créées lors de l’affectation d’une unité d’entrées/sorties à une tâche :
· BLP servant aux échanges du niveau logique vers le niveau physique,
· BPL servant aux échanges du niveau physique au niveau logique.
Dans le cas dune opération de lecture, les descripteurs de tampons sont alors tous chaînés à l’origine
dans la boîte BLP. Celle-ci constitue alors la liste des tampons disponibles pour la tâche du PIOCS
chargée de leur recopie. Cette tâche remplit tous les tampons trouvés dans BLP, les uns après les
autres, et les envoie dans BPL. Lorsque BLP est vide la tâche du PIOCS est alors mise en attente. La
boîte BPL constitue alors la liste des tampons disponibles pour la tâche du LIOCS chargée de les vider.
Cette tâche prend les tampons de BPL dans leur ordre d’arrivée et y lit, sous la forme d’enregistrements
logiques, les informations qui y ont été rangées. Lorsque toutes les informations contenues dans un
tampon de BPL ont été lues, ce tampon est envoyé dans BLP afin d’être de nouveau disponible pour la
tâche productrice du PIOCS. Quand BPL est vide, la tâche du LIOCS est alors mise en attente de
nouveaux tampons à consommer.
Lors d’une opération d’écriture, tous les descripteurs de tampons sont envoyés dans BPL. La tâche
réalisant l’opération les consomme au fur et à mesure qu’elle exécute des ordres d’écriture et les envoie
dans BLP qui contient alors les descripteurs de tampons écrits par le LIOCS et prêts à être recopiés une
tâche du PIOCS sur l’unité de sortie concernée par l’échange.
La figure 6.16 représente un exemple de gestion d’un port de sept tampons lors d’une opération de
lecture. Trois des tampons ont été remplis par le PIOCS et attendent d’être consommés par le LIOCS.
Deux des tampons Sont vides et attendent d’être remplis par le PIOCS. Un sixième tampon est en cours
d’exploitation par le LIOCS et un septième est simultanément exploité par le PIOCS. L’intérêt de ce
mécanisme est que le nombre de tampons n’est pas fixé a priori. Il est néanmoins limité à la place
mémoire disponible.

Figure 6.16. : Gestion d'un pool de tampon
1.6.5. / PRISE EN CHARGE DES ENTREES/SORTIES PAR LE SYSTEME
Le gestionnaire d’entrées/sorties doit permettre au système d’exploitation de :
· Offrir un ensemble de services suffisant pour que toutes les tâches utilisateur y trouvent de
quoi satisfaire leurs besoins,
· Fournir une réponse rapide aux demandes d’entrées/sorties,
· Gérer une structure de données afin de pouvoir exécuter simultanément plusieurs centaines
d’entrées/sorties (voire même plusieurs milliers sur les gros systèmes).
· Prendre en charge l’asynchronisme et offrir aux tâches des fonctions leur permettant de se re-
synchroniser,
· Assurer l’indépendance logiciel-matériel, ce qui est généralement obtenu par la notion de

conducteur d ‘interface.
1.6.5.1./ Les routines de services des entrées/sorties
A travers le gestionnaire d’entrées/sorties, un système d’exploitation offre aux programmes tout un

ensemble d’appels pour leur permettre de réaliser des opérations d’entrées/sorties sur les divers
périphériques disponibles sur la machine. Chaque type de périphérique possède son ensemble de
routines spécialisées.
1.6.5.2./ Structure de données associées aux entrées/sorties
Etant donné que plusieurs entrées/sorties peuvent être simultanément en cours sur différents
périphériques, pour stocker et retrouver facilement les paramètres relatifs à une entrée-sortie, un
système d’exploitation dispose d’une structure de données (cf. figure 6.17) pour les entrées/sorties en
cours. A chaque type de périphérique (physique ou virtuel) est associée une table, appelée descripteur
de périphérique, et située dans un espace mémoire réservé au système.

Cette table décrit les caractéristiques du périphérique. Parmi les informations qu’elle détient, deux
indicateurs Init et Début pointent sur les routines de pré-traitement et de démarrage d’une entrée-sortie
faisant partie du pilote conducteur d’interface. Lorsqu’un périphérique comprend plusieurs unités (par
exemple un contrôleur de terminaux possédant plusieurs lignes), à chaque unité sera associée une table
en mémoire, appelée descripteur d’unité contenant toutes les informations relatives à l’unité
périphérique considérée. Chaque entrée ou sortie demandée au système par une tâche est transformée
en un paquet d’informations (I/O packet) qui est stocké également dans l’espace mémoire réservé au
système. Ce paquet est mis dans une file d’attente des entrées/sorties en attente d’exécution. Le paquet
va contenir des informations telles que :
· Le type de l’opération d’entrée-sortie à effectuer (lecture ou écriture),
· L’adresse en mémoire de la zone tampon servant à l’échange,
· La longueur de l’entrée ou de la sortie (nombre d’informations à transférer),
· L’adresse dans le programme d’un mot d’état destiné à recevoir le statut final de l’opération ou
le numéro d’un drapeau que le système positionnera à la fin de l’opération,
· L’adresse d’une routine, fournie par la tâche et que le système exécutera à la fin de l’opération,
dans le cas d’un pilotage asynchrone (cf. §3.2 de ce chapitre).
Figure 6.17 : Structure de données associées aux entrées-sorties

1.6.6. / MECANISMES D’EXECUTION DE REQUETES D’ENTREES/SORTIES
Nous avons vu que les gestionnaires d’entrées/sorties permettent aux tâches des utilisateurs de
communiquer avec les unités périphériques au moyen de noms logiques (nom de fichier spécial par
exemple). Ce principe permet une définition dynamique de la connexion d’une tâche à une unité au
cours de son exécution, de la même manière qu’un fichier doit être ouvert pour y écrire ou y lire des
informations.
Ainsi, la seule manière pour un programme d’exécuter une opération d’entrées/sorties, est de faire appel
à la fonction correspondante du système. Cette fonction conçue par le concepteur du système est écrite
de façon optimisée afin de minimiser l’impact des opérations d’entrées/sorties sur les performances du
système. Son utilisation est réalisée par un appel au système. La forme de cet appel au système est celle
d’un appel de procédure. Il peut être réalisé Soit à partir d’une interruption interne, soit directement à
l’aide d’une instruction spéciale SVC (SuperVisor Call) qui crée une tâche de service chargée de
réaliser l’opération d’entrées/sorties. Cette instruction a deux paramètres :
· n : numéro de la routine du système,
· adresse: adresse de la zone mémoire contenant des informations concernant les données à
entrer ou à sortir.
Ainsi, un utilisateur qui désire, au cours d’une application, faire afficher sur un terminal la valeur d’une
variable V, doit le prévoir dans son programme. Selon le langage de programmation utilisé, il a alors
deux possibilités pour le faire :
· Soit l’application est écrite en langage assembleur et dans ce cas l’opération de sortie devra
être écrite sous la forme d’un appel la routine du système d’exploitation directement à laide de
l’instruction SVC,
· Soit l’application est écrite en langage évolué et dans ce cas le programmeur devra utiliser un
ordre tout préparé sous forme d’instruction et prévu dans la syntaxe du langage (WRITE en
langage PASCAL ou FORTRAN ou encore PRINTF en langage C...). C’est alors le
compilateur du langage qui traduit cet ordre en une instruction SVC et l’éditeur de liens génère
alors l’appel à la primitive du système d’exploitation qui doit être exécutée. Cette primitive est
réentrante de façon qu’elle puisse être utilisée par plusieurs tâches en même temps.
La figure 6.18 est un exemple de programme effectuant la lecture d’une donnée dans le fichier logique
INPUT. C’est l’instruction LIRE (INPUT, V) qui effectue cette requête. Cette instruction s’interprète
ainsi ‘Lire sur l’unité logique INPUT, une donnée qui doit être placée à l’adresse logique V’. Elle est
traduite lors de la compilation par l’instruction d’appel au superviseur SVC (Lecture, V) où le
paramètre Lecture correspond au numéro de la routine système souhaitée. C’est alors cette routine qui
déclenchera la tâche de service correspondante en mode synchrone ou asynchrone. Dans cet exemple, la
fonction du LIOCS est remplie par un simple appel, réalisé par l’instruction SVC, à la tâche de service
réalisée par le PIOCS. Cette tâche de service pourra bloquer la tâche du programme utilisateur si aucun
tampon est disponible.

Figure 6. 18 : Exemple d’exécution d’une opération de lecture
Dés que l’opération demandée est décodée, le gestionnaire d’entrées/sorties (I.O.M.) réalise les étapes
nécessaires à l’exécution de cette opération :
· Vérification de la cohérence du service demandé (lors d’une demande de lecture, il contrôle

par exemple, que le périphérique demandé est bien un dispositif d’entrée),
· Activation des fonctions du LIOCS et du PIOCS qui utiliseront le gestionnaire de tampons

chaque fois qu’elles auront besoin d’effectuer un transfert de tampons entre elles ou bien
qu’elles en libéreront,
· Envoi d’un événement (interruption) de fin de service à la tâche qui avait demandé l’opération.

2. TRAVAUX DIRIGES
METHODES DE PROGRAMMATIONS TRAVAUX DIRIGES Page 143

2.1. / Exercice 1 : La gestion des listes de tâches d’un système TR

2.1.1. / Enoncé
A l’aide des procédures de base :
- ENLEVER (T, LT) : retire une tâche T d’une liste LT.

- AJOUTER (T, LT): ajoute une tâche T d’une liste LT.
- TRANSFERRER () : basculer le microprocesseur d’une tâche vers une autre.
- ORDONNER (LT) : réorganise une liste de tâche LT en fonction de sa priorité (LTP) ou de
son temps d’attente (LTA & LTAS).
Ecrire l’algorithme des procédures de haut niveau suivantes :
1- S’ENDORMIR (Durée) : permet à la tâche active de s’arrêter pendant un certain temps ‘Durée’.
2- ENDORMIR (NomTâche, Durée) : permet à la tâche active d’arrêter une autre tâche ‘NomTâche’
pendant un certain temps ‘Durée’.
3- SUSPENDRE (Nomtâche) : permet de suspendre l’exécution de la tâche ‘NomTâche’.
4- DESSUPENDRE (Nomtâche) : permet de reprendre l’exécution de la tâche ‘NomTâche’.
Notas :
- On considère que l’on est avec un système temps réel (TR) qui traite 4 liste de tâches qui sont :
. LTP : Liste des Tâches Prêtes.

. LTA : Liste des Tâches en Attentes.
. LTS : Liste des Tâches Suspendues.
. LTAS : Liste des Tâches en Attentes et Suspendues.
- Pour le traitement des listes de tâches, on se réfèrera au figure 2.3 du chapitre 2.
2.1.2. / Solutions
2.1.2.1./ La procédure S’ENDORMIR
S’ENDORMIR (Durée)
{
ENLEVER (T1, LPT) ;
AJOUTER (T1, LTA) ;
Delai (T1) ß Durée ; // Mettre le paramètre ‘Delais’ du descripteur de tâche de T1 à la valeur ‘Durée’.
ORDONNER (LTA) ;
TRANSFERER () ;
}

Tâche Active
LTP
T1 LTA
S’ENDORMIR
(Durée) T2
2.1.2.2./ La procédure ENDORMIR
ENDORMIR (NomTâche, Durée)

{
Si NomTâche ∈ LTA Alors
{
ENLEVER (NomTâche, LTP) ;
AJOUTER (NomTâche, LTA) ;
Delais (NomTâche) ß Durée ;
ORDONNER (LTA) ;
TRANSFERER () ;
Exit () ;
}
Si NomTâche ∈ LTAS Alors

{
Delais (NomTâche) ß Delais (NomTâche) + Durée ;
ORDONNER (LTAS) ;
Exit () ;
}
Si NomTâche ∈ LTS Alors

{
ENLEVER (NomTâche, LTS) ;
AJOUTER (NomTâche, LTAS) ;
Delais (NomTâche) ß Durée ;
ORDONNER (LTAS) ;
Exit () ;
}


{
Delais (NomTâche) ß Delais (NomTâche) + Durée ;
ORDONNER (LTA) ;
Exit () ;
}
Si NomTâche ∈ LTP Alors

{
Afficher (« Erreur, la tâche ne peut être endormie !!! ») ;
Exit () ;
}
Afficher (« La tâche est inconnue !!! ») ;

}
2.1.2.3./ La procédure SUSPENDRE
SUSPENDRE (NomTâche)
{
Si NomTâche ∈ LTP Alors
{
AJOUTER (NomTâche, LTS) ;
Mettre le compteur de suspension de NomTâche à 1;
exit () ;
}
Si NomTâche est Active Alors

{
AJOUTER (NomTâche, LTS) ;
TRANSFERER () ;
exit () ;
}
Si (NomTâche ∈ LTAS) ou (NomTâche ∈ LTS) Alors

{
Incrémenter de 1 le compteur de suspension de NomTâche ;
exit () ;
}
…


{
ENLEVER (NomTâche, LTA) ;
AJOUTER (NomTâche, LTAS) ;
ORDONNER (LTAS) ;
exit () ;
}
Afficher (« Erreur, la tâche n’a pas été trouvée !!! ») ;

}
2.1.2.4./ La procédure DESSUSPENDRE
DESSUSPENDRE (NomTâche)
{
Si NomTâche ∈ LTS Alors
{
Décrémenter de 1 le compteur de suspension de NomTâche ;
Si le Compteur de suspension de Nomtâche = 0 Alors
{
ENLEVER (NomTâche, LTS) ;
AJOUTER (NomTâche, LTP) ;
ORDONNER (LTP) ;
Si NomTâche est en tête de LTP Alors
TRANSFERER () ;
FinSi
}
}
Si NomTâche ∈ LTAS Alors

{
Décrémenter de 1 le compteur de suspension de NomTâche ;
Si le Compteur de suspension de Nomtâche = 0 Alors
{
ENLEVER (NomTâche, LTAS) ;
AJOUTER (NomTâche, LTA) ;
ORDONNER (LTA) ;
}
}
Si (NomTâche ∈ LTP) ou (NomTâche ∈ LTA) ou (NomTâche est active) Alors

{
Afficher (« Erreur : La tâche est non suspendue ») ;
}
}

2.2. / Exercice 2 : La gestion de l’interruption de l’horloge TR

2.2.1. / Enoncé
A l’aide des procédures de base définies dans l’exercice 1, écrire l’algorithme de la procédure de traitement
de l’interruption de l’horloge temps réel pour les cas suivants :
- Dans le cas d’un système multiutilisateurs mettant en œ uvre un ordonnancement partourniquet

avec les listes de taches LTP et LTA.
- Dans le cas d’un système temps réel avec les listes LTP, LTA, LTS, et LTAS.
2.2.2. / Solutions
Pour un système multiutilisateur :
ITR_MULTIUSERS ()
{
Si LTA non vide Alors
{
Delais (1ére tâche LTA) ß Delais (1ére tâche LTA) –1 ;
Si Delais (1ére tâche LTA) = 0 Alors
{
ENLEVER (1ére tâche LTA, LTA) ; // On retire la 1ere tâche de LTA de la tête de LTA.
AJOUTER (1ére tâche LTA, LTP) ; // On la met à la fin de LTP.
Delais (1ére tâche LTA) = q ; // On réinitialise le quantum de temps de la tâche.
}
}
Si LTP non vide Alors

{
Delais (1ére tâche LTP) ß Delais (1ére tâche LTP) –1 ;
Si Delais (1ére tâche LTP) = 0 Alors
{
ENLEVER (1ére tâche LTP, LTP) ; // On retire la 1ere tâche de LTP de la tête de LTP.
AJOUTER (1ére tâche LTP, LTP) ; // On la met à la fin de LTP.
Delais (1ére tâche LTP) = q ; // On réinitialise le quantum de temps de la tâche.
TRANSFERER () ;
}
}

Pour un système Temps réel :
ITR_TR ()
{
Si LTAS non vide Alors
{
Delais (1ére tâche LTAS) ß Delais (1ére tâche LTAS) –1 ;
Si Delais (1ére tâche LTAS) = 0 Alors
{
ENLEVER (1ére tâche LTAS, LTAS) ; // On retire la 1ere tâche de LTAS de la tête de LTAS.
ére
AJOUTER (1 tâche LTAS, LTS) ; // On la met à la fin de LTS.
}
}
Si LTA non vide Alors

{
Delais (1ére tâche LTA) ß Delais (1ére tâche LTA) –1 ;
Si Delais (1ére tâche LTA) = 0 Alors
{
ENLEVER (1ére tâche LTA, LTA) ; // On retire la 1ere tâche de LTA de la tête de LTA.
AJOUTER (1ére tâche LTA, LTP) ; // On la met à la fin de LTP.
ORDONNER (LTP) ;
TRANSFERER () ;
}
}
}
Nota : Les listes de tâches LTP et LTS n’ont pas à être traitées dans un système temps réel.

2.3. / Exercice 3 : Ordonnancement de tâches dans un système TR

2.3.1. / Enoncé
Dans un contexte temps réel, on désire gérer une application composée de 4 tâches devant chacune
afficher à l’écran leur nom dans l’ordre suivant :
Tâche1, Tâche2, Tâche3↵

Tâche1↵ Pendant 30 secondes avec âche1 toutes les secondes.
Tâche1, Tâche2↵ Une 4éme tâche permettra l’affichage du caractère
retour chariot ’↵’.
Tâche1↵
Tâche1, Tâche2, Tâche3↵
1/ A l’aide de la procédure ENDORMIR (Nom_Tâche, Durée) ; de l’exercice N°1, écrire l’algorithme

des 4 tâches et de l’exécutif temps réel. Les durées d’exécution des tâches 1, 2, 3, et 4 sont
négligeable par rapport à une seconde. Les 4 tâches sont indépendantes les unes des autres.
L’exécutif temps réel créera les tâche 1, 2, 3, et 4, attendra 30 secondes, puis les détruira. Dans tous
les cas, la tâche 1 affiche son message toutes les secondes.
2/ Ecrire le même algorithme que dans l’énoncé précédent mais en utilisant les procédures
SUSPENDRE (Nom_Tâche) et DESSUSPENDRE (Nom_Tâche). Dans ce cas, il n’y a pas de
notion de temps pour l’exécution des tâches 1, 2, 3 et 4. On utilisera une 5éme tâche (Tâche5) pour
gérer la dessuspenssion des tâches 1, 2, 3 et 4. La seule notion de temps qui doit être conservé est
l’exécution pendant 30 secondes de l’exécutif temps réel.
3/ Ecrire le même algorithme que dans l’énoncé précédent mais en utilisant une 6éme tâche (Tâche6) qui
est chargée des affichages à l’écran. On écrira l’algorithme des 6 tâches et de l’exécutif temps réel
pour :
- Le cas d’une communication par variable commune.
- Le cas d’une communication par BaL.
4/ A partir de l’énoncé 2/, et en considérant que la tâche 5 est définie comme ci-dessous, écrire les
algorithmes des tâches 1, 2, 3 et 4 et de l’exécutif temps réel pour tenir comme de cette définition.
Tâche5 ()
{
TantQue ()
{
DESSUSPENDRE (Tâche1) ;
}
}

2.3.2. / Solutions
1/
Tâche1 ()
EXECUTIF_TR() {
{ TantQue ()
CREER Tâche1 ; {
CREER Tâche2 ; Afficher (« Tâche1 ») ;
CREER Tâche3 ; ENDORMIR (Tâche1, 1s);
CREER Tâche4 ; }
}
ENDORMIR (EXECUTIF_TR, 30s);
TUER Tâche1 ; Tâche2 ()

TUER Tâche2 ; {
TUER Tâche3 ; TantQue ()
TUER Tâche4 ; {
} Afficher (« Tâche2 ») ;
ENDORMIR (Tâche2, 2s);
}
}
Tâche4 ()
{
TantQue () Tâche3 ()
{ {
Afficher (« ↵ ») ; TantQue ()
ENDORMIR (Tâche4, 1s); {
} Afficher (« Tâche3 ») ;
} ENDORMIR (Tâche3, 4s);
}
}
2/
Tâche1 () Tâche2 ()
{ {
TantQue () TantQue ()
{ {
Afficher (« Tâche1 ») ; Afficher (« Tâche2 ») ;
SUSPENDRE (Tâche1); SUSPENDRE (Tâche2);
} }
} }

{ {
{ {
Afficher (« Tâche3 ») ; Afficher (« ↵ ») ;
} }
} }
EXECUTIF_TR() Tâche5 ()
{ {
CREER (Tâche1, P1) ; TantQue ()
CREER (Tâche2, P1) ; {
CREER (Tâche3, P1) ; DESSUSPENDRE (Tâche1);
CREER (Tâche5, P2) ;
DESSUSPENDRE (Tâche1);
ENDORMIR (EXECUTIF_TR, 30s); DESSUSPENDRE (Tâche2);
TUER Tâche1 ;
TUER Tâche2 ; DESSUSPENDRE (Tâche1);
TUER Tâche4 ;
} DESSUSPENDRE (Tâche2);
}
}
Nota : Dans l’exécutif temps réel, lors de la création des tâches, on défini leurs priorités. P1 est une
priorité qui est supérieure à P2. La tâche 5 doit être moins prioritaire que les tâche 1, 2, 3 et 4 sinon il n’y
aurai pas d’affichage à l’écran.

3/
Le cas d’une communication par variable commune
Tâche1 ()
{
TantQue ()
{
P(Exmu) ; // On charge le sémaphore du message.
Ecrire (« Tâche 1 » à Mess) ;
V(Exmu) ; // On libère le sémaphore du message.
SUSPENDRE (Tâche1);
V(S) ; // Indique qu’il y a un message à faire afficher par Tâche6.
}
}
Tâche2 ()
{
TantQue ()
{
}
}
Tâche3 ()
{
TantQue ()
{
}
}

Tâche4 ()
{
TantQue ()
{
Ecrire (« ↵ » à Mess) ;
}
}
EXECUTIF_TR() Tâche5 ()
{ {
CREER (Tâche1, P2) ; TantQue ()
CREER (Tâche2, P2) ; {
ENDORMIR (EXECUTIF_TR, 30s); DESSUSPENDRE (Tâche4);

TUER Tâche3 ;
} DESSUSPENDRE (Tâche4);
}
}
Nota : Dans l’exécutif temps réel, lors de la création des tâches, on a les priorités qui sont définies par :
P1 > P2 > P3.
Cette condition est nécessaire pour une bonne gestion du sémaphore de présence du message (S).

Tâche6 ()
{
TantQue ()
{
P(S); // Vérifie qu’il y a un message à afficher (sémaphore de présence).
P(Exmu) ;
Lire (Mess) ; // Gestion du sémaphore de message.
Afficher (Mess) ;
V(Exmu) ;
}
}
‚ Le cas d’une communication par BaL.
Tâche1 ()
{
TantQue ()
{
P(PlaceLibre) ; // Vérifie s’il y a de la place dans la BaL.
DEPOSER (« Tâche 1 », BaL) ;
V(Message) ; // Incrémente le compteur de messages dans la BaL.
}
}
Tâche2 ()
{
TantQue ()
{
}
}

Tâche3 ()
{
TantQue ()
{
}
}
Tâche4 ()
{
TantQue ()
{
DEPOSER (« ↵ », BaL) ;
}
}
EXECUTIF_TR()
{
ENDORMIR (EXECUTIF_TR, 30s);
TUER Tâche1 ;
TUER Tâche2 ;
TUER Tâche3 ;
TUER Tâche4 ;
TUER Tâche5 ;
TUER Tâche6 ;
}

Tâche5 ()
{
TantQue ()
{
}
}
Tâche6 ()
{
TantQue ()
{
P(Message); // Vérifie le compteur de message dans la BaL et le décrémente.
RETIRER (Mess, BaL) ;
Afficher (Mess) ;
V(PlacesLibre) ; // Libère le message de la BaL
}
}
4/
Tâche1 à Idem 2/
Tâche4 à Idem 2/
EXECUTIF_TR à Idem 2/
METHODES DE PROGRAMMATIONS INDEX Page 157

{ {
{ {
Afficher (« Tâche2 ») ; Afficher (« Tâche3 ») ;
} SUSPENDRE (Tâche3);
} SUSPENDRE (Tâche3);
}
}
2.4. / Exercice 4 : Adressage d’une mémoire virtuelle paginée
2.4.1. / Enoncé
Supposons qu’une @ mémoire virtuelle nécessite 20 bits.
Bits à |19 … 12|11 … 0|

page offset
1/ Quelle est la taille de cette mémoire virtuelle exprimée en nombre de mots et en nombre de pages.
2/ Qu’elle est l’@ hexa et octale du 970éme mot de la page 213.
3/ A quel mot de quelle page correspond l’@ hexa ‘ABCDE’. Donner le résultat en décimal.
2.4.2. / Solutions
1/ La page est sur 8 bits et l’offset est sur 12 bits. Il y a 28 pages (256) d’une taille de 212 mots (4096).
Soit : 256 pages x 4096 mots = 1 M mots.
2/ Comme on commence à l’@ mémoire 0, le 970éme mot est l’emplacement mémoire n°969.
Soit @ = [969 + (213 x 4096)]10 = (D53C9)16 = (3251711)8
3/ (A B C D E)16 = (1010 1011 1100 1101 1110)2
offset = (3294)10
Page = (171)10

2.5. / Exercice 5 : Adressage d’une mémoire virtuelle segmentée et paginée
2.5.1. / Enoncé
Supposons qu’une @ mémoire virtuelle nécessite 24 bits.
Bits à |23 … 18|17 … 12|11 … 0|

segment page offset
1/ Quelle est la taille de cette mémoire virtuelle exprimée en nombre de segments, de pages, et de mots.
2/ Qu’elle est l’@ octale du 145éme mot de la page 11 du 32éme segment.
3/ A quel mot de quelle page et de quel segment correspond l’@ octale ‘41032567’. Donner le résultat en
décimal.
2.5.2. / Solutions
1/ Le segment est sur 6 bits, la page est sur 6 bits et l’offset est sur 12 bits. Il y a 26 segments (64), 26
pages (64) pour un segment, et 212 mots (4096) pour une page.
Soit : 64 segments x 64 pages x 4096 mots = 16 M mots.
2/ Comme on commence à l’@ mémoire 0, le 145éme mot est l’emplacement mémoire n°144. Comme on
commence au segment 0, le 32éme segment est le n°31.
Soit @ = [31 11 0144]10 = (37 13 0220)8
3/ (41 03 2567)8 = (33 03 1399)10
offset
Page
Segment

2.6. / Exercice 6 : Gestion d’une mémoire virtuelle paginée

2.6.1. / Enoncé
Dans un système à mémoire paginée, un programme est constitué de 6 pages virtuelles numérotées de 0
à 5. Chaque bloc a une taille de 2048 octets. A un instant donné, seules 4 pages de ce programme sont
chargées en mémoire de la manière suivante :
Pages virtuelles Blocs

0 8
1 3
2 Absente
3 Absente
4 0
5 2
Pour chaque adresse virtuelle données ci dessous, indiquer si elles provoquent un défaut de page. Dans le
cas contraire, calculer en octets l’adresse réelle correspondante.
Les adresses virtuelles sont les suivantes : 00002 ; 02050 ; 05000 ; 09000 ; 11000.
2.6.2. / Solutions
Plages d’@ Page Défaut @ Blocs Plages @ Réel Blocs

virtuelles de page virtuelles correspondant d’@ réelles
00000 00000
| 0 Non @00002 8 | 808 0
02047 02047
02048 02048
| 1 Non @02050 3 | - 1
04095 04095
04096 04096
| 2 Oui @05000 - | 760+4096=4056 2
06143 (absente) 06143
06144 06144
| 3 Oui - - | 6144+2=6146 3
08191 (absente) 08191
08192 08192
| 4 Non @09000 0 | - 4
10239 10239
10240 10240
| 5 Non @11000 2 | - 5
12287 12287
12288
| - 6
14323
14324
| - 7
16383
16384
| 16384+2=16386 8
18419

2.7. / Exercice 7 : Gestion d’une mémoire virtuelle et défauts de pages

2.7.1. / Enoncé
Soit un système informatique disposant de 24 pages virtuelles mais de seulement 4 blocs. La mémoire
est considérée vide au départ. Un programme référence les pages virtuelles dans l’ordre suivant :
0 ; 1 ; 7 ; 1 ; 5 ; 7 ; 2 ; 7 ; 18 ; 9 ; 2 ; 17 ; 14 ; 4 ; 17 ; 2.
Quelles sont les références qui provoquent des défauts de pages pour :
- Une gestion avec un algorithme de remplacement du type FIFO (First In First Out).
- Une gestion avec un algorithme de remplacement du type LRU (Last Recent Used).
2.7.2. / Solutions
Pages Etats des blocs Défauts Pages Etats des blocs Défauts
(FIFO) de pages (LRU) de pages
0 - - - 0 Oui 0 - - - 00 Oui
1 - - 1 0 Oui 1 - - 10 01 Oui
7 - 7 1 0 Oui 7 - 70 11 02 Oui
1 - 7 1 0 Non 1 - 71 10 03 Non
5 5 7 1 0 Oui 5 50 72 11 04 Oui
7 5 7 1 0 Non 7 51 70 12 05 Non
2 5 7 1 2 Oui 2 52 71 13 20 Oui
7 5 7 1 2 Non 7 53 70 14 21 Non
18 5 7 18 2 Oui 18 54 71 180 22 Oui
9 5 9 18 2 Oui 9 90 72 181 23 Oui
2 5 9 18 2 Non 2 91 73 182 20 Non
17 17 9 18 2 Oui 17 92 170 183 21 Oui
14 17 9 18 14 Oui 14 93 171 140 22 Oui
4 17 9 4 14 Oui 4 40 172 141 23 Oui
17 17 9 4 14 Non 17 41 170 142 24 Non
2 17 2 4 14 Oui 2 42 171 143 20 Non
Xn : X est la page
Total : 11 virtuelle et n le Total : 10
compteur de
référence ment de
la page pour LRU

2.8. / Exercice 8 : Temps d’exécution d’une instruction et défaut de page

2.8.1. / Enoncé
L’exécution d’une instruction prend ‘1’ microseconde. Le temps additionnel nécessaire au traitement d’un
défaut de page prend ‘n’ microseconde. Donner une formule définissant le temps effectif d’exécution d’une
instruction si des défauts de page se produisent toutes les ‘k’ instructions.
2.8.2. / Solutions
Tee =
1+ n
Le temps effectif d’exécution est défini par la formule suivante : k
2.9. / Exercice 9 : Temps d’exécution d’une instruction et heure d’arrivée
2.9.1. / Enoncé
Soit les 4 tâches suivantes ainsi que leurs temps d’exécution et leurs heures d’arrivée :
Tâches Heure d’arrivée Temps d ‘exécution antérieur

A 0 8
B 1 4
C 2 9
D 3 5
1/ Donnez les temps d’exécution de chacune des tâches ainsi que le temps moyen d’exécution des tâches
en utilisant l’algorithme d’ordonnancement du « plus court d’abord » (Shortest Job First).
1/ Donnez les temps d’attente de chacune des tâches ainsi que le temps d’attente moyen avec le même
algorithme en supposant que cet algorithme puisse préempter une tâche entrante dans le système avec un
temps d’exécution plus faible que celui qui est en cours d’exécution avec l’algorithme du « plus court
temps restant » (Shortest Remaining Time). Donnez le nouveau temps moyen d’exécution des tâches.
2.9.2. / Solutions
1/ Algorithme d’ordonnancement du « plus court d’abord ».
Avec cet algorithme, la priorité est donnée à la tâche dont le temps d’exécution est le plus faible. C’est un
algorithme sans réquisition.
Tâches Heure d’arrivée Temps d ‘exécution antérieur Fin exécution Temps d’exécution
A 0 8 8 8
B 1 4 (8+4)-1 11
C 2 9 8+4+9+5 24
D 3 5 (8+4+9)-3 14

Temps exé. A = 8 4 5 9
AAAAAAAA BBBB DDDDD CCCCCCCCC
Temps exé. B = 11 TempsTotal 8+11+14+ 24

TempsExé = = =14.25
NbTâches 4
t=0
Temps exé. D = 14
t=1
t=3
Temps exé. C = 24
t=2
2/ Algorithme du « plus court temps restant ».
Tâches Heure d’arrivée Temps d ‘exécution antérieur Temps d’attente

A 0 8 4+5 = 9
B 1 4 0
C 2 9 7+5+3 = 15
D 3 5 2
Temps exé.
1 B=4 5 7 9
A BBBB DDDDD AAAAAA CCCCCCCCC

Temps exé.
D=7 TempsTotal 9+15+ 2
TempsExé = = =6.5
NbTâches 4
t=3
Temps exé. A = 17
t=0
t=1 Temps exé. C = 24
t=2

3. INDEX

adresse logique 32, 95, 106, 109, 110, 112, 116, 141
adresse physique 32, 66, 100, 103, 106, 107, 109, 110, 113, 114, 116, 137
adresses logiques 101, 102, 103, 114, 115
allocateur 31, 37, 38, 39, 41, 42, 43, 44, 49, 54, 56, 57, 58, 59, 60
allocation 17, 20, 24, 30, 34, 39, 42, 43, 49, 50, 55, 58, 59, 97, 102, 103, 105, 138
antémémoire 98
arrière plan 98
boîtes aux lettres 60, 92, 138
cache 98
compteur ordinal 41, 43, 66, 71, 76, 82, 127
contrôleur d’interruption 76
deadlock 91
défaut de page 38, 50, 113, 116
délai 40, 44, 45, 47, 48, 59
déroutements 78
descripteur de tâches 44, 47
device driver 128, 134, 136
DMA 120, 122, 123, 124, 125, 127
entrées/sorties 38, 50, 130, 134, 135, 136, 138, 139, 140, 141, 142
FIFO 52, 54, 58, 117

files 56, 57, 93, 135
FIRQ 75
flag 132
horloge 26, 27, 31, 40, 45, 46, 47, 48, 51, 56, 63
interblocage 91
interruptions externes 63, 64, 69, 78
interruptions internes 63
IOM 134

IRQ 69, 72, 73, 75

ITA 69, 72, 73, 74, 75
jetons d’accès 84
LFU 117
LIOCS 135, 136, 137, 138, 141, 142
liste des tâches 39, 42, 43, 44, 45, 46, 47, 48, 49, 52, 53, 54, 55, 58, 59, 60, 71, 84, 86
LRU 117, 161, 169
M.M.U 31, 99, 103, 109, 110

masquage 67, 76, 77, 78
mémoire centrale 10, 12, 17, 25, 32, 97, 98, 101, 103, 104, 106, 109, 113, 116, 118, 123, 127, 134
mémoire de masse 32, 97, 98, 99, 102, 104, 106, 113, 114
mémoire virtuelle 18, 31, 97, 101, 103, 104, 105, 106, 109, 110, 111, 112, 113, 114, 118
mémoire virtuelle linéaire 106
mémoire virtuelle segmentée 106, 109, 114
MFU 117
mode rafale 127
mode superviseur 65, 77
mode utilisateur 65, 71, 77, 78
monotâche 15, 30
MRU 117
multiplexeur 126, 127
multiprogrammation 16, 17, 19, 24, 29, 36, 50, 53, 79, 97
multitâche 18, 22, 24, 25, 26, 27, 29, 33, 34, 36, 59
multi-utilisateur 25, 28, 34, 40, 49, 53, 54, 55
Mutex 84, 85
NMI 75
ordonnancement 12, 24, 29, 34, 37, 44, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59
overlay 104
pagination 31, 101, 110, 113, 114, 116

PEPS 117
périphérique21, 64, 69, 72, 73, 74, 79, 118, 119, 120, 121, 122, 123, 124, 125, 127, 128, 129, 130, 131, 132, 133, 134, 135, 137,
139, 140, 142
pile 39, 43, 44
PIOCS 136, 137, 138, 141, 142
polling 70, 76
prepaging 116

priorités 24, 26, 33, 49, 51, 54, 55, 72, 73

processus 24, 34, 50, 67, 79, 83, 118, 119, 124, 132
quantum 54, 55, 56, 57
registres 41, 42, 43, 65, 75, 76, 77, 98, 100, 101, 120, 123, 124, 125, 126, 128
Rendez-vous 95, 96
round robin 54
routine d'interruption 65, 70
scrutation 70, 76
section critique 81, 82, 83, 84, 85
segmentation 31, 101, 104, 106, 110, 114
segmentation manuelle 104
sélecteur 125, 126, 127
sémaphore 60, 82, 83, 84, 85, 88, 89, 90, 91, 92, 93, 95
spooling 16, 17
synchronisation 12, 31, 37, 45, 59, 60, 61, 79, 85, 86, 87, 88, 89, 90, 91, 93, 94, 95, 102, 121
tâches 12, 17, 22, 24, 25, 26, 28, 29, 30, 31, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55,
56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 71, 79, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 99, 102, 103, 104,
127, 133, 134, 135, 139, 141, 144
TAS 82, 83
temps d’attente 17, 41, 44, 45, 46, 47, 50, 53, 54, 63, 133
temps partagé 17, 18, 19, 25, 26, 38, 41, 83
temps-réel 18, 26, 27, 28, 31, 40, 46, 51, 61, 63, 70, 79, 83, 86, 104, 118, 119
trap 63, 78
UNIX 18, 19, 22, 23
variables communes 91, 92

vecteurs d’interruption 73, 74
vol de cycle 122, 124

4. LEXIQUE
RESEAUX LEXIQUE Page 168

BaL Boîte aux Lettres

BTP Browser Table Page
DMA Direct Memory Access
DRAM Dynamic Random Access Memory
FIFO First In, First Out
FIRQ Fast Interrupt Request
IOM Input Ouput Manager
IRQ Interrupt Request
ITA Interrupt Acknowledge
LFU Last Frequently Used
LIFO Last In First Out
LIOCS Logical Input-Output Control System
LRU Last Recently Used
LSB Less Signifiant Bit
LTA Liste des Tâches en Attentes
LTAS Liste des Tâches en Attentes et Suspendues
LTP Liste des Tâches Prêtes
LTS Liste des Tâches Suspendues
MFU Moins Fréquemment Utilisé
MMU Memory Management Unit
MRU Moins Récemment Utilisé
MSB Most Signifiant Bit
NMI Non Masquable Interrupt
PEPS Premier Entré Premier Sorti
PIC Programmable Interrupt Controler
PIOCS Physical Input-Output Control System
RTP Register Table Page
RTS Register Table Segment
SJF Shostest Job First
SRT Shostest remaining Time
SVC SuperVisor Call
TAS Test And Set
RESEAUX LEXIQUE Page 169

5. Licence de Documentation Libre

Version 1.1, mars 2000 Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 États-Unis d'Amérique. La copie et la distribution de copies exactes de ce document
sont autorisées, mais aucune modification n'est permise.
PRÉAMBULE
Le but de la présente Licence est de « libérer » un ouvrage, un manuel, ou tout autre document écrit : assurer à chacun la liberté véritable et complète de le copier et de le redistribuer, en le modifiant ou non,
commercialement ou non. De plus, la présente Licence garantit à l'auteur et à l'éditeur un moyen d'être remerciés pour leur travail, sans devoir assumer la responsabilité de modifications effectuées par des tiers.
La présente Licence est une variété de gauche d'auteur (copyleft), ce qui signifie que les travaux dérivés du document protégé doivent être libres dans la même acception du mot « libre ». Elle complète la Licence
Publique Générale GNU ( GNU General Public License), qui est une licence de gauche d'auteur conçue pour le logiciel libre.
Nous avons conçu la présente licence dans le dessein de l'utiliser pour les manuels de logiciels libres, car les logiciels libres requièrent une documentation libre : un programme libre devrait être accompagné de
manuels offrant la même liberté que le programme lui-même. Mais la présente Licence n'est pas limitée aux manuels de logiciels ; on peut l'utiliser pour tout travail textuel, indépendamment du sujet, de son
contenu, et de son mode de distribution (livre imprimé ou autres). Nous recommandons la présente Licence principalement pour les travaux à vocation d'instruction ou de référence.
1. DOMAINE D'APPLICATION ET DÉFINITIONS
La présente Licence s'applique à tout manuel ou travail contenant une mention placée par le détenteur du copyright indiquant que le document peut être distribué selon les termes de la présente Licence. Le terme «
Document », ci-dessous, se réfère à tout manuel ou travail remplissant cette condition. Tout membre du public est bénéficiaire de la licence et se trouve ici désigné par « vous ».
Une « Version Modifiée » du Document signifie : tout travail contenant le Document, en intégralité ou en partie, aussi bien une copie verbatim ou avec des modifications qu'une traduction dans une autre langue.
Une « Section Secondaire » est une annexe ou un avant-propos du Document qui concerne exclusivement le rapport de l'éditeur ou des auteurs du Document avec le sujet général du Document (ou des domaines
voisins) et ne contient rien qui puisse tomber directement sous le coup du sujet général (par exemple, si le Document est en quelque partie un manuel de mathématiques, une Section Secondaire n'enseignera pas
les mathématiques). Le rapport peut être une connexion historique avec le sujet ou des domaines voisins, ou une précision légale, commerciale, philosophique, éthique ou politique les concernant.
Les « Sections Invariables » sont certaines Sections Secondaires désignées par leurs titres comme Sections Invariables dans la mention qui indique que le Document est couvert par la présente Licence.
Les « Textes de Couverture » sont certains courts passages du texte listés comme « Textes de Première de Couverture » ou « Textes de Quatrième de Couverture » dans la mention qui indique que le Document est
couvert par la présente Licence.
Une copie « Transparente » du Document signifie : une copie lisible par une machine, réalisée dans un format dont les spécifications sont disponibles au grand public, et dont le contenu peut être directement
visualisé et édité avec des éditeurs de texte génériques ou (pour les images composées de pixels) avec des programmes de composition d'images génériques ou (pour les figures techniques) un éditeur de dessin
vectoriel largement diponible, et qui soit approprié aux logiciels qui mettent le texte en forme et le calibrent (formateurs de texte) ou au transcodage automatique vers un assortiment de formats appropriés aux
formateurs de texte. Une copie réalisée dans un format de fichier habituellement Transparent mais dont le balisage a été conçu pour contrecarrer ou décourager des modifications ultérieures par le lecteur n'est pas
Transparente. Une copie qui n'est pas « Transparente » est appelée « Opaque ».
Les formats appropriés aux copies Transparentes sont par exemple l'ASCII brut sans balises, le format Texinfo, le format LaTeX, SGML ou XML utilisant une DTD publiquement disponible, et l'HTML simple et
conforme à la norme, conçu en vue d'une modification manuelle. Les formats Opaques incluent PostScript, PDF, les formats propriétaires qui ne peuvent être lus et édités que par des traitements de texte
propriétaires, SGML et XML dont les DTD et/ou les outils de rendu ne sont pas généralement disponibles, et l'HTML généré automatiquement par certains traitements de texte à seule fin d'affichage.
La « Page de Titre » désigne, pour un livre imprimé, la page de titre proprement dite, plus les pages suivantes qui sont nécessaires pour faire figurer, lisiblement, les éléments dont la présente Licence requiert qu'ils
apparaissent dans la Page de Titre. Pour les travaux dont le format ne comporte pas de page de titre en tant que telle, « Page de Titre » désigne le texte jouxtant l'apparition la plus marquante du titre de ce travail,
qui précède le début du corps du texte.
2. COPIES VERBATIM
Vous pouvez copier et distribuer le Document sur tout support, aussi bien commercialement que non, pour autant que la présente Licence, les mentions de copyright, et les mentions de licence indiquant que la
présente Licence s'applique au Document soient reproduites sur toutes les copies, et que vous n'ajoutiez aucune autre condition à celles de la présente Licence. Vous ne pouvez pas user de moyens techniques à des
fins d'obstruction ou de contrôle de la lecture ou de la duplication des copies que vous réalisez ou distribuez. Vous pouvez cependant accepter des compensations en échange de la cession de copies. Si vous
distribuez un assez grand nombre de copies, vous devez aussi suivre les conditions de la section Copies en quantité.
Vous pouvez aussi prêter des copies, selon les mêmes conditions que celles mentionnées ci-dessus, et vous pouvez exposer publiquement des copies.
3. COPIES EN QUANTITÉ
Si vous publiez des copies imprimées du Document à plus de 100 exemplaires, et que la mention de la licence du Document exige des Textes de Couverture, vous devez inclure les copies dans des couvertures où
figurent, clairement et lisiblement, tous ces Textes de Couverture : les Textes de Première de Couverture sur la première de couverture, et les Textes de Quatrième de Couverture sur la quatrième de couverture. Les
deux faces de la couverture doivent également clairement et lisiblement vous identifier comme étant l'éditeur de ces copies. La première de couverture doit présenter le titre complet, titre dont tous les mots doivent
être également mis en valeur et visibles. Vous pouvez ajouter des éléments supplémentaires sur les couvertures. Toute copie avec des changements limités aux couvertures, pour autant qu'ils préservent le titre du
Document et satisfont ces conditions, peut être considérée comme une copie verbatim à tous les autres égards.
Si les textes destinés à l'une ou l'autre page de couverture sont trop volumineux pour y figurer lisiblement, vous devez en mettre les premiers (autant qu'il est raisonnablement possible) sur la couverture proprement
dite, et poursuivre sur les pages adjacentes.
Si vous publiez ou distribuez des copies Opaques du Document à plus de 100 exemplaires, vous devez soit inclure une copie Transparente dans un format lisible par une machine, adapté au traitement automatisé,
en accompagnement de chaque copie Opaque, soit indiquer aux côtés de ou dans chaque copie Opaque une adresse de réseau électronique publiquement accessible, qui permette d'obtenir une copie Transparente
du Document, sans éléments ajoutés, à laquelle le grand public puisse accéder pour téléchargement anonyme et sans frais en utilisant des protocoles de réseau publics et standard. Si vous retenez la dernière option,
vous devez procéder prudemment et prendre les mesures nécessaires, lorsque vous commencez la distribution de copies Opaques en quantité, afin de vous assurer que cette copie Transparente demeurera
accessible au public pendant au moins une année après le moment de la distribution (directement ou par l'intermédiaire de vos agents ou revendeurs) de la dernière copie Opaque de cette édition.
Il est souhaité, mais non exigé, que vous contactiez les auteurs du Document bien avant la redistribution de tout grand nombre de copies, afin de leur laisser la possibilité de vous fournir une version mise à jour du
Document.
4. MODIFICATIONS
Vous pouvez copier et distribuer une Version Modifiée du Document selon les conditions des sections Copies verbatim et Copies en quantité qui précèdent, pourvu que vous diffusiez la Version Modifiée sous
couvert précisément de la présente Licence, avec la Version Modifiée remplissant alors le rôle du Document, et ainsi autoriser la distribution et la modification de la Version Modifiée à quiconque en possède une
copie. En complément, vous devez accomplir ce qui suit sur la Version Modifiée :
A. Utilisez dans la Page de Titre (et sur les couvertures, le cas échéant) un titre distinct de celui du Document et de ceux des précédentes versions (qui doivent, s'il en existe, être citées dans la section «
Historique » du Document). Vous pouvez utiliser le même titre qu'une version précédant la vôtre si l'éditeur original vous en donne la permission.
B. Indiquez sur la Page de Titre, comme auteurs, une ou plusieurs personnes ou entités responsables de l'écriture des modifications de la Version Modifiée, ainsi qu'au moins cinq des principaux auteurs
du Document (ou tous les auteurs principaux, s'ils sont moins de cinq).
C. Apposez sur la Page de Titre de nom de l'éditeur de la Version Modifiée, en tant qu'éditeur.
D. Préservez toutes les mentions de copyright du Document.
E. Ajoutez une mention de copyright appropriée à vos modifications, aux côtés des autres mentions de copyright.
METHODES DE PROGRAMMATIONS Licence de Documentation Libre Page 170

F. Incluez, immédiatement après les mentions de copyright, une mention de licence qui accorde la permission publique d'utiliser la Version Modifiée selon les termes de la présente Licence, sous la forme
présentée dans la section Addendum ci-dessous.
G. Préservez dans cette mention de licence les listes complètes des Sections Invariables et des Textes de Couverture exigés, données dans la mention de licence du Document.
H. Incluez une copie non altérée de la présente Licence.
I. Préservez la section intitulée « Historique », et son titre, et ajoutez-y un article indiquant au moins le titre, l'année, les nouveaux auteurs, et l'éditeur de la Version Modifiée telle qu'elle apparaît sur la
Page de Titre. Si le Document ne contient pas de section intitulée « Historique », créez-en une et indiquez-y le titre, l'année, les auteurs et l'éditeur du Document tels qu'indiqués sur la Page de Titre, puis
ajoutez un article décrivant la Version Modifiée, comme exposé dans la phrase précédente.
J. Préservez, le cas échéant, l'adresse de réseau électronique donnée dans le Document pour accéder publiquement à une copie Transparente du Document, et préservez de même les adresses de réseau
électronique données dans le Document pour les versions précédentes, sur lequelles le Document se fonde. Cela peut être placé dans la section « Historique ». Vous pouvez omettre l'adresse de réseau
électronique pour un travail qui a été publié au moins quatre ans avant le Document lui-même, ou si l'éditeur original de la version à laquelle il se réfère en donne l'autorisation.
K. Dans toute section intitulée « Remerciements » ou « Dédicaces », préservez le titre de section et préservez dans cette section le ton et la substance de chacun des remerciements et/ou dédicaces donnés
par les contributeurs.
L. Préservez toutes les Sections Invariables du Document, non altérées dans leurs textes et dans leurs titres. Les numéros de sections ou leurs équivalents ne sont pas considérés comme faisant partie des
titres de sections.
M. Supprimez toute section intitulée « Approbations ». Une telle section ne doit pas être incluse dans la Version Modifiée.
N. Ne changez pas le titre d'une section existante en « Approbations » ou en un titre qui entre en conflit avec celui d'une Section Invariable quelconque.
Si la Version Modifiée inclut de nouvelles sections d'avant-propos ou des annexes qui remplissent les conditions imposées aux Sections Secondaires et ne contiennent aucun élément tiré du Document, vous
pouvez, à votre convenance, désigner tout au partie de ces sections comme « Invariables ». Pour ce faire, ajoutez leurs titres à la liste des Sections Invariables dans la mention de licence de la Version Modifiée. Ces
titres doivent être distincts de tout autre titre de section.
Vous pouvez ajouter une section intitulée « Approbations », pourvu qu'elle ne contienne rien d'autre que l'approbation de votre Version Modifiée par diverses parties -- par exemple, indication d'une revue par les
pairs ou bien que le texte a été approuvé par une organisation en tant que définition de référence d'un standard.
Vous pouvez ajouter un passage de cinq mots ou moins en tant que Texte de la Première de Couverture, et un passage de 25 mots ou moins en tant que Texte de Quatrième de Couverture, à la fin de la liste des
Textes de Couverture de la Version Modifiée. Toute entité peut ajouter (ou réaliser, à travers des arrangements) au plus un passage en tant que Texte de la Première de Couverture et au plus un passage en tant que
Texte de la Quatrième de Couverture. Si le Document inclut déjà un texte de Couverture pour la même couverture, précédemment ajouté par vous ou, selon arrangement, réalisé par l'entité pour le compte de
laquelle vous agissez, vous ne pouvez en ajouter un autre ; mais vous pouvez remplacer l'ancien, avec la permission explicite de l'éditeur qui l'a précédemment ajouté.
Le ou les auteur(s) et le ou les éditeur(s) du Document ne confèrent pas par la présente Licence le droit d'utiliser leur nom à des fins publicitaires ou pour certifier ou suggérer l'approbation de n'importe quelle
Version Modifiée.
5. MÉLANGE DE DOCUMENTS
Vous pouvez mêler le Document à d'autres documents publiés sous la présente Licence, selon les termes définis dans la section Modifications ci-dessus, traitant des versions modifiées, pour autant que vous
incluiez dans ce travail toutes les Sections Invariables de tous les documents originaux, non modifiées, et en les indiquant toutes comme Sections Invariables de ce travail dans sa mention de licence.
Le travail issu du mélange peut ne contenir qu'une copie de cette Licence, et de multiples Sections Invariables identiques peuvent n'être présentes qu'en un exemplaire qui les représentera toutes. S'il existe plusieurs
Sections Invariables portant le même nom mais des contenus différents, faites en sorte que le titre de chacune de ces sections soit unique, en indiquant à la fin de chacune d'entre elles, entre parenthèses, le nom de
l'auteur original ou de l'éditeur de cette section s'il est connu, ou un numéro unique dans les collisions restantes. Pratiquez les mêmes ajustements pour les titres de sections, dans la liste des Sections Invariables de
la mention de licence de ce travail mélangé.
Dans le mélange, vous devez regrouper toutes les sections intitulées « Historique » dans les divers documents originaux, afin de constituer une unique section intitulée « Historique » ; combinez de même toutes les
sections intitulée « Remerciements », et toutes les sections intitulées « Dédicaces ». Vous devez supprimer toutes les sections intitulées « Approbations ».
6. RECUEILS DE DOCUMENTS
Vous pouvez réaliser un recueil regroupant le Document et d'autres documents publiés sous la présente Licence, et remplacer les diverses copies de la présente Licence figurant dans les différents documents par
une copie unique incluse dans le recueil, pour autant que vous suiviez les règles de la présente Licence relatives à la copie verbatim pour chacun de ces documents, dans tous les autres aspects.
Vous pouvez n'extraire qu'un seul document d'un tel recueil, et le distribuer individuellement sous la présente Licence, pour autant que vous insériez une copie de la présente Licence dans le document extrait, et
que vous suiviez la présente Licence dans tous ses autres aspects concernant la reproduction verbatim de ce document.
7. AGRÉGATION AVEC DES TRAVAUX INDÉPENDANTS
Une compilation du Document ou de ses dérivés avec d'autres documents ou travaux séparés et indépendants, ou bien sur une unité de stockage ou un support de distribution, ne compte pas comme une Version
Modifiée de ce Document, pour autant qu'aucun copyright de compilation ne soit revendiqué pour la compilation. Une telle compilation est appelée une « agrégation », et la présente Licence ne s'applique pas aux
autres travaux contenus et ainsi compilés avec le Document, sous prétexte du fait qu'ils sont ainsi compilés, s'ils ne sont pas eux-mêmes des travaux dérivés du Document.
Si les exigences de la section Copies en quantité en matière de Textes de Couverture s'appliquent aux copies du Document, et si le Document représente moins du quart de la totalité de l'agrégat, alors les Textes de
Couverture du Document peuvent n'être placés que sur les couvertures qui entourent le document, au sein de l'agrégation. Dans le cas contraire, ils doivent apparaître sur les couvertures entourant tout l'agrégat.
8. TRADUCTION
La traduction est considérée comme un type de modification, de sorte que vous devez distribuer les traductions de ce Document selon les termes de la section Modifications. La substitution des Sections
Invariables par des traductions requiert une autorisation spéciale de la part des détenteurs du copyright, mais vous pouvez ajouter des traductions de tout ou partie des Sections Invariables en sus des versions
originales de ces Sections Invariables. Vous pouvez inclure une traduction de la présente Licence pourvu que que vous incluiez la version originale, en anglais, de la présente Licence. En cas de désaccord entre la
traduction et la version originale, en anglais, de la présente Licence, la version originale prévaudra.
9. RÉVOCATION
Vous ne pouvez copier, modifier, sous-licencier ou distribuer le Document autrement que selon les conditions expressément prévues par la présente Licence. Toute tentative de copier, modifier, sous-licencier ou
distribuer autrement le Document est nulle et non avenue, et supprimera automatiquement vos droits relatifs à la présente Licence. De même, les parties qui auront reçu de votre part des copies ou des droits sous
couvert de la présente Licence ne verront pas leurs licences révoquées tant que ces parties demeureront en pleine conformité avec la présente Licence.
10. RÉVISIONS FUTURES DE LA PRÉSENTE LICENCE
La Free Software Foundation (« fondation du logiciel libre ») peut publier de nouvelles versions révisées de la présente GNU Free Documentation License de temps à autre. Ces nouvelles versions seront similaires,
dans l'esprit, à la présente version, mais peuvent différer dans le détail pour prendre en compte de nouveaux problèmes ou de nouvelles inquiétudes. Consultez http://www.gnu.org/copyleft/.
Chaque version de la Licence est publiée avec un numéro de version distinctif. Si le Document précise qu'une version particulière de la présente Licence, « ou toute version postérieure » s'applique, vous avez la
possibilité de suivre les termes et les conditions aussi bien de la version spécifiée que de toute version publiée ultérieurement (pas en tant que brouillon) par la Free Software Foundation. Si le Document ne spécifie
pas un numéro de version de la présente Licence, vous pouvez choisir d'y appliquer toute version publiée (pas en tant que brouillon) par la Free Software Foundation.
METHODES DE PROGRAMMATIONS Licence de Documentation Libre Page 171

Cours Methodes de Programmations

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cours Methodes de Programmations

Uploaded by

Copyright:

Available Formats

Nombre de pages : 171

Mise à jours 28 janvier 2001 Révision : 2.690

Il est autorisé de copier, distribuer et/ou modifier ce document

METHODES DE PROGRAMMATIONS Page 2

Table de mises à jours

Version Date Commentaires

METHODES DE PROGRAMMATIONS Table de mises à jours Page 3

1. COURS : INTRODUCTION AUX METHODES DE

METHODES DE PROGRAMMATIONS SOMMAIRE Page 4

1.2.8.1. / Les interruptions d’horloge interne ..........................................................................................................45

METHODES DE PROGRAMMATIONS SOMMAIRE Page 5

1.4.4.3. / Communication par Rendez-vous.............................................................................................................95

METHODES DE PROGRAMMATIONS SOMMAIRE Page 6

1.6.2.4.2. / Le multiplexeur par octet ...................................................................................................................126

2. TRAVAUX DIRIGES ..................................................................................143

2.1. / EXERCICE 1 : LA GESTION DES LISTES DE TACHES D’UN SYSTEME TR........................................................................144

METHODES DE PROGRAMMATIONS SOMMAIRE Page 7

5. LICENCE DE DOCUMENTATION LIBRE ..............................................................................................................170

METHODES DE PROGRAMMATIONS SOMMAIRE Page 8

1. COURS : Introduction aux méthodes de

METHODES DE PROGRAMMATIONS COURS Page 9

1.1. / PRESENTATION GENERALE

· Les programmes systèmes : développés par le constructeur de l’ordinateur ou le concepteur du

Du point de vue de l’utilisateur, le système d’exploitation fournit l’environnement destiné à faciliter le

METHODES DE PROGRAMMATIONS COURS Page 10

1.1.2. / LE ROLE D’UN SYSTEME D’EXPLOITATION

Figure 1.1 Découpage en niveau d’un système informatique

· Réduire et dominer la complexité des machines,

· Paire en sorte que les possibilités de la machine soient utilisées au mieux.

METHODES DE PROGRAMMATIONS COURS Page 11

· Préserver les investissements,

1.1.3. / LES FONCTIONS D’UN SYSTEME D’EXPLOITATION

- Gestion et ordonnancement des tâches,

- Gestion de la mémoire centrale,

- Gestion des interruptions,

- Gestion des périphériques,

- Gestion des fichiers,

- Traitement des erreurs et reprise,

- Gestion des programmes,

- Gestion des travaux,

METHODES DE PROGRAMMATIONS COURS Page 12

1.1.4.1./ Première génération (1945-1955) tubes à vides et panneaux de raccordement

METHODES DE PROGRAMMATIONS COURS Page 13

Ainsi, le premier ordinateur, le FERRANTI MARK 1, successeur de la machine de Manchester, fut

1.1.4.2./ Deuxième génération (1955-1965) Transistors et systèmes par lots

METHODES DE PROGRAMMATIONS COURS Page 14

Figure 1.2 : Principe du traitement par lots

Figure 1.3: Principe du traitement par lot

METHODES DE PROGRAMMATIONS COURS Page 15

1.1.4.3./ Troisième génération (1965-1980) Circuits intégrés et multiprogrammation

Le concept de la multiprogrammation (multiprogramning) consiste à utiliser les temps morts de

METHODES DE PROGRAMMATIONS COURS Page 16

Le concept du spooling (Simultaneous Peripherical Operation On Line) est né du besoin de supprimer

METHODES DE PROGRAMMATIONS COURS Page 17

1.1.4.4./ Quatrième génération (1980-1990) Ordinateurs personnels

METHODES DE PROGRAMMATIONS COURS Page 18

METHODES DE PROGRAMMATIONS COURS Page 19

1.1.4.5./ Génération multimédia (1990-à nos jours)

METHODES DE PROGRAMMATIONS COURS Page 20

Les innovations principales concernèrent alors l’interface de communication entre l’utilisateur et la

Le concept d’interaction homme-machine développé alors est la métaphore du bureau (desktop). La

METHODES DE PROGRAMMATIONS COURS Page 21

Le système WINDOWS 95, réalise le mariage attendu du système d’exploitation MS-DOS et de

METHODES DE PROGRAMMATIONS COURS Page 22