Vous êtes sur la page 1sur 84

Support de cours syst`eme d’exploitation

J. Gispert, J. Guizol, J.L. Massat

D´epartement d’informatique Facult´e de Luminy 163, Avenue de Luminy, Case 901, 13288 Marseille, cedex 9

23 f´evrier 2012

Chapitre 1 Organisation d’un syst`eme d’exploitation

1.1 Fonctionnalit´es d’un syst`eme informatique

En se limitant au seul point de vue d’un utilisateur d’un syst`eme informatique, les fonctions devant ˆetre assur´ees par celui-ci peuvent ˆetre r´esum´ees de la fa¸con suivante :

Gestion et conservation de l’information. Le syst`eme informatique doit permettre `a tout utilisateur de cr´eer, conserver, retrouver ou d´etruire les objets sur lesquels celui-ci d´esire ef- fectuer des op´erations.

Pr´eparation, mise au point et exploitation de programmes.

Logiciel d'application

Logiciel de base

Machine physique

d'application Logiciel de base Machine physique Outils & Services Système d'exploitation Fig.
d'application Logiciel de base Machine physique Outils & Services Système d'exploitation Fig.

Outils & Services

Système d'exploitation

Fig. 1.1 – Structure logicielle d’un syst`eme informatique

La figure ?? pr´ecise l’organisation logicielle d’un syst`eme informatique avec d’une part le logiciel d’application (traitement de textes, gestionnaire de bases de donn´ees, compilateurs, etc.) et d’autres part le logiciel de base livr´e avec la machine.

1.1.1 Fonctions d’un syst`eme d’exploitation

Le syst`eme d’exploitation est un des ´el´ements clef d’un syst`eme informatique. Il reprend `a son compte les deux fonctions pr´ec´edentes en y ajoutant des nouvelles fonctions li´ees `a la bonne gestion de la machine physique :

Structuration de l’information (sous forme de fichiers) en vue de sa conservation et de sa modification.

Transfert des donn´ees entre les ´el´ements constituants du syst`eme informatique (unit´e cen- trale, p´eriph´eriques d’impression ou de lecture, modem, etc.).

Gestion de l’ensemble des ressources pour offrir `a tout utilisateur un environnement n´ecessaire `a l’ex´ecution d’un travail.

1

2

Gestion du partage des ressources. Le syst`eme doit r´epartir les ressources dont il dis- pose entre les divers usagers en respectant la r`egle d’´equit´e et en empˆechant la famine. En particulier, il doit r´ealiser un ordonnancement des travaux qui lui sont soumis et ´eviter les interblocages.

Extension de la machine hˆote. Le rˆole du syst`eme est ici de simuler une machine ayant des caract´eristiques diff´erentes de celles de la machine r´eelle sur laquelle il est implant´e. Chaque utilisateur dispose alors d’une machine virtuelle munie d’un langage ´etendu permettant l’ex´ecution et la mise au point des programmes au moyen d’outils plus facilement utilisables que ceux dont est dot´ee la machine cˆabl´ee.

1.1.2 Aspects externes

La diversit´e des tˆaches `a remplir et des mat´eriels utilis´es a pour cons´equence une grande vari´et´e des aspects externes des syst`emes :

– les syst`emes destin´es `a la conduite de processus industriels (chimie industrielle, cracking, central t´el´ephonique, guidage de fus´ee, surveillance m´edicale ou monitoring , etc.) ;

– les syst`emes g´erant les bases de donn´ees (r´eservations de places, gestion de stock, gestion de comptes bancaires, documentation automatique, etc.) ;

– les syst`emes destin´es `a la cr´eation et l’ex´ecution de programmes qui peuvent ˆetre subdivis´es en plusieurs classes selon :

– le degr´e d’interaction entre l’utilisateur et ses programmes (traitement par trains ou conversationnel) ;

– le mode de partage des ressources (mono ou multiprogrammation) ;

– les possibilit´es offertes par le langage ´etendu (acc`es `a un ou plusieurs langages) ;

Malgr´e cette grande diversit´e, les syst`emes comportent entre eux des parties tr`es ressemblantes, voire identiques, et il serait donc tr`es utile de pouvoir d´egager celles-ci afin de profiter de certaines ´etudes partielles dans l’´elaboration de portions plus complexes. C’est ce souci de rentabilisation qui a conduit `a une conception modulaire des syst`emes et de leurs diff´erents constituants, technique g´en´eralisable `a tout logiciel d´evelopp´e sur une machine quelconque.

1.2 Structure interne des syst`emes d’exploitation

1.2.1 Conception descendante et structures en couches

Dans cette section, le terme de langage sera utilis´e dans le sens suivant : un langage d´efinit des objets (et les m´ecanismes permettant de les cr´eer), des actions (ou primitives) permettant de manipuler ces objets et des r`egles de composition de ces actions. En particulier, tout langage d´efinit une machine capable de l’interpr´eter : les instructions de cette machine repr´esentent l’ensemble des primitives du langage, sa m´emoire permet de repr´esenter les objets et son m´ecanisme d’ex´ecution est celui d´efini par les r`egles d’interpr´etation du langage. D´esirant r´esoudre un probl`eme, une d´emarche habituelle consiste `a d´ecomposer celui-ci en une succession de plusieurs sous-probl`emes que l’on esp`ere r´esoudre plus ais´ement. On essaie donc dans un premier temps de d´efinir une machine M 0 dont les primitives rendront la r´esolution du probl`eme plus facile. Le probl`eme initial (suppos´e r´esolu par la machine M 0 ) se transforme donc en la r´ealisation de cette machine M 0 sur la machine disponible M . On va alors d´efinir pour cela une machine M 1 , etc. jusqu’`a l’obtention d’une machine M n facilement r´ealisable sur M .

3

La puissance de cette m´ethode ne r´eside pas dans la seule simplification du probl`eme `a chaque niveau, mais r´esulte aussi du processus d’abstraction consistant `a focaliser l’´etude sur les aspects essentiels du probl`eme, concr´etis´es par la sp´ecification d’une machine, c’est `a dire, en fait, celle de son interface. Lorsque la r´ealisation d’une machine M i utilise l’interface d’une machine M j , on dit que M i d´epend de M j . En fait, cette relation de d´ependance ne porte que sur l’interface et non sur la r´ealisation interne. On peut alors d´ecrire la structure d’un syst`eme par un graphe dont les nœuds repr´esentent les machines, et les arcs, les relations de d´ependance. Dans la figure ??, le sch´ema (a) repr´esente la structure r´esultant de la m´ethode de concep- tion descendante. Celui-ci peut ˆetre g´en´eralis´e en (b) si l’on autorise chaque machine `a utiliser les primitives de toute autre machine de niveau inf´erieur. Enfin, si la seule contrainte est d’avoir un graphe sans circuit, on obtient le sch´ema (c) o`u les machines sont class´ees par niveau d’abstraction, chacune d’elles n’utilisant que les machines de niveau inf´erieur.

M0

M1 M2
M1
M2
M3 (a)
M3
(a)
M0 M0 M1 M1 M2 M2 M3 M4 M3 M5 (b) (c)
M0
M0
M1
M1
M2
M2
M3
M4
M3
M5
(b)
(c)

Fig. 1.2 – D´ecomposition hi´erarchique

En r´ealit´e, la m´ethode de conception descendante est rarement utilisable `a l’´etat pur. Plusieurs facteurs sont `a prendre en consid´eration : l’exp´erience du concepteur, l’existence de machines d´ej`a r´ealis´ees, la difficult´e de fixer `a l’avance les sp´ecifications d´etaill´ees des interfaces, qui utilisent en fait le r´esultat d’exp´erimentation sur des r´ealisations partielles. En tout ´etat de cause, l’ind´ependance introduite par l’abstraction procure `a la structure hi´erarchique par niveau plusieurs avantages :

Ind´ependance pour la conception. Description totale du comportement d’une machine par les sp´ecifications de son interface.

Ind´ependance pour la modification. Les modifications dans la r´ealisation d’une machine n’alt`erent en rien celles qui l’utilisent si les sp´ecifications d’interface demeurent inchang´ees.

Ind´ependance pour la mise au point. Son interface ayant ´et´e sp´ecifi´ee, une machine M peut ˆetre mise au point ind´ependamment de celles qui l’utilisent ; r´eciproquement, une machine M ´etant r´ealis´ee, les machines utilisant M peuvent ˆetre mises au point ind´ependamment de

M.

1.2.2 Notion d’objet

La d´ecomposition hi´erarchique que l’on vient de pr´esenter r´epond mal `a certains aspects de structuration des syst`emes. En particulier, la description de collections d’´el´ements ayant des ca- ract´eristiques communes, la cr´eation ou la destruction dynamique d’´el´ements seront facilit´ees grˆace

4

`a la notion d’objet, nouvel outil de structuration permettant d’exprimer des concepts importants tels que : d´esignation, liaison, type, protection. Un objet est concr´etis´e par une repr´esentation : repr´esentation externe `a laquelle a acc`es l’utili- sateur et repr´esentation interne qui est celle concernant le syst`eme. Cette repr´esentation des objets ainsi que la fa¸con d’y acc´eder font appel `a des fonctions d’acc`es. Un autre concept permet de regrouper un ensemble d’objets ayant des caract´eristiques com- munes : c’est la notion de classe. Les op´erations et fonctions d’acc`es associ´ees `a une classe sont applicables `a chaque objet de la classe. Il peut advenir que l’on d´esire d´efinir des ensembles d’objets

ayant `a la fois des propri´et´es communes avec une classe d´ej`a existante et des propri´et´es particuli`eres.

La notion de sous-classe permet d’y parvenir.

Une sous-classe h´erite des propri´et´es associ´ees `a la classe m`ere, auxquelles s’ajoutent des pro- pri´et´es sp´ecifiques. Cette sous-classe pourra `a son tour ˆetre consid´er´ee comme classe m`ere d’un autre ensemble, etc. On obtient ainsi une hi´erarchie de classes. Citons quelques classes bien connues, et la ressource physique associ´ee dont elles constituent une abstraction :

– les fichiers m´emoire secondaire,

– les flots organes p´eriph´eriques,

– les processus processeur,

– la m´emoire virtuelle m´emoire physique.

Les fonctions d’acc`es associ´ees `a une classe quelconque permettent, entre autre, de cr´eer ou de supprimer des objets de cette classe et donc d’en faire varier dynamiquement le nombre. Une fois cr´e´e, un objet dispose d’un ´etat repr´esent´e par ses propres donn´ees qui peuvent varier dans le temps.

1.2.3 Interfaces et sp´ecifications

Comme nous l’avons vu dans les deux paragraphes pr´ec´edents, une interface est associ´ee, soit `a une machine abstraite, soit `a une classe d’objets. Elle comporte trois types d’information :

– des structures de donn´ees ;

– des proc´edures ;

– des r`egles d’utilisation des donn´ees et proc´edures exprimant des restrictions :

– restrictions d’acc`es aux donn´ees (lecture seule autoris´ee

– restrictions sur l’ordre des proc´edures ;

)

;

– contraintes de simultan´eit´e dans l’ex´ecution des proc´edures ou l’acc`es aux donn´ees.

A l’heure actuelle, aucune solution satisfaisante n’a encore ´et´e propos´ee pour exprimer les

sp´ecifications d’une interface ou les contraintes d’utilisation, si ce n’est le recours au langage naturel. Deux m´ethodes sont utilis´ees pour prendre en compte, dans la sp´ecification, les ´eventuelles erreurs :

– Chaque proc´edure comporte un param`etre suppl´ementaire (code d’erreur) modifiable par la proc´edure. La valeur finale de cette variable constitue un compte-rendu interpr´etable `a un niveau sup´erieur.

– A chaque cause d’erreur est associ´ee une proc´edure de traitement sp´ecifique. En cas d’erreur, un m´ecanisme que nous d´etaillerons ult´erieurement (d´eroutement), d´eclenche automatique- ment la proc´edure correspondante.

5

Dans tous les cas, le traitement d’une erreur consistera `a revenir `a un ´etat stable du syst`eme o`u l’ex´ecution puisse reprendre normalement, en perdant le moins d’information possible. Des deux m´ethodes de prise en compte d’erreur pr´esent´ees plus haut, la seconde n´ecessite un m´ecanisme suppl´ementaire, mais elle sera pr´ef´erable `a la premi`ere pour deux raisons essentielles :

S´ecurit´e : le caract`ere syst´ematique de d´eroutement en cas d’erreur est sup´erieur au test de code qui peut ˆetre omis, provoquant ainsi une propagation d’erreur.

Clart´e : le fait de pouvoir associer une proc´edure particuli`ere `a chaque cause d’erreur per- met de s´eparer clairement le traitement des situations normales de celui des situations exceptionnelles .

Les m´ethodes de conception que nous venons de pr´esenter et les concepts ou outils d’abstraction qui leur sont associ´es permettent, on l’a vu, grˆace `a la modularit´e ainsi acquise, de diviser et subdiviser un syst`eme informatique en plusieurs parties ind´ependamment modifiables ou mˆeme interchangeables. Cet aspect s’av`ere primordial, car les syst`emes ´elabor´es `a l’heure actuelle sont de plus en plus importants et de plus en plus complexes. Si bien que leur r´ealisation est confi´ee `a plusieurs personnes, `a divers services, voire `a plusieurs ´equipes. La coh´erence du tout ne peut ˆetre facilement obtenue qu’`a la condition d’avoir pr´ealablement clairement d´efini les sp´ecifications d’interface et l’arborescence

des classes d’objets manipul´es,

D’autre part, certaines portions du syst`eme peuvent ˆetre con¸cues de diff´erentes fa¸cons en utilisant diff´erentes strat´egies. Dans ces conditions, les concepteurs devront tester celles-ci sur des crit`eres

de rapidit´e, d’optimisation d’occupation, d’utilisation de ressources, etc. Le respect des contraintes d’interfa¸cage autorisera la mise au point et l’´evaluation de performance de ces parties par simple substitution sans affecter le reste du syst`eme. A propos de ce cas de figure, les contraintes s’av`erent tr`es strictes, la substitution d’un module par un autre module n’´etant possible qu’`a la condition que les autres modules n’y acc`edent qu’en utilisant son interface. En particulier, un programme appelant un module ne devra en aucune fa¸con exploiter des renseignements sur la r´ealisation interne du module. Une m´ethode efficace pour parvenir `a ce but a ´et´e propos´ee par Parnas : laisser les programmeurs d’un module dans l’ignorance de la r´ealisation des autres.

mais seulement cela.

1.2.4 Les composantes d’un S.E.

L’´etude des composantes permet de fixer les rˆoles de chaque couche logicielle et les rapports entre ces couches. Nous allons par la suite distinguer les modules suivants (voir la figure ??) :

– Le gestionnaire d’interruptions r´ecup`ere les interruptions mat´erielles et logicielles et applique le traitement appropri´e qui varie sur la cause de ces interruptions.

– Les pilotes de p´eriph´eriques (drivers) g`erent l’´echange des donn´ees avec les p´eriph´eriques. Chaque pilote connaˆıt son p´eriph´erique et cache son mode d’utilisation aux couches sup´erieures du syst`eme. Ces drivers utilisent les interruptions car le dialogue asynchrone entre CPU et unit´es externes s’effectue au moyen des interruptions. En d’autres termes, le pilote envoie des ordres `a son p´eriph´erique qui r´epond au bout d’un temps non d´efini par le biais d’une interruption.

– Le syst`eme d’E/S masque les drivers de p´eriph´eriques. Il offre des fonctions d’E/S qui, bien qu’´etant de bas niveau, ne distinguent pas de mani`ere explicite la nature du p´eriph´erique. Ces E/S sont r´ealis´ees `a partir (ou vers) des zones de la m´emoire appel´es des tampons (buffer). L’allocation de ces tampons passe donc par le gestionnaire de la m´emoire centrale.

6

– La gestion de la m´emoire centrale r´epond aux demandes d’allocation et de lib´eration de zones m´emoire. Dans une premi`ere approche, la m´emoire virtuelle peut ˆetre vue comme une extension de la m´emoire centrale qui est temporairement rang´ee sur disque. Ce d´eplacement d’une partie de la m´emoire implique :

– le retour `a la demande des informations utiles et non pr´esentes en m´emoire centrale (c’est une op´eration d’E/S) ;

– la sauvegarde sur disque des informations pr´esentes mais inutilis´ees.

– Le syst`eme de gestion des fichiers (SGF) offre toutes les primitives n´ecessaires `a la cr´eation, destruction, modification des fichiers se trouvant en m´emoire secondaire.

– La gestion des processus r´epartit la ou les CPU entre les tˆaches qui en ont besoin. Ces tˆaches consomment de la m´emoire et exploitent des fichiers.

– Les processus utilisateur (dont les interpr´eteurs de commande sont un exemple particulier) utilisent le S.E. en lui adressant des requˆetes en bonne et due forme. Ces requˆetes permettent, au choix :

– de lancer, de figer ou de tuer d’autres processus,

– d’exploiter ou de modifier des fichiers,

– d’allouer de la m´emoire, etc.

processus utilisateur

interpréteur de commandes

interface d'appel au système (SVC)etc. processus utilisateur interpréteur de commandes Gestion des processus Gestion des fichiers Gestion de la

de commandes interface d'appel au système (SVC) Gestion des processus Gestion des fichiers Gestion de la
de commandes interface d'appel au système (SVC) Gestion des processus Gestion des fichiers Gestion de la
de commandes interface d'appel au système (SVC) Gestion des processus Gestion des fichiers Gestion de la

Gestion des processus

Gestion des fichiers

au système (SVC) Gestion des processus Gestion des fichiers Gestion de la mémoire centrale Gestion du
au système (SVC) Gestion des processus Gestion des fichiers Gestion de la mémoire centrale Gestion du
au système (SVC) Gestion des processus Gestion des fichiers Gestion de la mémoire centrale Gestion du

Gestion de la mémoire centrale

Gestion des fichiers Gestion de la mémoire centrale Gestion du système d'E/S Gestion des interruptions «

Gestion du système d'E/S

de la mémoire centrale Gestion du système d'E/S Gestion des interruptions « Drivers » de périphériques
de la mémoire centrale Gestion du système d'E/S Gestion des interruptions « Drivers » de périphériques

Gestion des interruptions

Gestion du système d'E/S Gestion des interruptions « Drivers » de périphériques interface vers le matériel

« Drivers » de périphériques

Gestion des interruptions « Drivers » de périphériques interface vers le matériel Machine physique Fig. 1.3

interface vers le matériel

« Drivers » de périphériques interface vers le matériel Machine physique Fig. 1.3 – Les composantes
« Drivers » de périphériques interface vers le matériel Machine physique Fig. 1.3 – Les composantes

Machine physique

Fig. 1.3 – Les composantes et la structure d’un syst`eme

1.3 Historique des syst`emes d’exploitation

L’historique est un moyen agr´eable de pr´esenter les principaux concepts en partant de l’absence de S.E. pour arriver aux syst`emes r´epartis.

7

1.3.1 Syst`emes monoprogramm´es

Sur les premiers ordinateurs il n’existe pas de S.E. `a proprement parler. L’exploitation de la machine est confi´ee `a tour de rˆole aux utilisateurs ; chacun disposant d’une p´eriode de temps fixe. C’est une organisation en porte ouverte. Au d´ebut des ann´ees 50, on voit apparaˆıtre le premier programme dont le but est de g´erer la machine : c’est le moniteur d’enchaˆınement des tˆaches. Cet embryon de S.E. a la charge d’enchaˆıner l’ex´ecution des programmes pour am´eliorer l’utilisation de l’unit´e centrale (U.C.). Il assure ´egalement des fonctions de protection (vis `a vis du programme en cours d’ex´ecution), de limitation de dur´ee et de supervision des entr´ees/sorties. Pour r´ealiser ces op´erations, le moniteur est toujours pr´esent en m´emoire. Il est dit r´esident. La fin des ann´ees 50 marque le d´ebut du traitement par lots (batch processing). Une machine pr´epare les donn´ees en entr´ee (lecture des cartes perfor´ees `a cette ´epoque) tandis que la machine principale effectue le travail et qu’une troisi`eme produit le r´esultat. Il existe donc un parall´elisme des tˆaches entre lecture, ex´ecution et impression. Les op´erations d’E/S ne sont plus r´ealis´ees par la CPU, ce qui lib`ere du temps de calcul.

1.3.2 Syst`emes multiprogramm´es

La multiprogrammation arrive au d´ebut des ann´ees 60. Elle est caract´eris´ee par la pr´esence simultan´ee en m´emoire de plusieurs programmes sans compter le S.E. lui-mˆeme. Cette caract´eristique s’explique de la mani`ere suivante : l’ex´ecution d’un programme peut ˆetre vue comme une suite d’´etapes de calcul (les cycles d’U.C.) et d’´etapes d’E/S (les cycles d’E/S) comme le montre la figure ??. Sur un syst`eme monoprogramm´e, la CPU est donc inutilis´ee durant les cycles d’E/S. L’id´ee de base est d’utiliser ces temps d’attente pour ex´ecuter un autre programme. Ce pro- gramme doit n´ecessairement ˆetre d´ej`a pr´esent en m´emoire afin d’´eviter l’E/S de chargement puisque justement on cherche `a utiliser les temps morts d’E/S. La r´ealisation pratique de cette id´ee n´ecessite :

– des unit´es mat´erielles capables d’effectuer des E/S de mani`ere autonome (lib´erant ainsi la C.P.U pour d’autres tˆaches) ;

– des possibilit´es mat´erielles li´ees `a la protection de la m´emoire et/ou `a la r´eimplantation du code pour ´eviter qu’une erreur d’un programme influence le d´eroulement d’un autre.

C.P.U.

Unité d'E/S

attente
attente
d´eroulement d’un autre. C.P.U. Unité d'E/S attente début fin début fin d'E/S d'E/S
d´eroulement d’un autre. C.P.U. Unité d'E/S attente début fin début fin d'E/S d'E/S

début

fin

début

fin

d'E/S

d'E/S

d'E/S

d'E/S

Fig. 1.4 – Cycles de CPU et cycles d’E/S

Dans les ann´ees 60/70 les premiers syst`emes en temps partag´e (time sharing) sont disponibles. Ces syst`emes sont directement li´es `a l’utilisation interactive des machines au moyen de terminaux vid´eo. Ce mode d’utilisation impose un temps de r´eponse acceptable puisque les utilisateurs attendent devant leur terminaux. Pour garantir un bon temps de r´eponse moyen, le temps d’ex´ecution de la CPU est d´ecoup´e en tranches appel´ees des quanta. Ces quanta sont allou´ees aux programmes en cours d’activit´e. Le temps d’ex´ecution de la CPU est donc partag´e entre les programmes utilisateurs. Si le nombre d’utilisateurs n’est pas trop important et, sachant qu’un utilisateur moyen passe 90% de son temps `a r´efl´echir et seulement 10% `a ex´ecuter une action, le temps de r´eponse reste

8

acceptable et chaque utilisateur `a l’impression d’avoir sa propre machine. Sur un plan mat´eriel, le temps partag´e est bas´e sur les possibilit´es suivantes :

– les programmes sont tous en m´emoire ; le temps partag´e implique donc la multiprogrammation ;

– le mat´eriel doit permettre l’interruption d’un programme au bout de son quanta de temps pour passer la CPU `a autre programme ;

– les temps de commutation d’un programme vers un autre doit ˆetre aussi faible que possible car durant cette ´etape la CPU est utilis´ee par le S.E. au d´etriment des programmes utilisateurs.

Les syst`emes r´epartis se d´eveloppent durant les ann´ees 80. Dans cette organisation, les donn´ees mais aussi les programmes sont r´eparties sur plusieurs machines connect´ees par un r´eseau. Les probl`emes sont plus complexes puisqu’ils couvrent la communication, la synchronisation et la collaboration

entre ces machines, mais ceci est une autre histoire

et un autre cours.

1950

1960

1970

1980

Gros

ordinateurs

Mini

ordinateurs

pas de

traitement

multi-

systèmes

répartis

logiciels

par lots

utilisateurs

moniteurs

temps

compilateurs

partagé

 

pas de

temps

multi-

logiciels

partagé

utilisateurs

moniteurs

compilateurs

Les Micros

pas de

compilateurs

compilateurs

moniteurs

multi-

utilisateurs

et

temps

partagé

Fig. 1.5 – ´evolution des syst`emes d’exploitation ([SG94])

1.4 Exemples de syst`emes d’exploitation

1.4.1 Ordinateur individuel

Toute configuration de base d’un ordinateur individuel comporte une unit´e centrale et un ter- minal (´ecran, clavier et ´eventuellement souris ). En g´en´eral, cet ensemble est augment´e d’une m´emoire secondaire (disque dur) et d’une imprimante. L’utilisateur potentiel attend de ce syst`eme principalement deux types de services :

– cr´eer et nommer des fichiers ; pouvoir les conserver en m´emoire secondaire ; transf´erer de l’information entre les fichiers et les organes d’entr´ees-sorties (clavier, imprimante, ´ecran) ;

– ex´ecuter des programmes qui peuvent ˆetre livr´es avec le syst`eme ou cr´e´es et introduits sous forme de fichiers ; les donn´ees sont introduites au clavier ou lues dans des fichiers ; les r´esultats sont affich´es `a l’´ecran, list´es sur l’imprimante ou encore stock´es dans des fichiers.

9

Ce genre de syst`eme ´etant utilis´e par un seul usager, la notion de partage de ressources est absente. L’allocation des ressources intervient pour la gestion de la m´emoire et de l’espace disque. Pour ce type de syst`eme, les qualit´es essentielles requises sont :

– la fiabilit´e ;

– l’efficacit´e (les performances de la machine support ´etant souvent limit´ees, il importe de les utiliser au mieux) ;

– la simplicit´e d’utilisation (Macintosh de Apple) ;

– la facilit´e d’extension par adjonction de nouveaux programmes utilitaires ou adaptation `a des nouveaux p´eriph´eriques.

Ces deux derniers aspects mettent en ´evidence l’importance de la conception des interfaces, tant au niveau du langage de commande qu’`a celui du syst`eme de gestion de fichiers.

1.4.2 Commande de proc´ed´es industriels

Imaginons que dans une usine de produits chimiques, un produit C soit synth´etis´e `a partir de deux produits A et B. Le r´eacteur peut ˆetre sch´ematis´e comme suit. Le calculateur charg´e de conduire le processus de fabrication doit assurer trois fonctions : r´egulation, enregistrement et s´ecurit´e.

vannes

A Réacteur B
A
Réacteur
B
C
C

capteurs

signaux

de mesure

vannes A Réacteur B C capteurs signaux de mesure Ordinateur signaux de commande Fig. 1.6 –
Ordinateur
Ordinateur
Ordinateur
Ordinateur
Ordinateur
Ordinateur
Ordinateur

Ordinateur

Ordinateur

signaux de commande

Fig. 1.6 – Conduite d’un r´eacteur chimique

R´egulation. Les divers param`etres de fonctionnement (temp´erature, concentration, pression) doivent ˆetre maintenues dans des limites fix´ees pour la bonne marche de la fabrication. Pour cela on doit agir sur les vannes A et B, sur l’alimentation de r´esistances de chauffage, d’un agitateur, etc. Tous les param`etres sont mesur´es `a chaque instant par un ensemble de capteurs dispos´es dans la cuve ; l’ordinateur pr´el`eve ces mesures, les interpr`ete et agit en cons´equence sur les organes concern´es selon un programme de r´egulation.

Enregistrement. Les mesures effectu´ees par les divers capteurs sont p´eriodiquement enre- gistr´ees ; leur valeur est affich´ee sur un tableau de bord surveill´e par un responsable et stock´ee dans un fichier ( journal ) en vue d’un traitement ult´erieur (statistiques d’exploitation).

10

S´ecurit´e. Il y a arrˆet d’urgence du r´eacteur si certaines valeurs pr´elev´ees d´epassent certains seuils pr´e-d´efinis.

Le mode de fonctionnement pr´ec´edemment d´ecrit impose des contraintes au syst`eme. Le temps n´ecessaire au traitement d’un ensemble de mesures (pr´el`evement, enregistrement, d´etermination et ex´ecution des commandes qui s’imposent) doit ˆetre inf´erieur `a la p´eriode de pr´el`evement ; la fonction de priorit´e doit ˆetre prioritaire sur toutes les autres. Le fait de fixer des limites `a la dur´ee d’un traitement informatique, l’existence d’´ech´eances, la notion de traitement prioritaire et la connexion aux organes de commande et de mesure d’un dispositif ext´erieur sont caract´eristiques des applications dites en temps r´eel. Pour ces syst`emes, la qualit´e principale est la fiabilit´e. Les cons´equences d’une d´efaillance pouvant ˆetre catastrophiques (centrale nucl´eaire), le syst`eme doit ˆetre en mesure d’assurer `a chaque instant la s´ecurit´e du processus qu’il pilote, et en particulier, assurer un service minimal en cas de d´efaillance du mat´eriel, d’´ev´enement accidentel (s´eisme) ou d’erreur humaine.

1.4.3 Syst`emes transactionnels

Ces syst`emes sont caract´eris´es par les propri´et´es suivantes :

– l’ensemble des informations g´er´ees peut atteindre une taille importante (milliards d’octets) ;

– Sur ces informations peuvent ˆetre ex´ecut´ees un certain nombre d’op´erations pr´e-d´efinies, ou transactions, souvent interactives ;

– Le syst`eme poss`ede un grand nombre de points d’acc`es (terminaux) et un grand nombre de transactions peuvent se d´erouler en mˆeme temps.

Les exemples types d’applications de ce genre sont les syst`emes de r´eservation de places de train ou d’avion, de gestion de comptes bancaires, de consultation ou de documentation. L`a encore une des principales qualit´es requises du syst`eme est la fiabilit´e (int´egrit´e et coh´erence des donn´ees). Un tel syst`eme doit en outre poss´eder des qualit´es de disponibilit´e et des capacit´es de tol´erance aux pannes.

1.4.4 Syst`emes en temps partag´e

Le rˆole d’un syst`eme en temps partag´e est de fournir ses services `a un ensemble d’usagers, chacun b´en´eficiant de services ´equivalents `a ceux accessibles sur une machine individuelle, mais aussi de services li´es `a l’existence d’une communaut´e d’usagers (partage d’information, communi- cation entre usagers). De plus, les coˆuts ´etant r´epartis entre un grand nombre d’usagers, ceux-ci peuvent b´en´eficier de services qui leur seraient inaccessibles individuellement (p´eriph´eriques sp´eciaux ou logiciels n´ecessitant un grand espace m´emoire). Les probl`emes rencontr´es sont donc `a la fois ceux des ordinateurs individuels et ceux des syst`emes transactionnels : d´efinition de la machine virtuelle pour chaque usager ; partage et allocation des ressources physiques communes (processeurs, m´emoires, organes de communication) ; gestion de l’information partag´ee (fichiers) et des communications. Les qualit´es attendues sont : disponibilit´e, fiabilit´e, s´ecurit´e, bonne exploitation des performances du mat´eriel, qualit´e de l’interface et des services offerts `a l’usager, facilit´e d’extension et d’adaptation.

Chapitre 2

Interruptions, d´eroutements et appels syst`eme

2.1 Ex´ecution de programme

Avant de pr´eciser ce que nous entendons par interruption, il est souhaitable de d´efinir rapidement la notion d’ex´ecution d’un programme sur une machine. En fait, notre objectif est de pr´esenter un mod`ele g´en´eral valable sur la plupart des machines. Une machine est compos´ee sch´ematiquement d’un processeur (aussi appel´ee la C.P.U.), d’une m´emoire principale et d’organes d’E/S. Le processeur est un circuit actif qui comporte des registres g´en´eraux et des registres sp´ecialis´es. L’ensemble des registres sp´ecialis´es forment le mot d’´etat du processeur (M.E.P. ou P.S.W. pour Processor Status Word ). Parmi ces registres on trouve :

– le compteur ordinal (CO) qui contient l’adresse de la prochaine instruction `a ex´ecuter ;

– le mode d’ex´ecution (MODE) qui peut ˆetre maˆıtre ou esclave ;

– Le masque d’interruptions que nous d´etaillerons plus tard.

– Un ou plusieurs pointeur(s) de pile.

etc.

La notion de mode a ´et´e introduite essentiellement pour des raisons de protection, afin qu’un programme quelconque ne puisse acc´eder `a des zones ou `a des registres propres au S.E. Dans la pratique, la CPU distingue les instructions normales et les instructions privil´egi´ees. Ces derni`eres ne sont utilisables qu’en mode maˆıtre. Elles permettent en g´en´eral la modification des registres sp´ecialis´es et le dialogue avec les unit´es d’E/S. Partons du principe que le S.E. s’ex´ecute en mode maˆıtre et que les programmes utilisateur s’ex´ecutent en mode esclave. La programmation directe des E/S est donc r´eserv´ee au S.E. et les E/S des programmes utilisateurs devront passer par des requˆetes au S.E. Nous d´evelopperons ce point `a la section ??. Une ex´ecution est une ´evolution discr`ete de l’´etat de la machine. Cet ´etat est donn´e par le contenu de la m´emoire et la valeur des registres de la CPU. Nous sommes donc capables d’observer l’´evolution d’une machine mais seulement sur certains points que nous appellerons les points obser- vables ou points interruptibles. Ces points sont situ´es dans le temps `a la fin de l’ex´ecution d’une instruction de la CPU. Le sch´ema ?? d´ecrit sommairement l’´evolution des registres d’une C.P.U. simplifi´ee lors de l’ex´ecution d’un programme.

11

12

Exécution

Code en cours d'exécution

123

124

125

126

12 Exécution Code en cours d'exécution 123 124 125 126 LOAD R1, #10 INC R1 ADD

LOAD R1,

#10

INC R1 ADD R1, R2

123 124 125 126 LOAD R1, #10 INC R1 ADD R1, R2 Evolution des registres de

Evolution des registres de la C.P.U.

CO

R1

R2

123

-

34

LOAD R1, #10

125

10

34

INC R1

126

11

34

ADD R1, R2

127

45

34

LOAD R1, #10 125 10 34 INC R1 126 11 34 ADD R1, R2 127 45

Fig. 2.1 – Un exemple d’ex´ecution

2.2 Le m´ecanisme des interruptions

Dans tous les types de syst`eme, il est toujours n´ecessaire de consid´erer un travail courant (le programme en cours d’ex´ecution) et un travail exceptionnel dont le but est de traiter un ´ev´enement. On peut citer les exemples suivants :

– Dans les syst`emes de conduite de processus, certains ´ev´enements importants (voir mˆeme graves) doivent ˆetre pris en compte dans les d´elais les plus brefs. En d’autres termes, il faut donc interrompre le travail courant (relev´es des capteurs), pour ex´ecuter un programme prioritaire.

– Il existe toujours un dialogue entre l’U.C. et les organes d’E/S. Notamment, une unit´e de disque ou une imprimante signalent `a l’U.C. que l’E/S est termin´ee. Dans ce cas ´egalement, le travail courant doit ˆetre interrompu pour prendre en compte cette nouvelle situation de mani`ere `a optimiser l’utilisation des organes d’E/S.

Ces deux exemples ont un point en commun : les ´ev´enements exceptionnels sont asynchrones c’est `a dire qu’il n’est pas possible de pr´evoir leur arriv´ee. Pour contourner ce probl`eme, les machines disposent d’un m´ecanisme g´en´eral permettant de traiter ces ´ev´enements asynchrones. C’est ce m´ecanisme complexe qui vous est pr´esent´e dans cette section. Les interruptions permettent d’interrompre provisoirement le d´eroulement d’un programme en cours pour ex´ecuter une routine consid´er´ee comme prioritaire. On associe `a chaque cause d’interrup- tion un num´ero k qui l’identifie. On dispose ´egalement dans les adresses basses de la m´emoire d’une table appel´ee le vecteur d’interruptions (vi). Les cases vi[k] de cette table contiennent l’adresse de la routine `a ex´ecuter lors d’une interruption de cause k. Cette routine est appel´ee le traitant d’interruption de cause k. Plus pr´ecis´ement, lors d’une interruption de cause k, la CPU effectue d`es la fin de l’instruction en cours les actions suivantes :

1. sauvegarder la valeur du compteur ordinal et le mode d’ex´ecution (dans une pile ou dans une case m´emoire particuli`ere suivant les C.P.U.) ;

13

3. forcer dans le compteur ordinal la valeur vi[k], c’est `a dire l’adresse de la premi`ere instruction de la routine associ´ee `a l’interruption de cause k.

L’interruption est donc un m´ecanisme mat´eriel puisque la sauvegarde et l’initialisation du comp- teur ordinal `a partir du vecteur d’interruptions sont des op´erations r´ealis´ees par la CPU. Le traitant repr´esente la partie logicielle du m´ecanisme d’interruption. Il a (presque) toujours la structure sui- vante :

1. Sauvegarder la valeur des registres de la CPU (dans un emplacement particulier de la m´emoire). Cette ´etape est couramment appel´ee la sauvegarde du contexte.

2. Traiter la cause de l’interruption.

3. Restaurer la valeur des registres de la CPU et le mode du programme interrompu. C’est la restauration du contexte.

4. Forcer dans le compteur ordinal la valeur pr´ealablement sauvegard´ee.

De cette description on tire deux conclusions : (1) les traitants d’interruption s’ex´ecutent en mode maˆıtre (donc avec des droits ´etendus) ; (2) l’ex´ecution du programme interrompu n’est pas perturb´ee par le traitement de l’interruption. L’´etape 4 est souvent r´ealis´ee au moyen d’une instruction de la CPU qui provoque le retour au programme interrompu (RTI). Cette ´etape est appel´ee l’acquittement de l’interruption. Les principales utilisations du processus d’interruption sont les suivantes :

– Interruption logicielle (ou d´eroutement) provoqu´ee par la CPU lors de la d´etection d’une situation anormale . Par exemple :

– appel explicite du S.E.,

– instruction incorrecte ou inconnue,

– violation de privil`ege,

– d´epassement de capacit´e,

– division par z´ero,

– tentative d’acc`es `a une zone prot´eg´ee de la m´emoire.

– Interruption mat´erielle g´en´er´ee par une unit´e externe `a la CPU afin de lui signaler l’apparition d’un ´ev´enement ext´erieur. Par exemple :

– fin d’une E/S,

– impulsion d’horloge,

– changement d’´etat d’un des p´eriph´eriques,

– pr´esence d’une valeur int´eressante sur un capteur.

Certaines CPU n’ont qu’une seule cause d’interruption. Dans ce cas, un ou logique de toutes les causes possibles sera effectu´e et le traitant d’interruption – qui est unique – devra au pr´ealable tester les indicateurs pour connaˆıtre la cause.

2.3 Les interruptions mat´erielles

Les interruptions mat´erielles se pr´esentent comme un ensemble de fils num´erot´es reliant la CPU et les circuits externes de la machine. La pr´esence d’un signal sur un de ces fils provoque une interruption du programme en cours d’ex´ecution. Le num´ero de cette interruption est directement li´e au fil qui l’a d´eclench´ee.

14

En r´esum´e, un circuit ext´erieur g´en`ere une interruption sur la CPU afin de lui signaler un ´ev´enement. Cette interruption stoppe le programme en cours pour lancer une routine du S.E. L’ex´ecution de cette routine permet, dans les meilleurs d´elais, la prise en compte par le S.E. de l’´ev´enement ext´erieur.

2.3.1 Syst`eme hi´erarchis´e d’interruptions

Les fils d’interruptions peuvent ˆetre hi´erarchis´es c’est-`a-dire class´es par ordre de priorit´es respec- tives. Un traitant d’interruption peut donc ˆetre lui-mˆeme interrompu par une demande d’interruption intervenant sur un fil de priorit´e sup´erieure. Il passe alors `a l’´etat d’attente. La figure ?? repr´esente l’activit´e des programmes dans le temps pour un syst`eme hi´erarchis´e `a 8 niveaux o`u le niveau 0 est le plus prioritaire, le niveau 7 correspondant au programme d’arri`ere-plan.

int.

int.

int.

int.

int.

niv 5

niv 4

niv 1

niv 3

niv 0

0

1

2

3

4

5

6

7

niv 5 niv 4 niv 1 niv 3 niv 0 0 1 2 3 4 5
niv 5 niv 4 niv 1 niv 3 niv 0 0 1 2 3 4 5
niv 5 niv 4 niv 1 niv 3 niv 0 0 1 2 3 4 5
niv 5 niv 4 niv 1 niv 3 niv 0 0 1 2 3 4 5
niv 5 niv 4 niv 1 niv 3 niv 0 0 1 2 3 4 5
niv 5 niv 4 niv 1 niv 3 niv 0 0 1 2 3 4 5

prise en compte de l'int. niv 3

Fig. 2.2 – Effet de la hi´erarchisation d’un syst`eme d’interruption

Les syst`emes d’interruption sont quelquefois plus ´elabor´es et sont constitu´es d’un type d’organi- sation tr`es modulaire ayant les caract´eristiques suivantes :

– Les interruptions sont group´ees en un certain nombre de niveaux hi´erarchis´es (d´ecrits plus haut).

– Un niveau regroupe plusieurs sous-niveaux poss´edant chacun son fil d’interruption et sa priorit´e `a l’int´erieur du niveau ; les programmes associ´es aux sous-niveaux d’un mˆeme niveau ne peuvent s’interrompre les uns les autres, leur priorit´e respective n’intervenant que lors du choix si plusieurs d’entre eux sont en attente simultan´ement.

– Un sous-niveau regroupe lui-mˆeme plusieurs demandes d’interruptions, les causes d’interrup- tion ´etant recherch´ees par test d’indicateurs.

2.3.2 Commande du syst`eme d’interruption

Chaque niveau d’interruption peut ˆetre dans l’un des ´etats suivants :

´etat d´esarm´e : le niveau n’accepte aucune demande d’interruption.

15

´etat arm´e : le niveau accepte et m´emorise une demande d’interruption. On peut armer ou d´esarmer un niveau d’interruption par programme en utilisant des instructions privil´egi´ees. Cette possibilit´e est donc r´eserv´ee au S.E.

´etat masqu´e : le niveau a ´et´e inhib´e par programme de sorte que l’interruption a pu ˆetre m´emoris´ee mais ne peut ˆetre prise en compte par la CPU.

´etat d’attente : l’interruption peut ˆetre prise en compte imm´ediatement si deux conditions sont remplies :

– aucun niveau de priorit´e sup´erieure n’est en ´etat d’attente ;

– la CPU se trouve dans une phase interruptible (fin d’instruction).

Le niveau passe alors `a l’´etat actif.

´etat actif : il implique la prise en compte de l’interruption par la CPU et dure pendant toute la dur´ee du traitant d’interruption.

Des instructions privil´egi´ees permettent d’armer (ou de d´esarmer), d’autoriser (ou de masquer), de d´eclencher un ou plusieurs niveaux d’interruption. Lorsque le nombre de niveaux d’interruption est limit´e, un registre sp´ecialis´e de la CPU contient ce que l’on appelle le masque d’interruption. A chaque niveau est associ´e un bit indiquant s’il est autoris´e ou masqu´e.

2.4 Les appels syst`emes

Nous avons vu pr´ec´edemment que les programmes utilisateur s’ex´ecutent en mode esclave. Les instructions privil´egi´ees permettant la programmation des E/S leur sont donc interdites. Dans ces conditions, toute demande d’E/S et plus g´en´eralement toutes les actions demandant des droits ´etendus, passent par une requˆete en bonne et due forme au S.E. Cette requˆete est r´ealis´ee par le truchement d’une instruction de la CPU qui provoque une interruption. Nous l’appellerons SVC pour SuperVisor Call mais on utilise aussi le terme TRAP. Cette solution, bien que compliqu´ee, a les avantages suivants :

– L’interruption provoque un branchement vers le traitant d’interruption mais aussi un chan- gement de mode. Il y a donc un passage automatique du programme utilisateur en mode esclave au S.E. en mode maˆıtre.

– Il existe un et un seul point d’entr´ee vers le S.E. pour les processus utilisateur. Il est donc plus facile (du point de vue du concepteur du syst`eme) de s´ecuriser l’appel des primitives syst`eme.

– Si on part du principe que le vecteur d’interruptions se trouve dans une zone inaccessible au programme utilisateur, alors ce dernier n’a aucun moyen de passer en mode maˆıtre et l’instruction SVC est le seul point de passage.

G´en´eralement, un appel syst`eme a la structure ci-dessous. Heureusement, les librairies standards dis- ponibles dans tous les syst`emes de d´eveloppement offrent une interface plus agr´eable et se chargent de programmer en assembleur l’appel du syst`eme. Le choix entre les diverses routines se fait non pas par adressage (comme c’est le cas pour un sous programme) mais au moyen d’un param`etre suppl´ementaire pass´e soit dans un registre, soit dans la partie op´erande de l’instruction SVC.

pr´eparer les arguments de la requˆete pr´eparer le type de la requˆete SVC analyser le compte rendu du S.E.

16

En fait, vu du programme utilisateur, et mise `a part la forme de l’instruction d’appel elle mˆeme (SVC supervisor call ), tout semble se passer comme un appel de proc´edure (empilement de l’adresse

mais en fait, comme nous venons de le voir, le m´ecanisme est beaucoup

de retour, des param`etres plus complexe.

)

En r´esum´e, un appel au S.E. permet l’utilisation depuis un programme utilisateur d’un certain nombre de routines syst`eme exigeant des droits ´etendus.

Du cot´e du S.E., le traitant de l’interruption SVC a la structure suivante :

sauver le contexte du demandeur v´erifier la nature de la requˆete v´erifier les arguments de la requˆete v´erifier les droits du demandeur ex´ecuter la demande restaurer le contexte du demandeur retour vers le demandeur

L’ensemble des routines syst`emes ainsi offertes `a l’utilisateur peut ˆetre consid´er´e comme une ex- tension du r´epertoire des instructions (chaque SVC repr´esentant une macro-instruction) constituant ainsi une nouvelle machine .

2.5 Les d´eroutements

Un d´eroutement est une interruption qui intervient lorsqu’une anomalie a ´et´e d´etect´ee dans le d´eroulement d’une instruction, empˆechant ainsi son ex´ecution. On distingue trois types de causes :

– donn´ees incorrectes (division par z´ero, d´ebordement arithm´etique, etc.) ;

– tentative de violation d’une protection et/ou d’une interdiction (violation de protection m´emoire, utilisation d’une instruction privil´egi´ee en mode esclave, etc.) ;

– impossibilit´e d’ex´ecution d’une instruction (instruction inconnue ou instruction optionnelle absente de la configuration utilis´ee, etc.).

Selon la cause d’un d´eroutement, on peut ´eventuellement en supprimer l’effet. Ainsi, par exemple, on peut r´ecup´erer les erreurs arithm´etiques ou encore les lectures au del`a de la fin de la m´emoire. Toutefois, le caract`ere strictement synchrone des d´eroutement interdit leur retard de prise en compte comme cela est possible pour les interruptions : en l’occurrence, la notion de masquage ne peut s’appliquer.

En r´esum´e, le mode esclave, les d´eroutements vers le S.E. en cas d’erreur et le m´ecanisme des appels syst`eme imposent un cadre strict pour l’ex´ecution des programmes utilisateur.

Les syst`emes d’exploitation r´ecents sont dits dirig´es par les interruptions car ils ne s’ex´ecutent que sur demande explicite. Cette demande provenant de l’ext´erieur (interruption mat´erielle) ou des programmes en cours d’ex´ecution (d´eroutement et appel syst`eme).

Chapitre 3 Les processus

3.1 D´efinition

Un processus est un programme en cours d’ex´ecution. Il faut d’embl´ee faire la diff´erence entre un programme qui est un fichier inerte regroupant des instructions de la CPU et un processus qui un ´el´ement actif. Figeons un processus pour en observer ses composantes. Nous trouvons :

– des donn´ees (variables globales, pile et tas) stock´ees dans une zone de la m´emoire qui a ´et´e allou´ee au processus ;

la valeur des registres (g´en´eraux et sp´ecialis´es) de la CPU lors de l’ex´ecution ;

– les ressources qui lui ont ´et´e allou´ees par le syst`eme d’exploitation (m´emoire principale, fichiers ouverts, p´eriph´eriques utilis´es, etc.) ;

L’ensemble de ces composantes forme le contexte d’ex´ecution d’un processus ou plus simplement le contexte.

3.2 ´etat d’un processus

Un processus n’est pas continuellement en train de s’ex´ecuter. Si la machine comporte n pro- cesseurs identiques, `a un instant donn´e il y a au maximum n processus actifs. En fait, parmi tous les processus qui sont susceptibles de s’ex´ecuter, seulement un petit nombre s’ex´ecutent r´eellement. L’allocation de la CPU aux processus qui la r´eclament est appel´ee l’ordonnancement de la CPU. Elle sera ´etudi´ee au chapitre ??. L’´etat op´erationnel d’un processus est un moyen de repr´esenter les diff´erentes ´etapes de ce processus telles qu’elles sont g´er´ees par le syst`eme d’exploitation. Le sch´ema ?? montre les divers ´etats dans lesquels, dans une premi`ere approche intuitive, peut se trouver un processus :

– Initialement, un processus est connu du syst`eme mais l’ex´ecution n’a pas d´ebut´e.

– Lorsqu’il est initialis´e, il devient prˆet `a ˆetre ex´ecut´e (1).

– Lors de l’allocation de la CPU `a ce processus il devient actif (2). Trois cas peuvent alors se pr´esenter :

– Le processus se termine (3).

– Le processus est en attente (5) d’un ´ev´enement et d`es sa r´eception il redeviendra prˆet

(6).

17

18

prêt 6 1
prêt
6
1

connu

18 prêt 6 1 connu terminé 3 en attente 5 4 2 actif 1. 2. 3.

terminé

3

en attente 5
en attente
5

4

2

18 prêt 6 1 connu terminé 3 en attente 5 4 2 actif 1. 2. 3.

actif

1.

2.

3.

4.

5.

6.

initialisation

exécution

achèvement

préemption

attente

signal

Fig. 3.1 – Sch´ema simplifi´e des transitions d’´etat d’un processus

– Le processus est suspendu et se remet dans l’´etat prˆet (4). Il y a r´equisition ou pr´eemption de la CPU. Dans ce cas, le S.E. enl`eve la CPU au processus qui la d´etient. Ce m´ecanisme sera vu en d´etail au chapitre traitant de l’allocation de la CPU.

La notion d’attente d’un ´ev´enement m´erite par son importance et sa complexit´e un petit exemple. Un ´editeur de texte enchaˆıne continuellement la boucle suivante :

r´ep´eter lire un caract`ere traiter ce caract`ere jusqu’`a

Lorsque le processus ´editeur est actif il adresse une requˆete au S.E. pour lui demander une op´eration d’E/S (la lecture d’un caract`ere). Deux cas se pr´esentent :

– si il existe un caract`ere dans le tampon d’entr´ee, ce dernier est renvoy´e par le S.E. ;

– si le tampon d’entr´ee est vide, le S.E. va endormir le processus en changeant son ´etat. Lorsque l’utilisateur frappe une touche du clavier, le S.E. (qui avait pr´ealablement sauvegard´e la demande de l’´editeur) r´eveille l’´editeur qui pourra ainsi devenir actif et traiter ce fameux caract`ere.

Plus g´en´eralement, toutes les op´erations lentes (en comparaison de la vitesse de la CPU) provoquent un arrˆet momentan´e du processus demandeur et une reprise ult´erieure lorsque l’op´eration est termin´ee. C’est notamment le cas pour les op´erations d’E/S. Le but de ce m´ecanisme est de r´ecup´erer le temps d’attente pour ex´ecuter un autre processus sur la CPU.

3.3 Repr´esentation d’un processus

Un processus est caract´eris´e dans le syst`eme par :

– un identificateur ou num´ero (par exemple le PID pour Process IDentification dans le syst`eme UNIX) ;

– un ´etat op´erationnel (par exemple, un des cinq vus pr´ec´edemment) ;

19

– un contexte ;

– des informations comme les priorit´es, la date de d´emarrage, la filiation ;

– des statistiques calcul´ees par le S.E. comme le temps d’ex´ecution cumul´e, le nombre d’op´erations d’E/S, le nombre de d´efauts de page, etc.

Ces informations sont regroup´ees dans un bloc de contrˆole de processus ou PCB (Process Control Block). Le syst`eme maintient donc un PCB pour chaque processus reconnu. Ce PCB est une mine d’informations. Il repr´esente en fait la principale donn´ee manipul´ee par l’allocateur de la CPU. Lorsqu’un processus quitte l’´etat actif, son PCB est mis `a jour et la valeur des registres de la CPU y est sauvegard´e. Pour que ce mˆeme processus redevienne actif, le S.E. recharge les registres de la CPU `a partir des valeurs sauvegard´ees dans le PCB, il change l’´etat et finalement il red´emarre l’ex´ecution du processus. Nous verrons plus tard dans quelles conditions un processus peut perdre la CPU. Hormis les processus, le syst`eme maintient ´egalement un certain nombre de files qui regroupent les blocs de contrˆole des processus. On trouve ainsi,

– la file des processus prˆets,

– la file des processus connus,

– la file des processus en attente qui se d´ecompose en

– la file des processus qui attendent la disponibilit´e

– de la ressource unit´e d’E/S 0 ,

– de la ressource m´emoire , etc

– la file des processus qui attendent la fin d’une op´eration d’E/S,

sur l’unit´e d’E/S 0 (le disque principal),

sur l’unit´e d’E/S 1 (un terminal), etc

etc

La figure ?? illustre le chemin suivi par notre ´editeur de texte dans les files du syst`eme lors de sa demande d’un caract`ere sur l’unit´e d’entr´ee standard.

3.4 Gestion des processus

Les processus sont les principaux ´el´ements actifs du syst`eme. Dans ce cadre, il est logique que la cr´eation d’un nouveau processus soit demand´ee par un processus. Il existe donc une filiation entre processus p`ere et le(s) processus fils. Lors du d´emarrage de la machine, le S.E. lance un processus qui est orphelin puisqu’il n’a pas de p`ere. Ce processus est souvent appel´e init. Le premier rˆole de ce processus est de lancer des fils qui auront chacun une fonction dans l’organisation g´en´erale de la machine. Par exemple,

– un processus pour g´erer les E/S asynchrones avec les terminaux,

– un processus pour g´erer les connexions au syst`eme avec demande et v´erification d’un nom d’utilisateur et d’un mot de passe,

– un processus pour g´erer l’allocation de la CPU aux processus !

20

réquisition

processus actifs
processus
actifs
20 réquisition processus actifs file des processus prêts allocation de la CPU fin de l'E/S file
file des processus prêts allocation de la CPU

file des processus prêts

allocation de la CPU

file des processus prêts allocation de la CPU
actifs file des processus prêts allocation de la CPU fin de l'E/S file des processus en

fin de

l'E/S

file des processus en attente de fin d'E/S
file des processus en attente de fin d'E/S

file des processus en attente de fin d'E/S

file des processus en attente de fin d'E/S
l'E/S file des processus en attente de fin d'E/S demande d'E/S file des processus morts appel

demande

d'E/S

file des processus morts

de fin d'E/S demande d'E/S file des processus morts appel de exit() Fig. 3.2 – D´eplacements

appel de exit()

Fig. 3.2 – D´eplacements des processus dans les files du syst`eme

etc

Ces processus font partie du syst`eme d’exploitation. Ils s’ex´ecutent donc avec des droits ´etendus. Nous les appellerons les processus syst`eme ou d´emons (daemons) par opposition aux processus utilisateur. Le syst`eme d’exploitation est donc compos´e d’un noyau r´esident qui ne s’ex´ecute que sur demande explicite (interruptions et d´eroutements) et d’un ensemble de processus syst`eme qui ont chacun une fonction pr´ecise `a assurer. Ce d´ecoupage pr´esente deux avantages :

1. la partie r´esidente du syst`eme est r´eduite en taille ce qui permet d’´eviter une trop grande consommation de m´emoire par le syst`eme ;

2. les processus syst`emes ne sont pas forc´ement toujours prˆets ou mˆeme toujours pr´esents en m´emoire ce qui permet – encore une fois – de r´eduire la m´emoire et le temps CPU consomm´e par le S.E. au d´etriment des processus utilisateur.

Si le syst`eme est organis´e `a base de plusieurs processus, des logiciels d’application peuvent ´egalement adopter cette structure. Si c’est le cas, il est n´ecessaire et mˆeme vital de fournir des outils permettant une communication et une synchronisation ais´ee entre les processus d’une mˆeme application. C’est l’objet du chapitre parall´elisme et synchronisation . De plus, cette structuration `a base de proces- sus coop´eratifs est la seule capable d’utiliser facilement une structure mat´erielle multi-processeurs en associant un processus diff´erent `a chaque processeur. Nous avons parl´e de la cr´eation d’un processus mais sa disparition est une ´etape importante ! Elle `a lieu sur demande d’un processus ´etranger (syst`eme ou p`ere) ou sur sa propre demande sous la forme d’un suicide. Ce dernier cas correspond `a l’appel de la fonction standard exit() du langage C.

3.5 Poids lourds et poids l´egers

Nous avons ´evoqu´e plus haut les avantages li´es `a la structuration des applications sous la forme de processus coop´eratifs. Mais cette structure comporte ´egalement des inconv´enients :

– elle implique une communication massive entre les processus ce qui engendre un coˆut non n´egligeable de la part du syst`eme ;

– elle augmente le nombre de commutations de contexte (c-`a-d la sauvegarde et la restauration du contexte d’un processus interrompu) provoquant de ce fait une perte de temps de CPU.

21

La notion de thread et de syst`emes multi-threads vise `a r´egler ce type de probl`eme. Dans les syst`emes multi-threads un processus est d´efini comme un ensemble de threads. Un thread (aussi appel´e processus de poids l´eger ou lightweight process LWP) est un programme en cours d’ex´ecution qui partage son code et ses donn´ees avec les autres threads d’un mˆeme processus. Bien entendu, les piles sont propres `a chaque thread pour ´eviter que les appels de fonctions et les variables locales ne se m´elangent. Cette solution pr´esente plusieurs avantages :

– si un processus ne comporte qu’un seul thread nous revenons au mod`ele classique ; les syst`emes multi-threads sont donc plus g´en´eraux ;

– il n’y a plus `a mettre en place une communication entre les threads d’un mˆeme processus puisqu’ils agissent tous sur les mˆemes donn´ees ;

– le temps de commutation entre les threads d’un mˆeme processus est r´eduit car le contexte est le mˆeme, et seuls les registres de la CPU doivent ˆetre sauvegard´es ;

– en associant un (ou plusieurs) thread(s) `a chaque processeur on peut facilement exploiter une structure multi-processeurs.

Chapitre 4 Allocation de ressources et interblocage

4.1 Allocation de ressources

4.1.1 Notion de ressources

Une ressource est un objet utilisable par un processus. Cette utilisation passe par le respect d’un mode d’emploi qui pr´ecise comment manipuler la ressource. Les ressources sont couramment libres ou allou´ees. Pour chaque ressource (ou famille de ressources) il existe un allocateur qui a la charge de r´epondre aux requˆetes de demande, de lib´eration et ´eventuellement de r´equisition. Les ressources peuvent ˆetre r´equisitionnables (CPU, m´emoire) ou pas (unit´es de bande),

partageables (m´emoire, disques

)

ou pas (imprimantes, unit´es de bande). Elles peuvent ˆetre phy-

ou logicielles (´editeur, canal). Dans ce dernier

cas, c’est donc un programme qui est partag´e entre plusieurs processus. La duplication de celui-ci en autant de copies qu’il y a de demandeurs est inconcevable du fait de la perte de taille m´emoire que cela impliquerait. Les ressources logicielles dont le code ne change jamais (les donn´ees ´etant ´etablies pour chaque demandeur) sont dites r´eentrantes. Les ressources peuvent ´egalement ˆetre banalis´ees si on dispose de plusieurs occurrences identiques d’une mˆeme ressource.

siques (celles que nous venons de citer, coupleurs

)

4.1.2 Objectifs et outils de l’allocation de ressources

Face `a tous ces types de ressources, il est souhaitable de d´efinir clairement les objectifs de l’allocation de ressources. Ces objectifs se retrouvent dans la plupart des allocateurs que nous avons ou que nous allons ´etudier. Le S.E. doit ˆetre ´equitable dans l’allocation de ressources tout en respectant les priorit´es. En d’autres termes, pour un mˆeme niveau de priorit´e, les demandes doivent ˆetre trait´ees sans favoritisme excessif. La forme la plus simple de l’´equit´e consiste `a ´eviter la privation de ressource, c’est `a dire l’attente infinie par un processus d’une ressource qu’il n’aura jamais. C’est notamment le cas si il y a interblocage entre plusieurs processus (nous verrons ce cas dans les sections suivantes). Finalement, le S.E. doit ´egalement ´eviter la congestion c’est `a dire la demande excessive de ressources. En d’autres termes, le S.E. doit veiller `a ne pas accepter les demandes quand le syst`eme est en surcharge. Un mod`ele math´ematique des files d’attente peut fournir aux designers de syst`eme des solutions efficaces au probl`eme d’allocation de ressource. Les param`etres de ce mod`ele sont :

– la loi de distribution des instants d’arriv´ee,

– la loi de distribution des demandes de service,

– la politique de gestion de la file d’attente,

– l’absence ou la pr´esence d’un m´ecanisme de r´equisition.

22

4.2

Les interblocages

23

Le but principal du syst`eme dans un environnement multiprogramm´e est le partage des ressources disponibles sur le site entre l’ensemble des processus. Or certaines de ces ressources ´etant non partageables, un processus poss´edant une telle ressource aura un contrˆole exclusif sur celle-ci. Si l’on g´en´eralise cela `a plusieurs processus et `a plusieurs ressources on voit facilement apparaˆıtre les risques d’interblocage. Leur potentialit´e est li´ee aux conditions suivantes :

– les ressources sont utilis´ees en exclusion mutuelle c’est `a dire par un seul processus `a la fois (voir le chapitre sur la synchronisation de processus) ;

– chaque processus utilise simultan´ement plusieurs ressources qu’il acquiert au fur et `a mesure de ses besoins sans n´ecessairement lib´erer celles qu’il poss`ede d´ej`a ;

– les ressources ne peuvent ˆetre r´equisitionn´ees ;

– il existe un ensemble de processus (p 0 ,p 1 ,

,p

n ) tel que chaque p i attend une ressource

occup´ee par p i+1 et p n attend une ressource occup´ee par p 0 .

Apr`es avoir pr´esent´e quelques exemples, nous ´etudierons dans les paragraphes qui suivent quelques m´ethodes employ´ees pour pr´evenir, ´eviter, d´etecter et gu´erir les interblocages.

– La pr´evention est bas´ee sur le principe de maintenir `a chaque instant le syst`eme dans un ´etat tel qu’aucun interblocage ne soit possible. Cette attitude est parfaitement efficace tant que l’on ne consid`ere que l’aspect interblocage, mais en contre partie elle engendre un mauvais rendement d’utilisation des ressources. N´eanmoins, ce genre de technique est tr`es largement utilis´e.

– Dans l’´evitement de blocage, le but recherch´e est de rendre moins strictes les conditions impos´ees au syst`eme, comparativement `a la pr´evention, afin de mieux utiliser les ressources. En fait, dans l’´evitement, la possibilit´e de blocage existe `a chaque instant, mais chaque fois que celui-ci s’approche, il est prudemment contourn´e.

– Les m´ethodes de d´etection se limitent `a d´eterminer si un interblocage est apparu et si c’est le cas, quels sont les processus et les ressources qui sont impliqu´es. Ce travail ´etant fait, l’interblocage peut ˆetre trait´e et supprim´e.

– Les m´ethodes de gu´erison sont utilis´ees pour gu´erir un interblocage en permettant `a certains processus impliqu´es de terminer leur ex´ecution afin de lib´erer les ressources qu’ils utilisent. En fait, ces techniques, la plupart du temps, consistent `a supprimer un ou plusieurs des processus bloqu´es. Ceux- ci sont repris ensuite, g´en´eralement `a partir du d´ebut, leur ex´ecution pr´ec´edente ayant ´et´e perdue.

4.2.1 Les embouteillages

Un exemple que l’on rencontre h´elas tr`es fr´equemment est caus´e par la bˆetise et l’individualisme de certains automobilistes abordant un carrefour important `a une heure de pointe. Chacun sˆur de sa sup´eriorit´e sur l’autre, ignore les contraintes consid´er´ees surann´ees (en la circonstance) que sont feux ou priorit´e et accapare la ressource que constitue le carrefour, pr´ef´erant faire confiance `a son agressivit´e ou sa soi-disant d´ebrouillardise pour imposer sa propre notion de priorit´e. Ce sont g´en´eralement ces mˆemes automobilistes qui seront prˆets `a tout pour faire respecter la loi lorsque d’aventure celle-ci va dans leur sens (unique).

24

4.2.2 Ressource unique

La plupart des risques d’interblocage dans un syst`eme sont dus aux ressources `a acc`es unique. La figure ?? illustre ce type de configuration. Nous y voyons deux processus et deux ressources `a acc`es unique. Une fl`eche allant d’une ressource `a un processus indique que celui-ci d´etient celle-l`a ; une fl`eche allant d’un processus `a une ressource signifie que celui-l`a est demandeur de celle-ci. Nous avons donc dans le cas pr´esent un interblocage puisque le processus A poss`ede la ressource 1 et d´esire acqu´erir en plus la ressource 2 alors que celle-ci est d´etenue par le processus B qui r´eclame la ressource 1. Cette configuration boucl´ee est caract´eristique des interblocages.

ressource 1
ressource
1
La ressource 1 est détenue par le processus A processus A
La ressource 1
est détenue par
le processus A
processus
A
Le processus B réclame la ressource 1 processus B
Le processus B
réclame la
ressource 1
processus
B

Le processus A réclame la ressource 2

ressource 2
ressource
2

La ressource 2 est détenue par le processus B

Fig. 4.1 – Interblocage simple

4.2.3 Interblocage dans un syst`eme de spooling

Rappelons que l’utilit´e d’un syst`eme de spooling est de ne plus assujettir l’ex´ecution d’un pro- gramme `a la lenteur de certains p´eriph´eriques tels que l’imprimante. Une sortie sur un tel p´eriph´erique sera donc aiguill´ee vers un support d’acc`es beaucoup plus rapide (disque magn´etique, par exemple) afin de lib´erer le programme. L’´echange effectif avec le p´eriph´erique sera effectu´e ensuite, `a partir du fichier spool constitu´e, via une unit´e d’´echange. Pour reprendre l’exemple de l’imprimante, on ne pourra tol´erer qu’un programme qui tourne plusieurs heures au rythme de 100 lignes d’impression toutes les 10 minutes monopolise ce pr´ecieux p´eriph´erique durant tout ce temps. C’est la raison pour laquelle les fichiers spool ne seront imprim´es qu’apr`es ach`evement des programmes correspondants. Dans ces conditions, le probl`eme qui se pose est celui de la place pr´evue pour l’ensemble des fichiers spool . Le spectre de l’interblocage se dessine peu `a peu. Il peut en effet arriver un moment o`u la zone de spool ´etant satur´ee, plus aucun processus ne puisse op´erer des sorties, mais aucun n’´etant achev´e, la zone spool ne peut se vider ! Que faire `a ce moment l`a ?

– Supprimer un processus (et perdre toute l’ex´ecution) pour r´ecup´erer la place qu’il occupait ? Qui nous assure que l’on ne sera pas oblig´e ensuite d’en supprimer un deuxi`eme puis un troisi`eme ?

– Commencer `a imprimer les sorties d’un des processus ? Lequel choisir ? Monopolisera-t-il l’im- primante longtemps ? Le principe lui-mˆeme est-il acceptable ?

25

– Aurait-on pu pr´evenir cette situation en interdisant tout acc`es `a un nouveau fichier spool (c’est `a dire en fait tout nouveau travail) d`es que l’occupation avait atteint un certain taux ?

4.2.4 Autre forme de blocage : la famine

Dans tout syst`eme o`u des processus sont en attente pendant que des ressources sont allou´ees et en particulier le processeur, il est possible que l’activation d’un processus soit ind´efiniment retard´ee alors que les autres sont servis. Cette situation de famine est aussi pr´ejudiciable qu’un blocage. Lorsqu’une ressource est allou´ee sur la base de priorit´es, il se peut qu’un processus reste en attente pendant qu’une suite ininterrompue de processus de priorit´e plus ´elev´ee ont la pr´ef´erence. Or le propre d’un syst`eme est d’ˆetre `a la fois ´equitable et efficace envers les processus en attente. On verra `a la section ?? comment on peut accroˆıtre la priorit´e au fur et `a mesure que le temps d’attente augmente. Ce type de technique pr´esent´e pour la ressource processeur peut ˆetre appliqu´e pour n’importe quelle ressource.

4.3 La pr´evention de blocages

C’est assur´ement la technique la plus utilis´ee par les designers de syst`eme. Nous allons voir ici quelques unes des m´ethodes propos´ees en consid´erant leurs effets `a la fois sur les utilisateurs et sur le syst`eme en particulier du point de vue des performances. Havender proposa de mettre en d´efaut les conditions n´ecessaires d’interblocage vues en ?? en imposant des contraintes aux processus :

– Tout processus doit annoncer les ressources qui vont lui ˆetre n´ecessaires et ne d´emarrer que lorsque toutes sont disponibles.

– Si un processus `a besoin d’une ressource suppl´ementaire, il doit lib´erer celles en sa possession et faire une nouvelle demande incluant la nouvelle.

– Les ressources sont class´ees par type dans un ordre lin´eaire auquel devra se soumettre tout processus pour ses demandes d’allocation.

Il est `a noter que chacune des strat´egies propos´ees ci-dessus a pour but de mettre en d´efaut une des conditions n´ecessaires d’interblocage sauf la premi`ere. En effet, nous voulons nous r´eserver le droit de disposer de ressources d´edi´ees.

4.3.1 ´echec `a la condition d’attente

La premi`ere strat´egie d’Havender impose que toutes les ressources n´ecessaires `a un processus soient libres avant qu’il puisse commencer ; ce sera donc du tout ou rien . En aucune fa¸con, les ressources utiles ne pourront ˆetre r´eserv´ees jusqu’`a ce que toutes ´etant libres, l’ex´ecution puisse commencer : elles devront ˆetres toutes libres simultan´ement ! La deuxi`eme condition n´ecessaire est ainsi trivialement mise en d´efaut mais `a quel prix ! Quel gaspillage de ressources ! Supposons qu’un programme dont l’ex´ecution dure plusieurs heures ait besoin la plupart du temps de un ou deux d´erouleurs de bandes sauf pendant un court instant, en fin d’ex´ecution, o`u dix unit´es lui sont n´ecessaires. En appliquant cette strat´egie, le processus devra monopoliser les dix d´erouleurs pendant toute son ex´ecution. De plus, il devra attendre qu’ils soient tous libres avant de pouvoir ˆetre initialis´e, ce qui risque d’ˆetre long ! Nous nous trouvons devant un risque flagrant de famine. Une solution utilis´ee pour rem´edier `a ce gros d´efaut consiste `a op´erer par ´etapes lorsque, comme dans l’exemple que nous venons de voir, le programme s’y prˆete. Dans ces conditions, l’allocation

26

des ressources se fera elle aussi par ´etape, ce qui r´eduit consid´erablement la sous-utilisation des ressources mais engendre un coˆut d’exploitation plus ´elev´e.

4.3.2 ´echec `a la condition de non-r´equisition

Supposons que le syst`eme autorise un processus `a conserver les ressources qu’il d´etient alors qu’il op`ere une nouvelle demande. Tant que les ressources suppl´ementaires demand´ees sont libres, le blocage n’apparaˆıt pas. Mais si nous arrivons dans un sch´ema montr´e dans la figure ??, nous sommes en situation d’interblocage. Havender pr´econise en pareil cas d’imposer `a un processus demandeur de lib´erer les ressources qu’il d´etient pour ensuite les redemander en y ajoutant la nouvelle. Cette strat´egie met en ´echec la troisi`eme condition n´ecessaire Mais l`a encore, `a quel prix ? Lors de la lib´eration obligatoire des ressources d´etenues, tout un travail peut ˆetre perdu (bonjour les performances syst`eme) ! Si cela se produit peu souvent, c’est tol´erable, mais si c’est fr´equent ce peut ˆetre catastrophique : en particulier des travaux prioritaires et/ou `a ´ech´eance risquent de voir leur statut s´erieusement remis en cause, sans parler des risques ´evidents de famine.

4.3.3 ´echec `a la condition d’attente circulaire

C’est le but recherch´e par la troisi`eme strat´egie propos´ee par Havender. Chaque type de ressource ayant un num´ero, tout processus ne pourra effectuer ses requˆetes que par ordre croissant dans ces types. Cette strat´egie a ´et´e implant´ee dans de nombreux syst`emes, mais non sans difficult´e.

– Les diverses ressources ´etant requises au moyen de leur num´ero d’ordre, l’ajout d’une nouvelle ressource sur un site n´ecessite la modification de tous les programmes. La portabilit´e est nulle.

– Le num´ero d’ordre allou´e aux diverses ressources doit refl´eter l’ordre d’utilisation de la plu- part des programmes susceptibles d’ˆetre ex´ecut´es sur le site. Si d’aventure un programme ne respecte pas cet ordre canonique , les ressources doivent ˆetre acquises ´eventuellement longtemps avant leur utilisation effective. D’o`u un gaspillage.

– Les syst`emes tendent de plus en plus aujourd’hui `a respecter la contrainte de convivialit´e. Le moins que l’on puisse dire est que cette strat´egie ne r´epond pas `a cette attente.

´

4.4 Evitement d’interblocage (l’algorithme des banquiers)

Dans un syst`eme o`u les risques d’interblocage existent, il est toujours possible de l’´eviter en prenant les pr´ecautions n´ecessaires `a chaque allocation de ressource. La technique la plus connue est sans doute l’algorithme des banquiers de Dijkstra ainsi nomm´ee `a cause de la grande prudence de ceux-ci en mati`ere de prˆets : On ne se lˆache pas des pieds sans se tenir des mains ! Partons du principe que le S.E. connaˆıt parfaitement l’´etat de l’allocation de ressources aux processus. Plus pr´ecis´ement, les donn´ees suivantes sont consid´er´ees comme disponibles :

dispo[i] nombre de ressources R i disponibles sur le syst`eme,

max[i,j] nombre maximum de ressources R i utilisables par le processus P j ,

alloc[i,j] nombre de ressources R i couramment allou´ees au processus P j (par d´efinition nous avons donc alloc[i,j] max[i,j]).

27

Un processus P j peut s’ex´ecuter si et seulement si, pour toute ressource R i , nous avons

max[i,j] alloc[i,j] dispo[i].

Un ordre d’ex´ecution P 1 ,P 2 ,

peuvent s’ex´ecuter jusqu’`a leur terme les uns apr`es les autres dans cet ordre. Bien entendu l’ex´ecution d’un processus P k implique la lib´eration par P k des ressources qu’il a utilis´ees. Un syst`eme est dit sain si il existe un ordre d’ex´ecution sain des processus. Si un syst`eme est sain, alors il ne peut pas y avoir d’interblocages. Par contre, si le syst`eme n’est pas sain, un interblocage peut apparaˆıtre mais ce n’est pas une obligation.

,P

n est dit sain si et seulement si les processus P 1 ,P 2 ,

,P

n

En r´esum´e, l’apparition d’un ´etat non sain n’implique pas pour autant qu’il y aura in´evitablement un interblocage. La seule chose que cela implique est qu’une s´equence d´efavorable d’´ev´enements peut conduire `a un interblocage.

En se basant sur cette propri´et´e, le S.E. face `a une demande d’allocation de la ressource R i au processus P j , applique l’algorithme suivant :

1. les annonces sont elles respect´ees (c-`a-d alloc[i,j] < max[i,j]) ?

2. si j’alloue R i `a P j l’´etat obtenu est-il sain ?

3. dans l’affirmative je r´ealise l’allocation ; sinon je suspends le processus P j qui ne peut donc pas continuer son ex´ecution.

Le principe de l’algorithme des banquiers est de refuser toute requˆete ayant pour effet de mettre le syst`eme dans un ´etat non sain. En r´esum´e :

– les conditions d’exclusion mutuelle, d’attente et de non r´equisition sont autoris´ees ;

– les processus doivent annoncer leurs besoins en ressources ;

– ils peuvent conserver les ressources en leur possession tout en r´eclamant des ressources suppl´ementaires ;

– il n’y aura pas de r´equisition ;

– afin d’aider le syst`eme, les ressources seront demand´ees une `a une ;

– si une requˆete n’est pas honor´ee, le processus demandeur conserve n´eanmoins les ressources en sa possession et attend un temps fini jusqu’`a ce qu’il obtienne satisfaction ;

– seules les requˆetes laissant le syst`eme dans un ´etat sain sont honor´ees. Dans l’´eventualit´e contraire, le processus demandeur devra attendre (le syst`eme ´etant toujours dans un ´etat sain, toutes les requˆetes pourront ˆetre satisfaites tˆot ou tard).

Cet algorithme semble donc int´eressant et `a tout le moins plus convivial et d’un meilleur rendement que les strat´egies de pr´evention propos´ees par Havender. Toutefois, nous allons voir qu’il contient de nombreuses faiblesses qui font que les concepteurs de syst`emes lui pr´ef`erent d’autres approches.

– L’algorithme pr´esuppose et s’appuie totalement sur le fait que le nombre de ressources est inva- riant. Or il est bien ´evident que des probl`emes de maintenance du mat´eriel ou tout simplement des pannes peuvent mettre en d´efaut ce postulat.

– Il pr´esuppose aussi que chaque utilisateur annonce le maximum de ressources utilis´ees. Or `a l’heure actuelle, la convivialit´e grandissante des syst`emes fait que rares sont les utilisateurs connaissant pr´ecis´ement les ressources dont ils ont besoin.

28

– L’algorithme garantit que les requˆetes pourront ˆetre satisfaites qui est rassurant mais gu`ere suffisant !

– R´eciproquement, il impose aux processus de restituer les ressources fini. L`a encore, on pourrait s’attendre `a un peu plus d’exigence !

dans un temps fini ( !) Voil`a

au bout d’un temps

4.5 D´etection des interblocages

Les algorithmes de d´etection sont utilis´es dans des syst`emes o`u les trois premi`eres conditions n´ecessaires sont autoris´ees et ont pour but de d´eterminer s’il y a attente circulaire. L’utilisation de ces algorithmes entraˆıne un coˆut d’exploitation non n´egligeable.

4.5.1 Graphes d’allocation de ressource

L’utilisation de graphes orient´es, repr´esentant les allocations et requˆetes de ressources, facilite la d´etection des blocages. Dans les sch´emas qui vont suivre, les carr´es repr´esentent des processus et les cercles des classes de ressources identiques. Les petits cercles contenus dans ces derniers repr´esentent le nombre de ressources de chaque classe. La figure ?? montre les relations pouvant ˆetre repr´esent´ees dans un graphe d’allocation et de requˆete des ressources. Ces graphes sont modifi´es au cours du temps `a chaque nouvelle allocation ou lib´eration de ressource sur le site. S’il advient qu’une ressource d’un type donn´e soit hors service (pour une cause quelconque), cela se traduira dans le graphe par la suppression d’un petit cercle dans le grand cercle correspondant au type en question.

(a)

(b)

R1

P1

P1

P1
P1

P1 réclame une ressource de type R1cercle correspondant au type en question. (a) (b) R1 P1 R2 Une ressource de type R2

R2

(a) (b) R1 P1 P1 réclame une ressource de type R1 R2 Une ressource de type

Une ressource de type R2 a été allouée à P1(a) (b) R1 P1 P1 réclame une ressource de type R1 R2 Fig. 4.2 – Graphe

Fig. 4.2 – Graphe de requˆete et d’allocation de ressource

Afin de d´eterminer s’il est en situation de blocage, le syst`eme devra proc´eder `a une r´eduction du graphe.

4.5.2 R´eduction d’un graphe d’allocation de ressource

Si les requˆetes d’un processus peuvent ˆetre satisfaites, on dit que le graphe est r´eduit par ce processus (cela signifie que l’on consid`ere le graphe comme si le processus s’´etait achev´e, lib´erant ainsi les ressources qu’il d´etenait). Cela se traduit par la suppression des fl`eches provenant de ressources et aboutissant `a ce processus et de celles partant de ce processus vers d’autres ressources.

Si un graphe peut ˆetre r´eduit par tous ses processus, il n y a pas de blocage. Dans le cas contraire, les processus irr´eductibles constituent l’ensemble des processus en interblocage.

La figure ?? montre les diverses ´etapes de r´eduction d’un graphe permettant d’aboutir `a la conclusion qu’il n’y a pas d’interblocage.

L’ordre dans lequel les r´eductions se font est sans importance : le r´esultat sera toujours le mˆeme.

29

P8 P7 R6 P9 R7
P8
P7
R6
P9
R7
P7
P7
P8
P8

R7

R6

P9
P9
29 P8 P7 R6 P9 R7 P7 P8 R7 R6 P9 Réduction par P9 Réduction par

Réduction

par P9

P7 R6 P9 R7 P7 P8 R7 R6 P9 Réduction par P9 Réduction par P8 P8

Réduction

par P8

P8 R7 R6 P9 Réduction par P9 Réduction par P8 P8 P7 R6 P9 R7 Réduction
P8 P7 R6 P9 R7 Réduction par P7
P8
P7
R6
P9
R7
Réduction par P7
P7
P7

R7

P8 R6 P9
P8
R6
P9

Fig. 4.3 – R´eductions d’un graphe d’allocation

4.6 Gu´erison d’interblocage

Une fois que le syst`eme a d´etermin´e qu’il y avait interblocage, il doit le gu´erir en supprimant une ou plusieurs des conditions n´ecessaires. Habituellement, un ou mˆeme plusieurs processus perdront pour ce faire tout ou partie du travail d´ej`a accompli. Mais mieux vaut cela que le maintien de l’interblocage. La gu´erison est rendue difficile pour plusieurs raisons :

– Tout d’abord, nous venons de le voir, la d´etection de l’interblocage n’est pas chose ais´ee, et le syst`eme peut ne pas s’en apercevoir tout de suite.

– La plupart des syst`emes n’ont gu`ere de facilit´e pour suspendre ind´efiniment un processus, l’enlever du syst`eme et le reprendre plus tard. En particulier, cela est hors de question pour les processus temps r´eels.

– Mˆeme si ces possibilit´es existaient, elles entraˆıneraient un coˆut d’exploitation prohibitif et n´ecessiteraient les comp´etences d’un op´erateur attentif, ce qui n’est pas toujours possible !

– La gu´erison d’un interblocage de proportions modestes peut ˆetre op´er´ee avec un coˆut raison- nable ; mais si l’on est en pr´esence d’un interblocage de grande envergure (faisant intervenir plusieurs dizaines ou mˆeme centaines de processus), la quantit´e de travail sera ´enorme.

Comme nous l’avons dit, la gu´erison passe forc´ement par la destruction d’un processus afin de r´ecup´erer les ressources qu’il poss´edait pour permettre aux autres processus de s’achever. Quelquefois la destruction de plusieurs processus s’impose pour r´ecup´erer un nombre suffisant de ressources. Aussi le terme de gu´erison semble ici un peu exag´er´e, mais s’adapte parfaitement `a la conception occidentale de la m´edecine qui s’attache surtout `a la symptomatique des pathologies. (On peut faire la comparaison avec une amputation d’un membre atteint d’art´erite : le patient s’estime-t-il gu´eri ?) L’ordre dans lequel les processus vont ˆetre supprim´es est tr`es important. Va-t-on chercher `a minimiser leur nombre ? Va-t-on consid´erer la quantit´e de travail d´ej`a accomplie afin de r´eduire la

30

perte de rendement ? Va-t-on consid´erer les priorit´es des processus ? Va-t-on choisir les processus victimes parmi ceux pour lesquels le retrait des ressources n est pas fatal `a 1 ex´ecution (afin de seulement les suspendre, le temps de gu´erir , pour ensuite les reprendre en l’´etat, sans perte de travail) ? Et le temps d’exploitation de tout cela ? Et si cela arrive sur un site sur lequel se d´eroule

une application temps r´eel tr`es d´elicate (surveillance de raffinerie, de centrale atomique

). Voil`a

autant de questions qui donnent `a r´efl´echir sur la conception des syst`emes de demain et qui, loin d’ˆetre r´esolues de fa¸con satisfaisante, occasionnent quelques nuits blanches au concepteurs

d’aujourd’hui.

4.7 Et demain ?

Nous venons d’avoir un aper¸cu de ce qui se faisait (ou pourrait se faire) aujourd’hui. En fait, ce sont les m´ethodes de pr´evention carr´ees, brutales, mais efficaces et sans risque qui sont le plus souvent employ´ees, le blocage ´etant encore tout `a fait occasionnel. Dans les syst`emes futurs, les interblocages devront ˆetre trait´es de fa¸con syst´ematique et efficace pour plusieurs raisons :

– Les syst`emes s’orienteront de plus en plus vers des op´erations parall`eles asynchrones, abandon- nant les sch´emas s´equentiels. Les bancs de processeurs seront monnaie courante, autorisant un parall´elisme ´enorme.

– L’allocation des ressources sera dynamique. La convivialit´e grandissante des syst`emes fera que l’on utilisera ce que l’on voudra quand on le voudra (sans mˆeme le savoir !).

– De plus en plus, les donn´ees seront assimil´ees `a des ressources. En cons´equence, la quantit´e des ressources que devra g´erer un syst`eme atteindra une taille gigantesque.

On peut donc imaginer que ce probl`eme tout en devenant de plus en plus important et de plus en plus difficile `a traiter trouvera n´eanmoins dans les technologies et les structures futures des solutions efficaces.

Chapitre 5 Allocation du processeur

5.1

Introduction

Le partage d’une machine entre plusieurs utilisateurs s’est tr`es rapidement r´ev´el´e n´ecessaire pour des raisons d’´economie, de rentabilit´e et de convivialit´e. Sous cette hypoth`ese, le probl`eme qui se pose alors, `a chaque instant, pour chaque processeur, est de d´ecider s’il doit poursuivre ou interrompre l’ex´ecution du processus courant, et, dans le second cas, de d´eterminer le prochain processus `a activer. La r`egle utilis´ee pour effectuer ce choix est contenue dans l’algorithme d’ordonnancement, plus couramment appel´e ordonnanceur (scheduler ). Nous allons pr´esenter ici quelques param`etres inter- venant dans l’´elaboration des divers algorithmes utilis´es, en les justifiant par l’id´ee directrice qui a motiv´e leur emploi. Il faut en fait consid´erer l’ordonnanceur sous trois aspects :

– Au niveau le plus ´elev´e, le plus proche de l’utilisateur, sa fonction consiste `a d´eterminer si un travail soumis doit ˆetre admis (tout travail admis devient un processus) ou pas. En d’autres termes, ce niveau a pour mission d’allouer (ou r´equisitionner) des machines virtuelles aux divers utilisateurs du syst`eme selon certaines r`egles induites par la gestion sp´ecifique du site consid´er´e. Ainsi, l’´evaluation des priorit´es, la gestion des ressources n´ecessaires (r`eglement de conflits), le maintien de la charge du syst`eme en dessous du seuil d’´ecroulement et de son int´egrit´e, en particulier en cas d’incidents impr´evisibles, sont autant de tˆaches dont l’ordonnanceur devra s’acquitter avec in´evitablement des r´epercussions sur les travaux soumis.

– Le rˆole du niveau moyen est de d´eterminer l’ensemble des processus pouvant obtenir le contrˆole. Autrement dit, il tient `a jour les param`etres relatifs aux diff´erents processus qui permettront de d´egager ceux ´etant susceptibles de devenir actifs.

– Le niveau le plus bas, le plus proche du mat´eriel, choisit parmi les processus prˆets, en respectant les priorit´es, celui `a qui le processeur va ˆetre allou´e. C’est le r´epartiteur qui est toujours r´esident en m´emoire.

Il faut bien comprendre que le fait d’allouer une ressource `a un processus favorise celui-ci (au moins de fa¸con temporaire). Ainsi, chaque rouage de l’ordonnanceur a pour effet d’appliquer une certaine politique envers les divers processus, et par cons´equent, envers les utilisateurs. Or, c’est justement cette politique qui sera appel´ee a ˆetre ´eventuellement modifi´ee afin de satisfaire le plus grand nombre d’usagers. C’est la raison pour laquelle, ces diff´erents points de choix devront ˆetre s´epar´es du cˆot´e purement logique de l’ordonnanceur. Sans donner plus de d´etails sur la fa¸con d’´evaluer la priorit´e d’un processus (ce sera l’objet du paragraphe suivant), le programme simplifi´e de l’ordonnanceur pourrait s’´ecrire :

31

32

pour toujours p := prioritaire ; tant que (´etat(p) = pr^et) faire p = suivant(p) ; fin faire restaurer contexte(p) ; relancer(p) ; fin-pour

Dans ce programme, on a suppos´e la liste ordonn´ee par priorit´e d´ecroissante `a partir de l’entr´ee prioritaire , et de plus boucl´ee.

5.2 Les strat´egies d’ordonnancement de la CPU

5.2.1 Les objectifs

Une politique d’ordonnancement doit :

1. ˆetre ´equitable : cette contrainte est satisfaite si tous les processus sont consid´er´es de la mˆeme mani`ere et qu’aucun n’est retard´e ind´efiniment ;

2. rendre le d´ebit maximum : elle doit faire en sorte de satisfaire le plus grand nombre de demandes par unit´e de temps ;

3. pouvoir prendre en charge un maximum d’utilisateurs interactifs tout en assurant des temps de r´eponse acceptables ;

4. ˆetre pr´edictible : un mˆeme processus doit pouvoir s’ex´ecuter dans un temps `a peu pr`es ´equivalent quelle que soit la charge du syst`eme ;

5. ˆetre la moins coˆuteuse possible afin de ne pas ´eprouver les performances g´en´erales du syst`eme en particulier dans les phases instables ;

6. avoir pour effet de rationaliser la gestion des ressources en :

– recherchant une utilisation optimum ;

– favorisant les tˆaches peu exigeantes en nombre et en qualit´e de ressources ;

– ´evitant la famine (par exemple en augmentant la priorit´e au fur et `a mesure que l’attente s’accroˆıt).

7. mettre en œuvre des priorit´es fond´ees sur des crit`eres pertinents ;

8. avoir la possibilit´e de r´eajuster ces priorit´es, soit de mani`ere globale (n´ecessit´e de modula- rit´e), soit de mani`ere ponctuelle au cours du temps (priorit´es dynamiques) ;

9. favoriser les processus ayant un comportement souhaitable ;

10. veiller `a ne pas accepter de nouveaux travaux lorsque le syst`eme est en surcharge ;

etc.

33

La liste des contraintes que nous venons d’´enoncer est loin d’ˆetre exhaustive, mais suffit d´ej`a `a

mettre en ´evidence les conflits (3/10, 4/8,

la d´etermination des tˆaches ´eligibles, ce qui est justement en compl`ete opposition avec le point 5.

Ceci explique en partie la raison pour laquelle les ordonnanceurs ne seront souvent qu’un ensemble de compromis tr`es satisfaisants dans certains cas de figures, mais s’av´erant moyennement, voire fortement critiquables dans d’autres circonstances. Ceci explique aussi pourquoi nous ne pourront pas vous pr´esenter ensuite L’Ordonnanceur avec un grand O, mais une panoplie de r´ealisations dont chacune pourra s’av´erer satisfaisante sur un site donn´e mais intol´erable sur un autre.

.). Ceci d´enote donc une grande complexit´e dans

5.2.2 Crit`eres `a consid´erer

Afin de pouvoir r´ealiser tout (ou plutˆot partie) des objectifs pr´esent´es au paragraphe pr´ec´edent, le m´ecanisme d’ordonnancement doit consid´erer :

1. le taux des entr´ees/sorties de chaque processus : apr`es que le processeur lui ait ´et´e allou´e, ne l’utilise-t-il qu’un temps tr`es court avant de r´eclamer un ´echange ?

2. le taux d’utilisation du processeur : pour chaque processus, lorsque le processeur lui est allou´e, l’utilise-t-il pendant toute la tranche de temps impartie ?

3. fonctionnement interactif ou traitement par lots : les utilisateurs interactifs ´emettent g´en´eralement des requˆetes simples qui doivent ˆetre satisfaites tr`es rapidement, alors que les utilisateurs batch , n’´etant pas pr´esents peuvent subir des d´elais (ceux-ci devant toutefois rester dans des limites raisonnables) ;

4. degr´e d’urgence : un processus batch ne requiert pas de r´eponse imm´ediate alors qu’un processus temps r´eel n´ecessite des r´eponses tr`es rapides ;

5. priorit´e des processus : les processus de forte priorit´e doivent b´en´eficier d’un meilleur trai- tement que ceux de priorit´e plus faible ;

6. taux de r´equisition : lorsqu’un processus est de faible priorit´e par rapport aux autres, il en d´ecoule un fort taux de r´equisition. Dans ces conditions, le syst`eme doit-il essayer de l’avantager ou au contraire attendre que les priorit´es redeviennent comparables afin d’´eviter les temps de commutation effectu´es en pure perte, vu la forte probabilit´e de r´equisition.

7. temps cumul´e d’allocation du processeur : doit-on p´enaliser un processus ayant b´en´efici´e d’un temps d’ex´ecution important ou au contraire le favoriser car on est en droit de penser qu’il va bientˆot s’achever ? Cette question revˆet une importance particuli`ere lorsque le syst`eme est en surcharge ;

8. temps d’ex´ecution restant : le temps d’attente moyen peut ˆetre r´eduit en ex´ecutant de pr´ef´erence les processus r´eclamant un temps CPU minimum pour s’achever. h´elas, l’´evaluation de ce temps restant est rarement possible.

5.2.3 R´equisition ou pas ?

On dit qu’un ordonnanceur n’op`ere pas de r´equisition si d`es lors qu’il a allou´e la CPU `a un processus, il lui est impossible de le lui retirer. R´eciproquement, une politique d’ordonnancement autorise la r´equisition si le contrˆole peut ˆetre retir´e `a tout moment au processus actif. Cette possibilit´e est absolument et trivialement n´ecessaire sur les sites supportant des applications temps r´eel . C’est la contrainte li´ee aux temps de r´eponse qui rend cette technique indispensable dans les syst`emes interactifs. Mais la r´equisition engendre un surcoˆut non n´egligeable `a l’exploitation :

34

coˆut en temps occasionn´e par les changements de contexte incessants, coˆut en espace engendr´e par la n´ecessit´e de partager la m´emoire entre tous les processus. La non-r´equisition est gˆenante pour les travaux courts lorsqu’ils doivent attendre qu’un travail tr`es long s’ach`eve ; mais globalement la philosophie semble plus ´equitable, les temps de r´eponse sont mieux pr´evisibles car l’arriv´ee de travaux `a forte priorit´e ne vient pas perturber l’ordre des travaux en attente. La r´ealisation d’un ordonnanceur `a r´equisition est, nous l’avons d´ej`a dit, tr`es d´elicate. En par- ticulier, le calcul des priorit´es ne doit pas voir l’aspect sophistiqu´e l’emporter sur le cˆot´e signifiant. Rester simple est le maˆıtre-mot, mais si cela n’est pas possible, il faut au moins insister pour demeurer effectif et pertinent dans les choix !

5.2.4 Intervalle de temps et interruption d’horloge

Le syst`eme dispose d’un moyen tr`es simple pour retirer le contrˆole `a un processus. Un simple d´ecompteur d’impulsions d’horloge, dont le calibrage peut ˆetre modifi´e, peut d´eclencher une in- terruption prioritaire qui aura pour cons´equence d’appeler un traitant d’interruption du syst`eme d’exploitation. Un processus utilisera donc le processeur jusqu’`a ce qu’il le lib`ere volontairement, ou qu’il y ait interruption d’horloge ou tout autre type d’interruption r´eclamant une intervention du syst`eme. Le syst`eme reprenant le contrˆole pourra alors le passer `a qui bon lui semble. L’interruption d’horloge aide `a garantir des temps de r´eponse acceptables dans un syst`eme interactif, ´evite au syst`eme de rester monopolis´e dans une boucle de programme et permet en outre de traiter des applications temps r´eels. C’est donc une technique simple, efficace et polyvalente qui toutefois demande une attention particuli`ere pour le calibrage du d´ecompteur.

5.2.5 Calibrage de la tranche de temps

La d´etermination de la tranche de temps ou quantum est critique dans un syst`eme. Doit-elle ˆetre longue ou courte ? Doit-elle ˆetre fixe ou variable ? Doit-elle ˆetre la mˆeme pour tous les utilisateurs ou d´etermin´ee s´epar´ement pour chacun d’eux ? Aux conditions limites, selon que l’on fait tendre le quantum vers l’infini ou vers z´ero, un processus s’ach`evera sans que l’ordonnanceur soit intervenu ou au contraire, tout le temps CPU sera utilis´e par l’ordonnanceur lui-mˆeme et aucun processus ne pourra se d´erouler. Afin d’ajuster le quantum `a une valeur optimale, il nous faut consid´erer la courbe du temps de r´eponse moyen (figure ??). Supposons qu’on ait le moyen de faire varier le quantum grˆace `a un curseur. Lorsque celui-ci est `a z´ero, l’ordonnanceur ´etant la seule tˆache active, le temps de r´eponse est infini. D`es que nous tournons l´eg`erement le curseur, augmentant ainsi la dur´ee du quantum, le temps de r´eponse commence `a diminuer. Si nous continuons, nous allons arriver `a une position telle que si nous tournons encore l´eg`erement le curseur, le temps de r´eponse va commencer `a augmenter. Nous aurons atteint la valeur optimale. Si nous tournons le curseur `a fond , le temps de r´eponse va d´ecroˆıtre pour le processus actif `a ce moment l`a, puisqu’il va se terminer sans ˆetre interrompu, mais va consid´erablement augmenter pour tous les autres. Le temps de r´eponse moyen se stabilisera `a un niveau m´ediocre fonction du nombre moyen de tˆaches en attente et du temps d’ex´ecution moyen d’une tˆache. On sera arriv´e `a l’algorithme FIFO que nous verront dans le paragraphe suivant. Consid´erons donc la valeur optimale que nous avons obtenue pr´ec´edemment. Elle repr´esente en fait une petite fraction de seconde. Mais cette valeur est-elle vraiment bien adapt´ee `a chacun des types de tˆache. Est-elle assez grande pour que la majeure partie des requˆetes interactives puissent ˆetre trait´ees en un seul quantum ? En particulier, si nous pouvons avoir une distribution moyenne dans le temps des demandes d’´echange ´emises par m processus interactif, il serait avantageux que la valeur du quantum soit sup´erieure `a l’intervalle entre deux ´echanges car cela diminuerait d’autant le

35

nombre de r´equisitions inutiles (il vaut mieux qu’un processus n’utilise pas tout son quantum et c`ede le contrˆole `a cause d’une demande d’´echange, plutˆot qu’il soit interrompu, attende son tour , r´ecup`ere le contrˆole pour aussitˆot lancer un ´echange).

Temps de

réponse moyen

aussitˆot lancer un ´echange). Temps de réponse moyen quantum Fig. 5.1 – Influence du quantum sur
aussitˆot lancer un ´echange). Temps de réponse moyen quantum Fig. 5.1 – Influence du quantum sur

quantum

Fig. 5.1 – Influence du quantum sur le temps de r´eponse moyen

En fait, on s’aper¸coit que la valeur de ce quantum va varier d’un syst`eme `a un autre, mais aussi en fonction du taux de charge. On vient de montrer qu’il peut aussi d´ependre du processus.

5.2.6

Priorit´es

Les priorit´es peuvent ˆetre allou´ees automatiquement par le syst`eme ou de mani`ere externe. Elles peuvent ˆetre m´erit´ees ou acquises. Elles peuvent ˆetre statiques ou dynamiques. Elles peuvent ˆetre allou´ees de fa¸con rationnelle ou arbitraire, en particulier lorsque le syst`eme est contraint de faire une distinction entre plusieurs processus sans avoir les moyens d’ˆetre sˆur de faire le bon choix.

5.2.6.1 Priorit´es statiques et priorit´es dynamiques

Par d´efinition, les priorit´es statiques ne changeant pas, elles sont d’une mise en œuvre facile et engendrent un faible coˆut d’exploitation. Toutefois, elles sont insensibles aux changements survenus dans l’environnement, changements qui justement peuvent n´ecessiter un ajustement des priorit´es. A l’inverse, les priorit´es dynamiques peuvent changer en fonction de la modification de l’envi- ronnement. En particulier, nous verrons que la priorit´e initiale peut ˆetre r´eajust´ee tr`es rapidement afin d’ˆetre mieux adapt´ee au type du processus consid´er´e. Il est bien ´evident que la gestion des priorit´es dynamiques est beaucoup plus complexe et engendre un coˆut beaucoup plus grand que celle des priorit´es statiques. En contre partie, leur emploi permet d’accroˆıtre consid´erablement le d´ebit et la souplesse du syst`eme.

36

5.2.6.2 Priorit´es acquises

)

`a la majorit´e des utilisateurs d’un site. Mais il doit aussi pouvoir accepter qu’un usager b´en´eficie d’un

traitement particulier. Celui-ci ayant, par exemple, un travail particuli`erement urgent, peut d´esirer payer un suppl´ement de service pour acqu´erir une priorit´e plus forte afin que son programme soit ex´ecut´e plus rapidement. Ce suppl´ement se justifie sous deux aspect :

Un syst`eme doit offrir un service ´equitable et raisonnable (ou plutˆot raisonnablement ´equitable

– tout d’abord, ce n’est que justice car vu sa priorit´e accrue, les ressources qu’il va utiliser (en particulier le processeur) seront enlev´ees `a d’autres utilisateurs plus souvent que s’il avait conserv´e sa priorit´e normale. (Il faudrait toutefois s’assurer que le coˆut pour les autres usagers

sera diminu´e en cons´equence !

)

;

– l’autre aspect laisse supposer que les id´ees lib´erales se sont infiltr´ees jusque l`a car en effet, si on ne faisait pas payer, tout le monde r´eclamerait un meilleur service , ce qui est bien ´evidemment inconcevable !

5.3 Algorithmes d’ordonnancement

Nous allons, en fonction des probl`emes que nous venons d’exposer et des solutions partielles qui ont ´et´e envisag´ees, pr´esenter ici quelques r´ealisations d’ordonnanceurs en montrant pour chacune d’elles les avantages et les inconv´enients envers le syst`eme et envers les utilisateurs.

5.3.1 Ordonnancement par ´ech´eance

Certains travaux peuvent ˆetre soumis accompagn´es d’une date d’´ech´eance. L`a encore, cette option va entraˆıner un suppl´ement d’autant plus important que l’´ech´eance est proche de l’instant de lancement, `a condition, bien sˆur, que cette ´ech´eance soit respect´ee. Par contre, si ce n’est pas le cas, le service suppl´ementaire pourra ˆetre gratuit. Ce type d’ordonnancement est complexe pour plusieurs raisons :

– le syst`eme doit respecter l’´ech´eance sans que cela implique pour autant une s´ev`ere d´egradation de performances pour les autres utilisateurs ;

– le syst`eme doit planifier parfaitement l’utilisation des ressources toujours `a cause de cette ´ech´eance fatidique. Or cela est particuli`erement difficile car de nouveaux travaux peuvent arriver et ´emettre des demandes impr´evisibles ;

– afin de limiter les ennuis du point pr´ec´edent, l’utilisateur r´eclamant une ´ech´eance doit fournir au lancement la liste exhaustive des ressources qu’il utilisera, ce qui n’est pas ´evident, certaines ´etant transparentes pour lui (tampons d’E/S, canaux, etc.) ;

– si plusieurs travaux `a ´ech´eance sont lanc´es en mˆeme temps, l’ordonnancement va devenir tellement complexe que des m´ethodes d’optimisation tr`es sophistiqu´ees vont ˆetre n´ecessaires, d’o`u un coˆut d’exploitation tr`es lourd ;

– ce surcroˆıt de temps CPU utilis´e par l’ordonnanceur ajout´e aux faveurs accord´ees au(x) pro- cessus `a ´ech´eance va in´evitablement p´enaliser les autres utilisateurs, ce qui risque d’engendrer des conflits de personnes. Ce facteurs doit ˆetre consid´er´e avec une grande attention par les concepteurs des syst`emes d’exploitation.

37

5.3.2 Premier arriv´e, premier servi (FIFO)

La technique FIFO est assur´ement la plus simple et de ce fait n’engendre qu’un tr`es faible coˆut propre. C’est une technique sans r´equisition (tout travail commenc´e se poursuit jusqu’`a ach`evement). L’ordre de priorit´e correspond de fa¸con naturelle `a l’ordre d’arriv´ee.

arrivée

de fa¸con naturelle `a l’ordre d’arriv´ee. arrivée sortie Fig. 5.2 – L’ordonnanceur FIFO De ce point
de fa¸con naturelle `a l’ordre d’arriv´ee. arrivée sortie Fig. 5.2 – L’ordonnanceur FIFO De ce point
de fa¸con naturelle `a l’ordre d’arriv´ee. arrivée sortie Fig. 5.2 – L’ordonnanceur FIFO De ce point
de fa¸con naturelle `a l’ordre d’arriv´ee. arrivée sortie Fig. 5.2 – L’ordonnanceur FIFO De ce point
de fa¸con naturelle `a l’ordre d’arriv´ee. arrivée sortie Fig. 5.2 – L’ordonnanceur FIFO De ce point
de fa¸con naturelle `a l’ordre d’arriv´ee. arrivée sortie Fig. 5.2 – L’ordonnanceur FIFO De ce point
de fa¸con naturelle `a l’ordre d’arriv´ee. arrivée sortie Fig. 5.2 – L’ordonnanceur FIFO De ce point
de fa¸con naturelle `a l’ordre d’arriv´ee. arrivée sortie Fig. 5.2 – L’ordonnanceur FIFO De ce point
de fa¸con naturelle `a l’ordre d’arriv´ee. arrivée sortie Fig. 5.2 – L’ordonnanceur FIFO De ce point

sortie

Fig. 5.2 – L’ordonnanceur FIFO

De ce point de vue, il est donc ´equitable, mais il faut toutefois regretter le fait que les longs travaux occasionnent une longue attente des travaux brefs qui suivent et, r´eciproquement, une multitude de petits travaux peut provoquer une longue attente de travaux importants. FIFO pr´esente une faible variance ; il est donc plus pr´edictible que la plupart des autres techniques. De toute ´evidence, il n’est pas utilisable dans les syst`emes interactifs car il ne garantit pas un bon temps de r´eponse. C’est en particulier une des principales raisons qui font que cette technique est rarement utilis´ee aujourd’hui `a l’´etat brut . N´eanmoins, il faut noter qu’elle peut ˆetre associ´ee `a une technique plus sophistiqu´ee qui accordera des priorit´es g´en´erales, les processus de mˆeme priorit´e ´etant consid´er´es selon un sch´ema FIFO.

5.3.3 Tourniquet (Round Robbin)

L’ordonnancement de type tourniquet s’inspire de la technique FIFO, l’association d’une tranche de temps autorisant la r´equisition. Les processus, au fur et `a mesure qu’ils obtiennent le statut prˆet , sont rang´es dans une file. A chacune de ses interventions, le distributeur alloue le contrˆole au processus en tˆete de file. Si le temps d’ex´ecution qui lui est ainsi imparti expire avant son ach`evement, il est plac´e en queue de file et le contrˆole est donn´e au processus suivant.

arrivée

CPU
CPU

sortie

réquisition (préemption)

Fig. 5.3 – Ordonnancement par tourniquet

Cette technique est satisfaisante dans les syst`emes temps partag´e o`u les utilisateurs interactifs doivent b´en´eficier de temps de r´eponse corrects. Le coˆut de la r´equisition peut ˆetre maintenu faible si les m´ecanismes de commutation sont efficaces et la m´emoire suffisante pour contenir plusieurs processus simultan´ement. A noter aussi la n´ecessit´e d’un r´eglage judicieux du quantum pour accroˆıtre le taux d’utilisation du processeur et donc diminuer les temps de r´eponse (voir ??).

5.3.4 Travail plus court d’abord (SJF)

La technique Plus court d’abord (SJF pour Shortest Job First ) est encore un sch´ema d’or- donnancement sans r´equisition (donc inutilisable en temps partag´e) o`u le processus ayant le plus faible temps estim´e d’ex´ecution jusqu’`a ach`evement est prioritaire. C’est donc une technique qui a ´et´e cr´e´ee pour pallier partiellement `a l’inconv´enient de FIFO qui autorisait l’ex´ecution de travaux tr`es longs avant des travaux de plus faible importance, seul leur ordre d’arriv´ee ´etant pris en compte. SJF favorise donc les travaux brefs au d´etriment des plus importants. De ce fait il entraˆıne une variance beaucoup plus grande que FIFO, en particulier pour ce qui concerne les travaux longs. SJF

38

fonctionne de fa¸con `a ce que la prochaine ex´ecution puisse s’achever (et donc quitter le syst`eme) d`es que possible. Cette technique tend donc `a r´eduire le nombre de travaux en attente, ce qui a pour cons´equence de diminuer la moyenne des temps d’attente des processus. Le principal inconv´enient de SJF est qu’il requiert une connaissance pr´ecise du temps d’ex´ecution, valeur qu’il n’est habituellement pas possible de d´eterminer. Le seul moyen est de se fier `a une esti- mation donn´ee par les utilisateurs eux-mˆemes. Cette estimation peut ˆetre bonne dans des environ- nements de production o`u les mˆemes travaux sont soumis r´eguli`erement, mais elle s’av`ere rarement possible dans les environnements de d´eveloppement. La connaissance de ce sch´ema d’ordonnancement pourrait tenter certains de sous-estimer vo- lontairement le temps d’ex´ecution afin de profiter d’une priorit´e indue. Afin d’´eviter ce genre de malhonnˆetet´e , l’utilisateur est pr´evenu `a l’avance que son travail sera abandonn´e en cas de d´epassement. Cela pr´esente deux inconv´enients :

– obligation pour les usagers de majorer les estimations ;

– mauvaise rentabilit´e du processeur (le temps consacr´e aux travaux abandonn´es faisant rapide- ment baisser le rendement).

Une seconde possibilit´e est donc offerte : poursuivre l’ex´ecution du travail durant le temps estim´e augment´e, si n´ecessaire, d’un certain pourcentage (faible en g´en´eral) puis de le mettre de cˆot´e dans l’´etat o`u il se trouve pour reprendre son ex´ecution plus tard. Bien entendu l’utilisateur sera p´enalis´e par cette attente mais aussi par un suppl´ement de facturation. Une troisi`eme possibilit´e est de ne pas mettre de cˆot´e le travail, mais de poursuivre son ex´ecution jusqu’`a ach`evement en facturant le temps exc´edent `a un taux beaucoup plus ´elev´e. Cette solution est finalement mieux accept´ee car le suppl´ement correspond effectivement `a un meilleur service.

5.3.5 Plus court temps restant (SRT)

La strat´egie SRT pour Shortest Remaining Time est la version avec r´equisition de SJF (donc utilisable en temps partag´e) o`u, l`a encore, priorit´e est donn´ee au processus dont le temps d’ex´ecution restant est le plus faible (en consid´erant `a chaque instant les nouveaux arrivants). Dans SRT, un processus actif peut donc ˆetre interrompu au profit d’un nouveau processus ayant un temps d’ex´ecution estim´e plus court que le temps n´ecessaire `a l’ach`evement du premier. L`a encore, et plus particuli`erement du fait de la r´equisition, le designer doit pr´evoir une dissuasion `a l’´egard des malins connaissant la strat´egie d’ordonnancement. Le coˆut de SRT est sup´erieur `a celui de SJF : il doit tenir compte du temps d´ej`a allou´e aux processus en cours, effectuer les commutations `a chaque arriv´ee d’un travail court qui sera ex´ecut´e imm´ediatement avant de reprendre le processus interrompu (`a moins qu’un travail encore plus court ne survienne). Les travaux longs subissent une attente moyenne plus longue et une variance plus grande que dans SJF. En th´eorie SRT devrait offrir un temps d’attente minimum, mais du fait de son coˆut d’exploitation propre, il se peut que dans certaines situations, SJF soit plus performant. Afin de r´eduire ce coˆut, on peut envisager plusieurs raffinements ´evitant la r´equisition dans des cas limites :

– supposons que le processus en cours soit presque achev´e et qu’un travail avec un temps d’ex´ecution estim´e tr`es faible arrive. Doit-il y avoir r´equisition ? On peut dans ces cas de figure garantir `a un processus en cours dont le temps d’ex´ecution restant est inf´erieur `a un seuil qu’il soit achev´e quelles que soient les arriv´ees ;

– autre exemple : le processus actif a un temps d’ex´ecution restant l´eg`erement sup´erieur au temps estim´e d’un travail arrivant. Ici encore, si SRT est appliqu´e au pied de la lettre , il

39

y a r´equisition. Mais si le coˆut de cette r´equisition est sup´erieur `a la diff´erence entre les deux temps estim´es, cette d´ecision devient absurde !

La conclusion de tout cela est que les designers de syst`emes doivent ´evaluer avec beaucoup de pr´ecautions les coˆuts engendr´es par des m´ecanismes sophistiqu´es car ils peuvent dans bien des cas aller `a l’encontre du but recherch´e : le gain de temps.

5.3.6 Plus grand rapport ensuite (HRN)

En 1971, Brinch Hanssen propose la strat´egie HRN (pour Highest Response Ratio Next ). Elle corrige certains travers de SJF et en particulier le favoritisme excessif dont b´en´eficient les nouveaux travaux courts. HRN peut ˆetre consid´er´e avec ou sans r´equisition. La priorit´e de chaque travail est fonction non seulement du temps de service, mais aussi du temps d’attente. Les priorit´es sont donc dynamiques et calcul´ees par la formule :

priorit´e = temps d’attente + temps de service temps de service en choisissant de pr´ef´erence les travaux courts si le niveau de priorit´e est identique. Ce syst`eme pr´esente plusieurs avantages :

– Les travaux longs, bien qu’´etant d´efavoris´es, voient leur priorit´e augmenter au fur et `a mesure de leur attente. Ils sont donc sˆur de r´ecup´erer la CPU au bout d’un temps d’attente fini, ce qui ´elimine le risque de privation.

– Si on utilise HRN avec un m´ecanisme de r´equisition de la CPU, les processus qui restent en sommeil un certain temps (apr`es une demande d’E/S par exemple) voient leur priorit´e augmenter. Cette augmentation permet de leur allouer plus de temps CPU lors du r´eveil, ce qui est assez logique.

5.3.7 Tourniquet multi-niveaux

Nous avons vu les probl`emes que posait dans SJF et SRT la difficult´e de connaˆıtre `a l’avance la quantit´e de temps CPU n´ecessaire `a l’ex´ecution d’un programme. Un travail fonctionnant essen- tiellement en entr´ee/sortie n’utilisera en fait la CPU que de courts instants. A l’oppos´e, un travail r´eclamant le contrˆole en permanence monopolisera la CPU durant des heures si l’on suppose un sch´ema sans r´equisition. En fait, nous l’avons vu plus haut (?? et ??), un ordonnanceur doit :

– favoriser les travaux courts ;

– favoriser les travaux effectuant de nombreuses E/S (pour une bonne utilisation des unit´es externes) ;

– d´eterminer le plus rapidement possible la nature de chaque travail afin de le traiter en cons´equence.

Le tourniquet multi-niveaux r´epond `a ces attentes. Un nouveau processus est stock´e en queue de la file de plus haut niveau. Il progresse dans cette file FIFO jusqu’`a ce qu’il obtienne le contrˆole. Si le processus s’ach`eve ou lib`ere la CPU pour une entr´ee/sortie ou une attente d’´ev´enement, il est sorti de la file d’attente. Si le quantum expire avant, le processus est plac´e en queue de la file de niveau inf´erieur. Il deviendra `a nouveau actif lorsqu’il parviendra en tˆete de cette file et `a condition que celles de niveau sup´erieur soit vides. Ainsi, `a chaque fois que le processus ´epuisera sa tranche

40

réquisition (préemption)

niveau 0 niveau 1 niveau 2 . . . . . . niveau n-1 niveau
niveau 0
niveau 1
niveau 2
.
.
.
.
.
.
niveau n-1
niveau n
arrivée
CPU
sortie

Fig. 5.4 – Sch´ema de principe du tourniquet multi-niveaux

de temps il passera en queue de la file de niveau inf´erieur `a celle o`u il se trouvait jusqu’`a ce qu’il atteigne la file de plus bas niveau. Dans ce sch´ema d’ordonnancement, la taille du quantum s’accroˆıt au fur et `a mesure que l’on descend dans les niveaux de file. En cons´equence, plus un travail est long, plus le temps CPU dont il b´en´eficie est grand. Mais en contre-partie, le processeur lui sera allou´e plus rarement puisque les processus des files sup´erieures ont une plus grande priorit´e. Un processus en tˆete de quelque file que ce soit ne pourra devenir actif que si les files de niveau sup´erieur (si elles existent) sont vides. Il y aura r´equisition d`es qu’un travail arrivera dans la file de plus haut niveau. Consid´erons `a pr´esent la fa¸con dont ce m´ecanisme s’adapte aux diff´erents types de travaux. Il favorisera les utilisateurs interactifs dont chaque requˆete sera envoy´ee dans la file prioritaire et satisfaite avant l’´epuisement du quantum. De mˆeme, les travaux travaillant essentiellement en entr´ee/sortie seront avantag´es si l’on suppose que le quantum de la file prioritaire est assez grand pour qu’une demande d’´echange survienne avant qu’il expire. Dans ces conditions, d`es que la demande d’´echange se produit, le processus demandeur est sorti de la file prioritaire et y reviendra lorsque cet ´echange sera effectu´e (b´en´eficiant ainsi entre chaque demande de la priorit´e accord´ee `a la file de plus haut niveau). En ce qui concerne un travail tendant `a monopoliser la CPU, il d´ebutera comme tous les autres dans la file la plus prioritaire, puis, tr`es vite, il descendra les niveaux pour arriver dans la file la moins prioritaire, son quantum expirant `a chaque ´etage. L`a, il restera jusqu’`a ce qu’il soit achev´e

dans les hypoth`eses actuelles, que se passe-t-il si d’aventure un processus de ce type demande

un ´echange ? Il est sorti de la file et lorsque l’´echange aura ´et´e r´ealis´e, il reviendra

dans la file

prioritaire

mais

`a moins que le syst`eme retienne la file dont il ´etait issu afin de l’y replacer ensuite.

Ce faisant, cette technique pr´esuppose que le comportement pass´e d’un processus est une bonne indication de son comportement futur. Mais alors, un processus qui apr`es une longue phase de calcul entre dans une phase o`u les ´echanges pr´edominent est d´esavantag´e ! Ceci peut encore ˆetre r´esolu en associant au processus le dernier temps pass´e dans le r´eseau de files ou en convenant que tout

41

processus montera d’un niveau dans le r´eseau chaque fois qu’il aura volontairement lib´er´e la CPU avant expiration du quantum. Le tourniquet multi-niveaux est un tr`es bon exemple de m´ecanisme adaptatif. Bien sˆur, le coˆut d’un tel ordonnanceur est sup´erieur `a un qui n’a pas ces facult´es d’adaptation, mais la meilleure ad´equation de l’attitude du syst`eme vis `a vis des diff´erents types de travaux justifie amplement cette d´epense. A noter une variante de ce syst`eme consistant `a maintenir un processus plusieurs tours dans une mˆeme file avant qu’il passe au niveau inf´erieur. Habituellement ce nombre de tours s’accroˆıt (comme la taille du quantum) en descendant dans les niveaux.

Chapitre 6 Allocation de la m´emoire centrale

6.1 Concepts de base

6.1.1 M´emoire logique

La notion de ressource logique conduit `a s´eparer les probl`emes d’utilisation d’une ressource particuli`ere des probl`emes d’allocation de cette ressource. Pour un processus, la m´emoire logique est le support de l’ensemble des informations potentiellement accessibles, c’est `a dire, l’ensemble des emplacements dont l’adresse peut ˆetre engendr´ee par le processeur lors de l’ex´ecution de ce processus. L’allocation de m´emoire consiste `a concr´etiser cette m´emoire logique par des supports physiques d’information tels que m´emoire principale, disques magn´etiques, etc. En bout de chaˆıne , l’acc`es d’un processus `a une information se traduit par l’acc`es d’un processeur physique `a un emplacement de m´emoire principale adressable par ce processeur. L’information accessible `a un processus est d´efinie par :

– l’ensemble des informations d´esignables dans son programme (objets) ;

– l’ensemble des informations de d´esignation (noms) ;

– la mise en correspondance noms/objets.

Dans un programme ´ecrit en langage ´evolu´e, noms et objets sont d´efinis par ce langage. Ils sont diff´erents de ceux que manipule le processeur physique. Le programme doit donc subir une s´erie de transformations appel´ee liaison. Celle-ci comporte une ´etape de traduction (mise en correspondance des objets avec les emplacements m´emoire et des noms avec les adresses relatives correspondantes), une ´etape d’´edition de lien (liaison entre programmes traduits s´epar´ement), et enfin une ´etape de chargement (fixation d´efinitive des adresses, jusque l`a d´efinies `a une translation pr`es). La s´eparation conceptuelle des probl`emes de d´esignation et liaison, d’une part, et des probl`emes d’allocation m´emoire, d’autre part, peut ˆetre sch´ematis´ee par la figure ??.

Langage

Mémoire

logique

Mémoire

physique

noms

noms

noms
noms
?? . Langage Mémoire logique Mémoire physique noms adresse logique adresse physique désignation et liaison

adresse

logique

adresse physique
adresse
physique

désignation

et liaison

allocation

de mémoire

Fig. 6.1 – Transformation des adresses

42

43

Le fait que la notion de m´emoire logique ne soit pas rest´ee un outil conceptuel, mais ait ´et´e mise en œuvre sur certaines machines par des dispositifs physiques de transformation d’adresse a conduit `a ce que la s´eparation des fonctions soit plus ou moins bien respect´ee.

M´emoire logique contigu¨e : Elle est constitu´ee d’une suite d’emplacements identiques (mots) organis´es de mani`ere s´equentielle et d´esign´es par des entiers cons´ecutifs appel´es adresses logiques. Un objet est une information occupant un mot ou plusieurs mots cons´ecutifs ; il est d´esign´e par l’adresse logique du premier mot. Cette organisation est donc identique `a celle des emplacements d’une m´emoire physique.

M´emoire logique non contigu¨e ou segment´ee : Elle est constitu´ee d’un ensemble de segments. Un segment est une suite de mots et regroupe g´en´eralement des informations de mˆeme nature. Il peut avoir une taille variable. Les mots contenus dans un segment sont d´esign´es par des entiers cons´ecutifs appel´es d´eplacements. L’adresse logique d’un mot est donc un couple (num´ero de segment, d´eplacement dans le segment) appel´e adresse segment´ee. Un objet, qui peut occuper un segment entier ou une suite de mots cons´ecutifs dans un segment, est d´esign´e par l’adresse segment´ee de son premier mot.

M´emoire physique non contigu¨e. Le placement des m´emoires logiques en m´emoire physique peut ˆetre contigu¨e ou pas. Dans ce dernier cas, les pages qui composent la m´emoire logique sont diss´emin´ees dans diff´erentes pages physiques. C’est une organisation en m´emoire pagin´ee ou segment´ee et pagin´ee.

6.1.2 Allocation de M´emoire

On distingue diff´erentes mani`eres de r´ealiser la mise en correspondance entre organisation de la m´emoire logique et implantation de cette m´emoire logique en m´emoire physique :

R´eimplantation dynamique : la correspondance logique/physique est variable dans le temps. De ce fait, l’allocation de la m´emoire physique se fait par zones (de taille variable) et/ou par pages (de taille fixe).

Correspondance fixe (aussi appel´ee implantation statique). La correspondance est ´etablie une fois pour toutes au moment de la compilation. C’est le cas dans les syst`emes `a partition unique ou fixes.

Correspondance dynamique (aussi appel´ee r´eimplantation dynamique). La correspondance lo- gique/physique peut aussi ˆetre dynamique et ce de deux mani`eres.

– Elle peut ˆetre fix´ee au moment du chargement du processus et donc varier entre deux ex´ecutions. La m´emoire est allou´ee sous forme de zone contigu¨es appel´es des partitions, c’est le syst`eme des partitions variables.

– Elle peut ´egalement varier durant l’ex´ecution du processus. Les objets sont donc d´eplac´es `a l’int´erieur la m´emoire centrale. Bien entendu, ces d´eplacements, op´er´es par le syst`eme, doivent ˆetre transparents pour le processus. C’est le cas dans les syst`emes pagin´es ou segment´es qui allouent la m´emoire par pages (de taille fixe) ou segments (de taille variable).

L’allocation de m´emoire doit permettre `a un processus l’acc`es `a un objet d´efini en m´emoire lo- gique, en amenant en temps voulu cet objet en m´emoire principale (la seule directement adressable). Une politique d’allocation m´emoire doit donc apporter une solution aux deux probl`emes suivants :

1. r´ealiser la correspondance entre adresses logiques et adresses physiques ;

44

Mém. physique contiguë Mém. physique non contiguë Mém. logique contiguë Correspondance fixe partitions fixes
Mém. physique contiguë
Mém. physique non contiguë
Mém. logique contiguë
Correspondance fixe
partitions fixes
partition unique
mémoire paginée
mémoire virtuelle paginée
partitions variables
Mém. logique non contiguë
mémoire segmentée
mémoire segmentée paginée

Fig. 6.2 – Les diff´erentes organisations de la m´emoire

2. r´ealiser la gestion de la m´emoire physique (allocation des emplacements, transfert de l’infor- mation).

Lorsque les informations appartiennent `a plusieurs utilisateurs, deux contraintes suppl´ementaires apparaissent :

3. r´ealiser le partage d’information entre ces utilisateurs ;

4. assurer la protection mutuelle d’informations appartenant `a des usagers distincts.

Une politique d’allocation de m´emoire id´eale aurait pour effet d’assurer qu’`a tout instant l’informa- tion n´ecessaire `a l’ex´ecution de l’instruction en cours soit imm´ediatement accessible au processeur, donc se trouve en m´emoire principale. Cet objectif n’est en g´en´eral pas atteint : on cherche alors `a r´eduire la probabilit´e que l’information soit absente de la m´emoire lorsqu’elle est n´ecessaire (d´efaut de page). Le probl`eme se r´esume alors `a deux questions :

– Quand charger un objet en m´emoire principale ?

– lorsqu’on en a besoin (chargement `a la demande),

– avant d’en avoir besoin (pr´e-chargement).

– O`u charger cet objet ?

– S’il y a assez de place libre, dans quels emplacements le charger (placement) ;

– sinon, quel(s) objet(s) renvoyer en m´emoire secondaire afin de lib´erer de la place en m´emoire principale (remplacement).

Plusieurs crit`eres seront utilis´es pour imaginer, ´evaluer et comparer les algorithmes d’allocation de m´emoire :

– Crit`eres li´es `a l’utilisation de la ressource m´emoire, mesur´ee par exemple par le taux de place perdue (ou inutilisable).

– Crit`eres li´es `a l’acc`es `a l’information, comme le temps moyen d’acc`es ou le taux de d´efauts de page.

– Crit`eres plus globaux caract´erisant des performances induites par l’allocation de la m´emoire :

taux d’utilisation de la CPU, temps de r´eponse d’un syst`eme interactif, etc.

6.2

Partage de la m´emoire sans r´eimplantation

45

6.2.1 Syst`eme `a partition unique (va-et-vient simple)

Dans les syst`emes `a partition unique (aussi appel´e va-et-vient simple ou swapping ), une zone fixe de m´emoire est r´eserv´ee aux processus des usagers (voir figure ??). Les programmes sont conserv´es sur disque sous forme absolue. Pour ˆetre ex´ecut´e, un programme est d’abord amen´e en m´emoire principale, dans sa totalit´e. L’allocation de processeur aux programmes d´etermine donc les transferts. En cas de r´equisition du processeur, le programme en cours doit ˆetre sauvegard´e sur disque avant le chargement de son successeur.

RL

sur disque avant le chargement de son successeur. RL S.E. partition unique RB mémoire Fig. 6.3
sur disque avant le chargement de son successeur. RL S.E. partition unique RB mémoire Fig. 6.3

S.E.

partition unique

chargement de son successeur. RL S.E. partition unique RB mémoire Fig. 6.3 – Syst`eme `a partition

RB

mémoire

Fig. 6.3 – Syst`eme `a partition unique

Afin d’´eviter que des erreurs d’adressage du processus utilisateur ne viennent alt´erer le S.E. r´esident, la partition unique peut ˆetre d´elimit´ee par des registres de la CPU (registre de base RB pour le d´ebut et registre limite RL pour la taille). A chaque acc`es `a une case d’adresse α, la CPU v´erifie que (RB α < RB + RL). Si ce test ´echoue, un d´eroutement pour erreur d’adressage est g´en´er´e. Ce sch´ema a l’avantage de la simplicit´e. Son principal inconv´enient est de laisser la CPU inutilis´ee pendant la dur´ee des transferts. Il est employ´e sur des installations de petite taille lorsque les contraintes de temps de r´eponse sont compatibles avec la dur´ee et la fr´equence des transferts. Des am´eliorations permettent de r´eduire le volume d’information transf´er´ee et donc la perte de temps pour la CPU :

– lorsqu’un programme est sauvegard´e sur disque, on ne range que la partie modifi´ee (en pratique, la zone des donn´ees) ;

– l’algorithme de la peau d’oignon permet d’´epargner des transferts : lorsqu’un programme est recouvert par un autre de taille plus petite, il suffit pour restaurer le plus gros de recharger la partie recouverte.

Ces am´eliorations n’apportent n´eanmoins qu’un gain limit´e, la taille des transferts n’intervenant que pour une faible part dans le temps requis. Il serait pr´ef´erable de pouvoir ex´ecuter un programme pen- dant la dur´ee de transfert d’un autre. Pour ce faire, il faut donc conserver simultan´ement en m´emoire plusieurs programmes, en partie ou en totalit´e. Ce mode de partage est appel´e multi-programmation. Une multi-programmation sans r´eimplantation dynamique est possible par la partition de la m´emoire.

6.2.2 Partition fixe de la m´emoire

Dans un syst`eme `a partitions fixes, la m´emoire est partag´ee de fa¸con statique en un nombre fixe de partitions, les tailles et limites de ces partitions ´etant d´efinies lors de la g´en´eration du syst`eme. Chaque programme est affect´e de fa¸con fixe `a une partition au moment de la construction de son image m´emoire par l’´etape d’´edition de liens. Les programmes (sous leur forme ex´ecutable ) sont conserv´es sur disque sous forme absolue, et les adresses qui y figurent sont les adresses physiques correspondant `a l’implantation de chacun d’eux dans la partition qui lui a ´et´e attribu´ee.

46

Pendant qu’un programme est transf´er´e (en entr´ee ou sortie), un autre programme peut ˆetre ex´ecut´e dans une autre partition ; il faut bien entendu disposer d’un processeur d’entr´ee/sortie auto- nome (canal ou ADM). La figure ?? sch´ematise l’implantation des programmes et le chronogramme d’activit´e dans un syst`eme `a partitions fixes.

S.E.

zone 1

zone 2

mémoire

A
A

C

B

programmes

U.C.

Canal.

Allocation de la mémoire

A(1)

C(2)

B(1)

U.C. Canal. Allocation de la mémoire A(1) C(2) B(1) C(2) A(1) B(1) C(2) Chronogramme d'activité

C(2)

U.C. Canal. Allocation de la mémoire A(1) C(2) B(1) C(2) A(1) B(1) C(2) Chronogramme d'activité programme(zone)
U.C. Canal. Allocation de la mémoire A(1) C(2) B(1) C(2) A(1) B(1) C(2) Chronogramme d'activité programme(zone)
U.C. Canal. Allocation de la mémoire A(1) C(2) B(1) C(2) A(1) B(1) C(2) Chronogramme d'activité programme(zone)

A(1)

B(1)

C(2)

Chronogramme d'activité

programme(zone)

chargementA(1) B(1) C(2) Chronogramme d'activité programme(zone) sauvegarde Fig. 6.4 – Syst`eme `a partitions fixes En

sauvegardeC(2) Chronogramme d'activité programme(zone) chargement Fig. 6.4 – Syst`eme `a partitions fixes En r´ealit´e,

Fig. 6.4 – Syst`eme `a partitions fixes

En r´ealit´e, le chronogramme peut ˆetre plus complexe, chaque programme pouvant lui-mˆeme ex´ecuter des entr´ees-sorties. Dans ce cas, le processeur est ´egalement affect´e `a un autre programme. Les syst`emes `a partitions fixes sont couramment utilis´es sur des petites et moyennes installations o`u un petit nombre d’usagers interactifs coexistent avec un travail de fond. Il est alors possible de d´efinir au moment de la g´en´eration du syst`eme, des tailles de partitions adapt´ees aux diff´erentes classes de programmes. Le temps de r´eponse moyen des processus interactifs d´epend du rapport des temps d’ex´ecution aux temps de transferts, lui-mˆeme fonction du degr´e de multiplexage des partitions.

6.3 Syst`eme `a partitions variables

Dans un syst`eme `a partitions variables, le d´ecoupage en partitions n’est pas fix´e une fois pour toutes, mais il est red´efini `a chaque d´ebut d’ex´ecution d’un processus. En cons´equence, le chargement d’un programme (fixation des adresses) ne peut ˆetre fait qu’au dernier moment, lorsqu’une place lui est attribu´ee. L’allocation de la m´emoire par partitions de tailles variables suppose l’existence d’un m´ecanisme de r´eimplantation dynamique. L’utilit´e de celui-ci apparaˆıtra dans la d´esignation d’objets appartenant `a des partitions qui auront du ˆetre d´eplac´ees en m´emoire centrale.

6.3.1 R´eimplantation dynamique par registre de base

Le principe que nous allons d´ecrire est simple. Disposant d’un registre particulier ou registre de base, son contenu est syst´ematiquement ajout´e `a toute adresse engendr´ee par un processus, le r´esultat constituant une adresse physique de l’information d´esign´ee. Si les adresses d’un programme

47

sont relatives `a son d´ebut (i.e. si le programme est implant´e `a l’adresse logique 0), il suffit que le registre de base soit affect´e `a son adresse d’implantation en m´emoire physique (voir figure ??). Dans ces conditions, le programme pourra ˆetre charg´e en n’importe quel endroit de la m´emoire. En particulier, d´eplacer globalement un programme dont l’ex´ecution est commenc´ee, peut s’op´erer tr`es facilement, `a condition de modifier en cons´equence la valeur contenue dans le registre de base. De plus, si programme et donn´ees sont atteints par l’interm´ediaire de registres distincts, leur d´eplacement pourra ˆetre effectu´e ind´ependamment.

0

A

 

1

B

2

C

3

D

3

4

E

5

F

RL RB 6 150 oui 3 < RL +
RL
RB
6
150
oui
3 < RL
+

non

déroutement sur

erreur d'adressageF RL RB 6 150 oui 3 < RL + non déroutement sur   150 A

 
 

150

A

151

B

152

C

153

D

154

E

155

F

  150 A 151 B 152 C 153 D 154 E 155 F

Fig. 6.5 – Passage logique / physique par registre de base et registre limite

6.3.2 Algorithmes de gestion de la m´emoire par zones

Disposant d’une file constitu´ee par les programmes en attente de traitement, un choix doit ˆetre op´er´e afin de d´eterminer leur ordre de lancement. Cet ordre pourra ˆetre tout simplement celui de la file d’attente ou dict´e par des contraintes de priorit´es calcul´ees par le syst`eme en fonction des demandes de ressources (place m´emoire, nombre de p´eriph´eriques, etc.) ou du temps d’ex´ecution pr´esum´e. En tout ´etat de cause, cet ordre sera aussi fonction de la taille des diff´erentes partitions libres. Il faut auparavant r´esoudre les probl`emes suivants :

– choix d’une repr´esentation des partitions,

– d´efinition des crit`eres de s´election d’une partition libre,

– politique de lib´eration d’une partition occup´ee,

– d´ecision `a prendre lorsqu’aucune partition ne convient

6.3.2.1 Repr´esentation des partitions

Une partition est d´efinie par sa taille et son adresse de d´ebut, contenues dans un descripteur. En supposant que les tailles demand´ees sont variables, le nombre de partitions le sera aussi. En cons´equence, il est pr´ef´erable, plutˆot que de regrouper les descripteurs dans une table, de les situer dans les partitions elles-mˆemes et de les chaˆıner entre eux. L’ordre du chaˆınage a une influence sur l’efficacit´e des algorithmes. On peut choisir l’ordre de lib´eration des partitions, mais le plus souvent, on utilise l’un des deux classements suivants :

– classement par adresses croissantes ou d´ecroissantes,

– classement par tailles croissantes ou d´ecroissantes.

48

6.3.2.2 Algorithmes de s´election

Une demande ´etant ´emise, on connaˆıt la taille requise pour charger le programme du processus demandeur. Le plus souvent, cette demande sera satisfaite grˆace `a une partition de taille sup´erieure ; la diff´erence, ou r´esidu est rattach´ee `a la liste des partitions libres, pour autant que cette diff´erence ne soit pas trop petite. Deux possibilit´es peuvent ˆetre envisag´ees quant au choix de la partition libre pour satisfaire une demande :

– prendre la premi`ere possible, c’est `a dire, parcourir la liste jusqu’`a ce que l’on en trouve une dont la taille est sup´erieur ou ´egale `a la demande ( first-fit ) ;

– prendre la partition la plus petite possible, celle donnant le plus petit r´esidu ( best-fit ).

L’allocation d’une partition `a un processus peut se d´ecomposer en deux phases, recherche de la partition selon l’algorithme choisi puis placement du r´esidu dans la liste. Le classement par tailles croissantes ´evite de parcourir toute la liste pour trouver la plus petite partition possible (permettant ainsi une impl´ementation ais´ee du best-fit ). Par contre le placement du r´esidu impose une modification du chaˆınage. A l’oppos´e, le classement par adresses croissantes autorise une gestion rapide des r´esidus (seule la taille doit ˆetre modifi´ee, le chaˆınage demeurant inchang´e) pour peu que le chargement s’op`ere en bas de partition. Cette technique est mieux adapt´ee `a l’algorithme du first-fit . On peut constater que certaines tailles sont demand´ees plus fr´equemment que les autres. Dans ces conditions, on am´eliore l’efficacit´e de l’allocation en r´eservant un certain nombre de partitions poss´edant ces tailles privil´egi´ees. En cas d’´epuisement de cette r´eserve, le m´ecanisme classique est utilis´e.

6.3.2.3 Lib´eration d’une partition

Trois cas sont `a consid´erer lors de la lib´eration d’une partition :

– la partition lib´er´ee est entour´ee de deux partitions libres,

– la partition lib´er´ee est entour´ee d’une partition libre et d’une partition occup´ee,

– la partition lib´er´ee est entour´ee de deux partitions allou´ees.

Chaque fois que cela est possible (deux premiers cas), il est utile de regrouper les partitions libres contigu¨es afin de r´eduire la fragmentation de la m´emoire. Il est ´evident que le classement par adresses croissantes est alors le plus efficace.

6.3.3 Fragmentation et compactage

Le ph´enom`ene le plus gˆenant dans le type d’allocation ´etudi´e ici est celui de la fragmentation de la m´emoire, qui apparaˆıt au bout d’un certain temps de fonctionnement et qui est dˆu `a la multiplication des r´esidus de petite taille On peut aboutir `a une situation o`u aucune partition de taille suffisante n’est disponible pour satisfaire une demande, alors que la somme des tailles de partitions libre est largement sup´erieure. Une solution consiste `a compacter les partitions allou´ees en les d´epla¸cant vers une extr´emit´e de la m´emoire, laissant apparaˆıtre ainsi `a l’autre extr´emit´e une partition libre de taille ´egale `a la somme des tailles des partitions libres primitives. Le compactage peut s’effectuer de deux fa¸cons possibles :

– par recopie `a l’int´erieur de la m´emoire physique en utilisant une instruction de type MOVE (voir ci-dessous), op´eration monopolisant le processeur central,

MOVE adresse d´epart , adresse arriv´ee , longueur

49

– par recopies successives des partitions sur disque puis du disque en m´emoire, `a la place voulue, en utilisant un processeur d’entr´ee-sortie. L’op´eration est alors plus longue, mais a le m´erite de lib´erer le processeur central pour poursuivre l’ex´ecution des autres programmes.

La figure ?? donne un exemple simple de compactage. Il montre les diff´erentes strat´egies de recopie des partitions occup´ees de mani`ere `a limiter la quantit´e de donn´ees `a d´eplacer. On passe dans cet exemple de 200 ko `a 50 ko. Il est bien certain que seule une possibilit´e de r´eimplantation dynamique permet d’op´erer un tel compactage. D’autre part, Knuth a montr´e que lorsque l’algorithme d’allocation ne peut satisfaire une demande, cela intervient alors que le taux de remplissage de la m´emoire est tel qu’apr`es compac- tage, la mˆeme situation va `a nouveau apparaˆıtre tr`es rapidement, obligeant le syst`eme `a consacrer une grande partie de son temps `a effectuer des compactages successifs. En conclusion, une telle forme d’allocation n’est gu`ere adapt´ee `a un syst`eme interactif, mais convient mieux lorsque le nombre de partitions allou´ees est faible, et leur temps d’allocation grand (traitement par trains de travaux).

100

 

100

100

100

 

100

100

5050

100

100

100

5050

 
 

100

   

5050

5050

5050

 

200

150

100

50

Fig. 6.6 – Diff´erentes possibilit´es de compactage de la m´emoire

6.4

M´emoire pagin´ee

50

Une m´emoire pagin´ee est divis´ee en blocs de taille fixe, ou pages logiques, qui servent d’unit´es d’allocation. La m´emoire physique est elle-mˆeme divis´ee en blocs de mˆeme taille appel´e pages phy- siques. Nous pr´esentons successivement les m´ecanismes de pagination d’une m´emoire contigu¨e pa- gin´ee et d’une m´emoire pagin´ee segment´ee.

6.4.1 Pagination d’une m´emoire contigu¨e

La figure ?? repr´esente le sch´ema g´en´eral d’une m´emoire contigu¨e pagin´ee. Le rˆole de la boˆıte marqu´ee Fonction de pagination est d’´etablir une correspondance entre les adresses de pages logiques et les adresses de pages physiques de mani`ere `a se qu’une page logique puisse ˆetre rang´ee dans une page physique quelconque. Les pages physiques deviennent ainsi des ressources banalis´ees dont la gestion est plus simple que celle de partitions de taille variable. Le nombre d’emplacements d’une page (physique ou logique) est toujours une puissance de 2. Notons 2 l la taille (nombre d’emplacements) d’une page (logique ou physique) et 2 n le nombre de pages. Il y a pour l’instant autant de pages logiques que de pages physiques.

Mémoire

Mémoire

logique

physique

2

0

1

n

- 1

Mémoire logique physique 2 0 1 n - 1 Fonction de pagination 2 0 1 n
Mémoire logique physique 2 0 1 n - 1 Fonction de pagination 2 0 1 n
Mémoire logique physique 2 0 1 n - 1 Fonction de pagination 2 0 1 n
Mémoire logique physique 2 0 1 n - 1 Fonction de pagination 2 0 1 n
Mémoire logique physique 2 0 1 n - 1 Fonction de pagination 2 0 1 n
Mémoire logique physique 2 0 1 n - 1 Fonction de pagination 2 0 1 n
Mémoire logique physique 2 0 1 n - 1 Fonction de pagination 2 0 1 n
Mémoire logique physique 2 0 1 n - 1 Fonction de pagination 2 0 1 n
Mémoire logique physique 2 0 1 n - 1 Fonction de pagination 2 0 1 n
Mémoire logique physique 2 0 1 n - 1 Fonction de pagination 2 0 1 n
Mémoire logique physique 2 0 1 n - 1 Fonction de pagination 2 0 1 n
Mémoire logique physique 2 0 1 n - 1 Fonction de pagination 2 0 1 n

Fonction de

pagination

physique 2 0 1 n - 1 Fonction de pagination 2 0 1 n - 1
physique 2 0 1 n - 1 Fonction de pagination 2 0 1 n - 1

2

0

1

n

- 1

Fig. 6.7 – M´emoire lin´eaire pagin´ee

Une adresse logique pagin´ee est alors construite par concat´enation d’un num´ero de page lo- gique (n bits) et d’un d´eplacement dans la page (l bits). De mˆeme, une adresse physique est la concat´enation d’un num´ero de page physique (n bits) et d’un d´eplacement (l bits). Les tailles de page usuelles vont de 0,5ko `a 32ko. ´etant donn´e un num´ero de page logique (npl), la fonction de pagination permet de trouver le num´ero de la page physique (npp) qui la contient. Dans un souci d’efficacit´e, cette fonction est r´ealis´ee par un m´ecanisme mat´eriel. La r´ealisation la plus courante de la fonction de pagination utilise une table de pages en m´emoire, index´ee par un num´ero de page logique (table desc de la figure ??). Lors d’un acc`es `a la m´emoire, la correspondance adresse logique/adresse physique (qui est une op´eration mat´erielle), est mise en œuvre comme suit :

51

adr. logique npl dep vérifier que npl < RL npp prot + npp npp dep
adr. logique
npl
dep
vérifier que
npl < RL
npp
prot
+
npp
npp
dep
adr. physique
R. de base
RL

Table des pages (desc)

Fig. 6.8 – Organisation d’une table de pages

(npl, d´eplacement) = adresse logique si (npl < RL) alors si les protections sont respect´ees alors adr. physique = (desc[npl].npp, d´eplacement) sinon d´eroutement sur violation de protection fin si sinon d´eroutement sur erreur d’adressage fin si

Le champ desc[npl].prot indique le mode d’acc`es autoris´e `a la page logique npl. Cette informa- tion est utilis´ee par les m´ecanismes de protection et un acc`es non autoris´e provoque un d´eroutement pour violation de protection. Notons qu’une table de pages repr´esente le contenu d’une m´emoire logique particuli`ere. Si le syst`eme d’exploitation permet `a chaque processus, ou `a chaque usager du syst`eme, de d´efinir une m´emoire logique distincte, il doit g´erer une table de pages distincte par processus ou par usager. Le pointeur vers l’origine de cette table (RB) fait alors partie du contexte du processus ou de l’usager. Les tables des pages se trouvent en m´emoire physique, dans la partition r´eserv´ee au syst`eme d’exploitation.

La m´emoire logique d’un processus n’est plus repr´esent´ee d’une mani`ere contigu¨e en m´emoire centrale (voir figure ??). En effet, l’indirection des acc`es par la table de pages permet de loger les pages logiques dans n’importe quelle page physique. De ce fait, la gestion de la m´emoire physique revient simplement `a g´erer une liste des pages physiques libres sans id´ee de regrou- pement. Les probl`emes li´es `a la fragmentation externe disparaissent mais la fragmentation interne se fait plus pr´esente puisque la page devient l’unit´e ´el´ementaire d’allocation et de lib´eration (en pratique plusieurs kilo-octets).

L’acc`es `a une page logique n´ecessite maintenant deux r´ef´erences `a la m´emoire en raison de la consultation de la table des pages. Cette augmentation du temps d’acc`es moyen est bien sur intol´erable. La r´eduction de ce coˆut passe par deux points :

– observer le comportement des processus (vis `a vis de la m´emoire),

52

Mémoire

Table des

logique du

pages du

processus 1

processus 1

A B C
A
B
C

Table des

Mémoire

pages du

logique du

processus 2

processus 2

D E F G
D
E
F
G

pages physiques

A

D

F

C

B

A D F C B E G

E

G

F G pages physiques A D F C B E G Fig. 6.9 – Un exemple
F G pages physiques A D F C B E G Fig. 6.9 – Un exemple
F G pages physiques A D F C B E G Fig. 6.9 – Un exemple

Fig. 6.9 – Un exemple sur deux m´emoires logiques pagin´ees

– optimiser la transformation des adresses au moyen d’un circuit particulier : les m´emoire asso- ciatives.

Pour ´eviter l’acc`es `a cette table (et donc r´eduire le temps d’acc`es moyen), on passe par un circuit particulier : une m´emoire associative. Mais avant de pr´esenter cette m´emoire il faut discuter de l’utilisation de la m´emoire par les processus

6.4.2 Comportement des processus en m´emoire pagin´ee

Le comportement d’un processus dans son espace logique d´etermine ses demandes de m´emoire physique. Il est donc utile de connaˆıtre les caract´eristiques de ce comportement pour am´eliorer l’effi- cacit´e des algorithmes de gestion dynamique de la m´emoire. Donnons d’abord quelques d´efinitions :

– L’´ecoulement du temps est rep´er´e par l’ex´ecution des instructions successives : l’ex´ecution d’une instruction d´efinit une unit´e de temps. Ce temps est dit virtuel car il suppose que le programme dispose de toutes les ressources n´ecessaires (m´emoire et processeur). En cas de partage de ressources, on peut ainsi raisonner sur un programme donn´e en faisant abstraction des autres.

– La m´emoire logique pagin´ee est d´ecoup´ee en page contigu¨es de taille fixe. L’acc`es `a un em- placement d’une page est appel´e r´ef´erence `a cette page. Le num´erotage des pages permet d’´etiqueter les r´ef´erences.

– Le comportement du processus est d´efini par la s´erie des num´eros de pages r´ef´erenc´ees au cours de l’ex´ecution. Cette s´equence s’appelle chaˆıne de r´ef´erence pour le processus consid´er´e.

L’ex´ecution d’une instruction peut donner lieu `a plusieurs r´ef´erences distinctes : pages conte- nant l’instruction, le ou les op´erandes.

L’exp´erience montre que les chaˆınes de r´ef´erences des processus poss`edent des caract´eristiques communes que nous d´efinirons d’abord de mani`ere qualitative.

Non-uniformit´e. Soit n i le nombre total de r´ef´erences `a une page p i . La r´epartition des n i n’est pas uniforme : un faible pourcentage des pages cumule g´en´eralement un taux tr`es important du nombre total des r´ef´erences. Il est courant de constater que plus des 75% des r´ef´erences int´eressent moins de 20% des pages.

53

Propri´et´e de Localit´e. Sur un temps d’observation assez court, la r´epartition des r´ef´erences pr´esente une certaine stabilit´e : les r´ef´erences observ´ees dans un pass´e r´ecent sont en g´en´eral une bonne estimation des prochaines r´ef´erences.

A partir de cette constatation de localit´e, on peut cr´eer un mod`ele de comportement des programmes.

Dans ce mod`ele, le d´eroulement d’un programme est d´efini comme une succession de phases s´epar´ees par des transitions. Une phase i est caract´eris´ee par un ensemble de pages S i et un intervalle de temps virtuel T i . Lorsque le programme entre en phase i, il y reste un temps T i en effectuant principalement des r´ef´erences `a des pages de S i . Ensuite, il subit un transition durant laquelle les r´ef´erences aux pages sont dispers´ees, avant d’entrer dans la phase i + 1. Les phases constituent donc des p´eriodes de comportement stable et relativement pr´evisible, alors que les transitions correspondent `a un comportement plus erratique. L’exp´erience montre que les p´eriodes de transition ne repr´esentent qu’une faible partie du temps virtuel total, la majeure partie du temps virtuel ´etant occup´e par des phases de longues dur´ee (quelques centaines de milliers d’instructions). Qualitativement, ce type de comportement s’explique par le fait que les programmes sont souvent organis´es en proc´edures poss´edant chacune un contexte sp´ecifique, que les acc`es aux donn´ees sont souvent concentr´es (parcours de tableau), que les programmes comportent des boucles concentrant aussi les r´ef´erences. La notion d’ensemble de travail ( working set ) est ´egalement utilis´ee pour caract´eriser le comportement des programmes et pr´evoir d’apr`es l’observation. Soit W (t,T ) l’ensemble des pages ayant ´et´e r´ef´erenc´ees entre les temps t T et t. D’apr`es la propri´et´e de localit´e, ces pages ont une probabilit´e plus ´elev´ee que les autres de faire l’objet d’une r´ef´erence au temps t `a condition toutefois que la taille de la fenˆetre d’observation T soit convenablement choisie. En admettant un comportement suivant le mod`ele phase/transition, T devra ˆetre inf´erieur `a T i en phase i.

6.4.3 M´emoire associative et pagination

Une m´emoire associative est un ensemble de couple entr´ee, sortie . La pr´esence d’une valeur sur

le bus d’entr´ee provoque soit l’apparition d’une valeur de sortie soit un signal d’´echec indiquant que

cette entr´ee n’existe pas dans la m´emoire associative (figure ??). Ces m´emoires ont quelques dizaines

`a quelques centaines d’entr´ees et leur coˆut tr`es ´elev´e a empˆech´e leur extension `a des m´emoires de

plus grande taille.

 
     
   
     
   

entre 16

 

et 512

100

100 100 500   500

100

500

 
100 100 500   500

500

 
 
     
   
     
100 500   500         échec Fig. 6.10 – Sch´ema d’une m´emoire associative

échec

Fig. 6.10 – Sch´ema d’une m´emoire associative

Dans cette m´emoire associative on conserve les couples npl, npp relev´es lors des acc`es les plus r´ecents. En raison de la propri´et´e de localit´e des programmes, on a une probabilit´e ´elev´ee (80% `a 95% avec les tailles usuelles) de trouver dans la m´emoire associative le num´ero de la page logique adress´ee et donc de d´eterminer sa page physique. Ce n’est qu’en cas d’´echec que l’on passe par la table des

54

pages ; la m´emoire associative est alors mise `a jour, le couple npl, npp courant rempla¸cant le plus anciennement utilis´e (figure ??).

adr. logique npl dep mémoire succès associative échec vérifier que npl < RL npp prot
adr. logique
npl
dep
mémoire
succès
associative
échec
vérifier que
npl < RL
npp
prot
+
npp
npp
dep
adr. physique
RB
RL

Table des pages (desc)

Fig. 6.11 – Pagination avec m´emoire associative

En partant du principe que l’acc`es `a la m´emoire physique prend 100 ns et que le temps de recherche de la m´emoire associative est de 20 ns, le temps moyen d’acc`es est compris entre

0, 8 × (100 + 20) + 0, 2 × (100 + 20 + 100)

=

140

ns

0, 95 × (100 + 20) + 0, 05 × (100 + 20 + 100)

=

125

ns

suivant la probabilit´e de r´eussite et donc la taille de la m´emoire associative. Finalement, le temps d’acc`es moyen n’a augment´e que de 25%, mais la gestion de la m´emoire est beaucoup plus souple et les probl`emes de fragmentation externe n’existent plus.

6.4.4 Partage et protection de l’information

L’utilisation d’informations partag´ees entre plusieurs m´emoires logiques soul`eve trois probl`emes :

– la d´esignation : comment adresser de mani`ere uniforme les informations partag´ees ;

– le partage physique : comment assurer que les informations partag´ees existent en exemplaire unique ;

– la protection : comment garantir le respect des r`egles d’acc`es (´eventuellement s´electives) aux informations partag´ees.

Dans un syst`eme pagin´e, l’unit´e ´el´ementaire de partage est la page. Pour ˆetre partag´es, les informa- tions doivent se trouver sur une (ou plusieurs) page logique partag´ee. Cette page peut ˆetre charg´ee dans une page physique quelconque ; les tables de pages des m´emoires logiques o`u figure cette page logique contiennent alors, `a l’entr´ee correspondante, le mˆeme num´ero de page physique. Dans l’exemple pr´esent´e par la figure ?? les pages contenant le programme (Pa et Pb) sont partag´ees

mais les pages de donn´ees (D1,

, D7) ne le sont pas.

55

Mémoire

Table des

logique du

pages du

processus 1

processus 1

Pa Pb D1 D2
Pa
Pb
D1
D2

Table des

Mémoire

pages du

logique du

processus 2

processus 2

Pa

Pb

D4

D5

D6

D7

pages physiques