Cours système d'exploitation

Generated by Foxit PDF Creator © Foxit Software
http://www.foxitsoftware.com For evaluation only.

Références bibliographiques

l Leila baccouche, Au cœur des systèmes
Cours Système d’exploitation d’exploitation ; édition CPU. Tunis 2003
l Silberschatz A. Principes appliqués des
systèmes d’exploitations vuibert Paris 99
Niveau : GL2 & IIA2 l Tanenbaum A. Architecture de l’ordinateur,
Enseignant : Mona LAROUSSI cours et exercices 4e édition Dunod Paris
Bureau : 4 A8-28 2001
E-mail: mona.laroussi@insat.rnu.tn l Mohamed said ouerghi, Principe des
systèmes d’exploitation, édition CPU Tunis
2003
http://www.slideshare.net/secret/mXzhZp1rTxohC6

Plan
Calendrier des Cours
l Chapitre 1: Introduction (Matériel, Système d’exploitation)
l Chapitre 2: Gestion des processus (ordonnancement, état, l COURS
critères, algorithmes, etc.)
l Chapitre 3: Communication et synchronisation interprocessus l Le mardi de 8:00 à 9:30 ( GL)
(communication, synchronisation, interblocage)
l Chapitre 4: Gestion de la mémoire (Partition contiguë, l Le mardi de 9:45 à 11:15 (IIA2)
multiprogrammation, pagination, segmentation, etc.)
l Chapitre 5: Mémoire virtuelle (pagination et segmentation à la l TD
demande)
l Chapitre 6: Gestion des systèmes de fichiers (répertoire et nom, l
types d’objets, types d’informations, etc.)
l Chapitre 7: Gestion de périphériques
l Chapitre 8: Sécurité

1


Chapitre 1: Introduction Ordinateur
l Un ordinateur est une machine électronique
qui permet l'exécution des programmes

Ordinateur (cont.)
Les composants internes
l Un ordinateur est composé au
l Un programme est un ensemble
moins de :
d'instructions qui seront traduites en signaux
l processeur
électriques
l carte mère
l La sortie de ces programmes est convertie à l mémoire vive
nouveau pour que l'utilisateur puisse la l mémoires de masse
comprendre l périphériques

Hardware X Software

2


Carte Mère
Processeur
l C'est le “cerveau” de l'ordinateur, il contient
l Elle relie les différents composants d'un
différents composants responsables pour
ordinateur, à travers un « bus »
l'interprétation des instructions et le calcul
l La carte mère est aussi responsable de
contrôler l'accès aux
différents types
d'entrée et de sortie

La mémoire vive (RAM) Les mémoires de masse
l Utiles quand on doit sauvegarder les données
l Pour travailler avec plusieurs données, le d'une façon persistante (par exemple, quand
processeur doit utiliser une mémoire auxiliaire l'ordinateur est éteint)
pour sauvegarder temporairement les données l Disque dur, disquette, Clé USB, CD-ROM, etc.
l Plus lentes que la mémoire vive
l La mémoire RAM (Random Access Memory) est
une mémoire volatile, c'est-à-dire qu'elle ne peut
garder des informations que si elle est alimentée
électriquement

3


Les périphériques d'entrée et sortie Logiciels (Software)
l Les logiciels
l Ce sont les composants qui permettent à
l le système
l'ordinateur de communiquer avec l'extérieur
d'exploitation
(utilisateur ou autre ordinateur)
l les applications
l Périphériques d'entrée : clavier, souris, carte
réseau, mémoires de masse, etc.
l Périphériques de sortie : écran, imprimante, carte Applications
réseau, mémoires de masse, etc.
Système d’exploitation
Hardware

Systèmes d'exploitations Abstraction
l angl. « Operating System (OS) »
l Cacher la complexité des machines pour
l Qu'est-ce que c'est? l'utilisateur afin d'utiliser la machine sans savoir
« Programme assurant la gestion de l'ordinateur et ce qui est derrière
de ses périphériques »
[www.dicofr.com]
l Abstraction du terme « Machine » selon Coy:
l A quoi ca sert?
l machine réelle = Unité centrale + périphériques
l à simplifier la vie des utilisateurs et des
programmeurs l machine abstraite = machine réelle + système
d'exploitation
l à gérer les ressources de la machine d'une
manière efficace l machine utilisable = machine abstraite +
application

4


Exigences à un Système d'exploitation et i l i u ' lds
ur
a
s t gx ei
E
n
e
c

às Glé
ét i a én
r à « Faut que ça marche ! »
apslsr esrs i l i usl eàas iS
mme t et
oe u u
grr a te r i f a t (comme j'en ai envie ...)
écu,odéiv3De
Cs ,ad DGr
De u o 2,ré
lé, i à ,
D ,
V
ar
D
. .U B
.S,
- imu )a i t i ( srs i l iàt srul
t>l- sn
- tr
é et
ua ue s uiP à « Ça imprime pas ... »
srs i l i u
et
ua t
ebàe rê
l et e t
nx
i
s
e)eiai à iMa
n(es l u c
mab tei
d cl
uh
é
tn =h
n

oxto slesle
ceesupup
mpgà nD
:el r
ea i, f i uéàc i fE
elt
n
ma t o a f
b
n ve
l ,

aruxu
ods r
mme
gei
pE
rg
nc
e oi t niQe
n i ds
s qu
él
u
fe

alduu ' l ei fmp
eras rà Sl
ex
ca
oè
sc ii l Poes
r u
cs
ma
:nc
ei
h l Ta meta o
ri np r t
t
e ls
,eh u hié ,s e
src i f qipàp oMé i
i eé r c ,r
,
s r e mo
p
u
r
nncgucn
et orr, as
e iap t ,
r mmu
mme
oa i
nr
éx
e
si l S tmeMu tc e
y s tah
è
s l
i
-
éi f u eooed
n tap i è
à mp l
i ern t
mma
gd
rMo
ile
s l S tmeMu u tu
y s ta r
è
s l te s
ii
-ls
l S tmeMu p ce r
y s t r eu
è
s l o s s
i
-
as udé c f
celota t à i fE
s sn a
s c i
l S tmetmp é l
y se sr
è
s e
l S tmed us
y st é
è
s r
i
s
i
b
à eec
nnh
Ma
dei
u
ét
=

5


l U u tu dnepi r
n a r on u u
te s
i
l
s l s
e
s
cmmad s( « Jobs ») dans une queue
o ne
d'éxécution de programmes
l Entièrement séquentielle
l p.ex. pour faire plusieurs calculs pendant
la nuit

l p.ex. autoexec.bat

Définitions: Définitions:
Systèmes Multi-tache (Multitasking) Systèmes Multi-processeurs
l système avec plusieurs processeurs
l Assurer l'éxécution de plusieurs l parallèle
programmes en meme temps (c-à-d. l vrai multi-tache
plusieurs processus) l doit assurer qu'il y a l'éxecution d'autant de processus que
processeurs en meme temps
l contrairement: système avec un seul processeur
quasi-parallèle
l Chaque processus a besoin du l

l arreter et reprendre les différentes processus
processeur l Gestion avec le « scheduler » (ordonnancement des processus)
l situation concurrente
l solution: « scheduling »


Systèmes Multi-utilisateurs (« time-sharing ») Multi-utilisateurs
l permettre a différentes personnes de travailler avec l Login
un ordinateur en même temps
l connexion par
l via le terminal de l'ordinateur lui-même l Type:
l à distance (telnet, ssh, ftp, ...)
l Administrateur (« root »)
l donner l'impression à chaque utilisateur qu'il est seul
l exige une géstion des droits l Groupes
l de fichiers (pour éviter la destruction des fichiers etc.) l Utilisateurs
l de processus

l pour gérer les droits

Systèmes Temps réels Systèmes distribués
l Sert pour le pilotage et le contrôle des déroulements l doit permettre l'éxecution d'un seul
externes (p.ex. centrale électrique) programme sur plusieurs machines

l doit garantir des temps de réactions données pour des
signaux extérieur urgents l distribuer les processus et les remettre
ensemble
l plusieurs systèmes d'exploitations n'y arrivent pas car
l'interruption de certaines activités met le système dans l pour gros calculs, p.ex. inversion de grandes
un état instable
matrices

7


SE: Modèle en couches Ingrédients
l Gestion de la mémoire
Application (Logiciel, p.ex. Microsoft Word) l Gestion des fichiers
Gestion des fichiers l Gestion des processus
l Gestion des périphériques (entrées/sorties)
Gestion des périphériques (entrées/sorties)
l Contrôle des péripheriques via « Pilotes » (Driver)
Gestion des processus
l Quelques logiciels
Gestion de la mémoire l Logiciels utilitaires (ls, pwd, format, ...)
Noyau du Système d’exploitation l Logiciels d'application (Bloc-notes, ...)
Pilote Pilote Pilote l Logiciels de communication (Internet Explorer, ...)
Matériel

Historique (avant les Systèmes
d'Exploitations) oi at oess
n t i èt'
s xd py
me
S
l
1945 - 55 : tubes et interrupteurs l C / ( p i 9 4 D il e a h
P M d u1 7) it R e r
e s ,g a s c
oi at oedes
n t à i psP
xy a
lme
ètd
'

é fpstc srt a t :65
e e a ,osn 1
sr r
oe
r is -5
r 5 9 l U I( p i 9 - 9 9 p mi p r
NX d u1 6 1 7 ) r e a
e s 9 ,e r
soà et a
tl p n
mer
ai
r t
T A&
T T
qd éni st cr c :85
ss ,g u i 1
ui st
e ér i -6
0
9 l MS D S( p i 9 1 Miof
- d u1 8 ) c o
O e s , rt s
ei tose atpp,iMu
s s/rne arnitt l
re t àéoo
é g mma
mp
, rr
s
g-
P fStA&, , n
aXnoD x i
OeBTe U
c r Ss,
e I à iv
nT
i r
l MaO ( p i 9 4 A p
c S d u1 8) pe
e s , l
P snetd : 1
Cnl u r 9
( )psr io --8
or n
se a
e 0 l Wi o ( p i 9 1 Miof
n w d u1 9 ) c o
ds e s , rts
dat1sré c(tuàafet I
)rS9ee oqgc rn
of 6v c n a e
n 0 r ce
, ep ph r
i l Lu ( p i 9 2 O eS u e
i x d u1 9, p no r
n e s ) c
bàr sdRsx
ui tmeeu
é èssé
s y te
t a
i

eni i at ome
ré t iè> -
o etd
é
c
n xy
a S'-
s p
ls

8


S tmee pit s
y s' oi
è d lo
s xt n
a
l C / ( p i 9 4 D il e a h
P M d u1 7) it R e r
e s ,g a s c l U I( p i 9 - 9 9 A &
NX d u1 6 1 7 ) T T
e s 9 ,
l G o d du d r map s
en e q e u
t
i
s s
i , sai l as r d mo è pu MS D S
e ie d e o r - ,
v l O
dro c ne
a rsec
'b e Wio, .
n w.
ds
l P s eg p me
a d r h
a s
i l Mut h eMuu tus
- e t -a r
tc
i
lâ t se
it
lil
l Ee e
xmp :
l l ac s tn a xf e pr e u ,
cè aé u c i,é h r e
mu
i l
s i r p q s
hs i i
l C U8 8 , MH
P 08 2 z mé r,r eu .
mo p ce r .
i o s ,
e s
l 6 K d RM
4O e A l Po cnmé r : uu p g mme
reo mo a c n r r
tt i i
e o a
l5 MO d du d r
e qe u
s
i n p ufr p n r yme
e e t i at est
a lel è
e s
l y med f e hrr q e
st s ec is é c i
è
s i r ia hu
h
l c aod Mu h
f ll e r y
. i p l G I- n os
U X Wi w
d

S tmee pit s
y s' oi
è d lo
s xt n
a S tmee pit s
y s' oi
è d lo
s xt n
a

l MS D S( p i 9 1 Miof
- d u1 8 ) c o
O e s , rts l MaO ( p i 9 4 A p
c S d u1 8) pe
e s , l
l p mi G I
r e U
e r


Systèmes d'exploitations

l Wios. 1
n w3 1
d l Linux (depuis 1992), OpenSource
l pse
a mu c e p s emu u tu
d t h ,a
l
i
â d ta r
l te s
ii
-sl l finlandais Linus Thorwald
l Wios 5
n w9
d
l multi-tâche
l Licence GPL (General Public Licence) –
l p mi y me2 i
r es t 3 b
e rs è t OpenSource
l Wios 8
n w9
d l Multi-tâche et Multi-utilisateurs
l Irt g dn GI
n n i r as U
t et é e
e n e l
l Pg P y
u & a
l l
l Distributions
l p rè met n os T
a le n dwN
al Wi l Red Hat
l y mee pit r a x
st d o i é u
s
è ' l o e
xt n s
a multi-utilisateur l Fedore
l Wios0 0 ears n osP
n w2 0 , t p Wi wX
d è d l S.u.S.e
l j a e n y mee pit sé a x t
u lg et s t d o i r u e
me r s
eè ' l o e
xt ns
a « stand-
l Debian
alone »
l Mandrake..

Modèle en couches Modèle en couches

Application (Logiciel, p.ex. Microsoft Word) Application (Logiciel, p.ex. Microsoft Word)

Gestion des fichiers Gestion des fichiers

Gestion des périphériques (entrées/sorties) Gestion des périphériques (entrées/sorties)
Gestion des processus Gestion des processus

Gestion de la mémoire Gestion de la mémoire

Noyau du Système d’exploitation Noyau du Système d’exploitation
Pilote Pilote Pilote Pilote Pilote Pilote
Matériel Matériel


Modèle en couches Chapitre 1. Introduction

1.2 Rappel sur le fonctionnement de l'UC
Application (Logiciel, p.ex. Microsoft Word) * appel de sous- programme
branchement et conservation de l'adresse de retour
Gestion des fichiers
objectif : pouvoir appeler une séquence
Gestion des périphériques (entrées/sorties) d'instructions de plusieurs endroits
Gestion des processus moyen :
conservation de l'adresse de retour (= lecture du
Gestion de la mémoire
CO )
Noyau du Système d’exploitation branchement (= écriture du CO )
Pilote Pilote Pilote
Matériel passage de paramètres :
convention entre l' appelant et l'appelé (sys +lg)

Chapitre 1. Introduction Chapitre 1. Introduction

1.3 rappels sur les interruptions
1.3 rappels sur les interruptions
cycle de l'UC avec interruption
interruption
un agent extérieur ( périphérique ou canal)
interrompt l'UC pour lui faire exécuter une partie
d'un autre processus as: adresse sauvegarde CO
ai : adresse 1ère instruction à exécuter sur interruption
déroutement: IP : booléen vrai ssi interruption présente
même technique, mais la commutation est due au IA : booléen vrai ssi traitement interruption autorisé
processus en cours ( div par zéro, protection
mémoire)

11


Chapitre 1. Introduction Chapitre 1. Introduction

cycle de l'UC avec interruption 1.4 rappels sur les E/S
répéter E/S = transfert d'information
RI := Mem[CO];
entre mémoire centrale (et/ou UC) et périphérique
CO :=CO + 1;
éxécuter (RI);
si (IP et IA) alors * une instruction de l'UC initialise ces transferts
début avec adresse mémoire, adresse périphérique, sens,
Mem[as] :=CO; longueur (plus ou moins explicitement)
CO :=ai;
IP := IA := faux;
* sur gros ordinateur, un organe autonome le canal
fin ;
conduit ces transferts et prévient l'UC en fin d'E/S .
jusqu'à faux;

Chapitre 2. Typologie des systèmes Phase 1: Les débuts

2.1 systèmes séquentiels avec E/S synchrones l Au début, on a observé qu`il y avait des
2.2 systèmes séquentiels avec E/S synchrones + fonctionnalités communes à tous les
"faux" périphériques programmes
2.3 systèmes séquentiels avec E/S asynchrones
l il fallait les pré-programmer et les fournir
2.4 systèmes avec multi-programmation
au programmeur à moyen d`instructions
2.5 systèmes multi-processeurs
2.6 systèmes distribués
d` appel:
l amorçage du système
l entrée/sortie

12


Phase 2: Systèmes de traitement Un ordinateur principal (mainframe)
par lots (batch) simples du milieu des annnées ‘60
disques

l Sont les premiers SE (mi-50)
UCT
l L’usager soumet une job à un opérateur (mémoire probablem.
rubans autour de 250-500K)
l Programme suivi par données
l L’opérateur place un lot de plusieurs jobs sur le
dispositif de lecture lecteur de cartes
console opérateur
l Un programme, le moniteur, gère l'exécution de
chaque programme du lot
l Le moniteur est toujours en mémoire et prêt à être
exécuté
l Les utilitaires du moniteur sont chargés au besoin
l Un seul programme à la fois en mémoire, programmes
sont exécutés en séquence
l La sortie est normalement sur un fichier, imprimante, ruban
magnétique… Musée de l’histoire de l’informatique http://www.computerhistory.org/

Opérateur lisant un paquet de
Oui, cartes perforées…
cartes perforées

Une ligne de données ou de programme était codée
dans des trous qui pouvaient être lus par la machine
Source: http://www.tietokonemuseo.saunalahti.fi/eng/kuva_32_eng.htm
Finnish Data Processing Museum Association

13


Langage de contrôle des travaux (JCL) Langage de contrôle des travaux
$JOB
(JCL)
l Utilisé pour contrôler l ’exec d ’une job
l le compilateur à utiliser $FTN l L’E/S est déléguée au moniteur
l indiquer où sont les données
... l Chaque instruction d’E/S dans pgm usager
l Exemple d’une job:
l paquet de cartes comme suit:
Programme
l $JOB début FORTRAN invoque une routine d’E/S dans le moniteur:
l $FTN charge le compilateur FORTRAN et ... l s’assure de ne pas lire une ligne JCL
initie son exécution
$LOAD
l $LOAD charge le pgm objet (à la place du l un usager ne peu pas interférer avec les E/S
compilateur) $RUN
l $RUN transfère le contrôle au programme ... d`un autre usager…
usager
Données l Quand le programme usager se termine, la
l les données sont lues par le moniteur et
passées au progr. usager ...
$END
prochaine ligne de JCL est lue et exécutée
$JOB par le moniteur.
...
(job suivant)

Le moniteur par lots Caractéristiques désirables du matériel (1)

l Lecture de cartes perforées
l Interprétation de commandes JCL l Protection de la mémoire
l Lecture (load) d’une job (du lecteur de cartes)
l ne pas permettre aux pgms usager d’altérer
l Chargement en mémoire (dans la région de
l’usager) de cette job la région de la mémoire où se trouve le
l Transfère le contrôle au programme usager (job
sequencing)
moniteur
Exécution du programme usager jusqu’à:
l
l fin du programme
l Minuterie
l E/S l limite le temps qu`une job peut exécuter
l erreur

l À ce point, le moniteur reprend le contrôle l produit une interruption lorsque le temps est
l Pour le redonner plus tard au même écoulé
programme ou à un autre programme

Stallings

14


Caractéristiques désirables du matériel (2) Les systèmes par lots
l Instructions privilégiées l Ont été les premiers systèmes d`exploitation.
l exécutables seulement par le moniteur l Ils sont associés aux concepts suivants:
l une interruption se produit lorsqu’un programme usager l langage de contrôle de travaux (JCL)
tente de les exécuter l système d ’exploitation résident en mémoire
l UCT peut exécuter en mode moniteur ou mode usager l kernel = noyau
l Les instructions privilégiées ne peuvent être exécutées que en l protection de mémoire
mode moniteur
l l ’usager ne peut exécuter que en mode usager l instructions privilégiées
l seulement le SE ou une interruption peuvent changer de mode l modes usager-moniteur
l Interruptions l interruptions
l facilitent le transfert de contrôle entre le système l minuterie
d ’exploitation, les opérations d`E/S et les programmes l Toutes ces caractéristiques se retrouvent dans les
usagers systèmes d’aujourd’hui
l Le mode moniteur sera plus souvent appelé mode l Encore aujourd’hui on parle de jobs ‘par lots’ quand ils
superviseur sont exécutés séquentiellement sans intervention
humaine

Traitement par lots
Traitement par lots multiprogrammé
multiprogrammé
l Les opérations E/S sont extrêmement l Si la mémoire peut contenir +sieurs
lentes (comparé aux autres instructions) pgms, l’UCT peut exécuter un autre
l Même avec peu d’E/S, un programme pgm lorsqu’un pgm attend après E/S
passe la majorité de son temps à l C’est la multiprogrammation
attendre
l Donc: pauvre utilisation de l’UCT
lorsqu’un seul pgm usager se trouve en
mémoire

[Stallings] [Stallings]

15


Plusieurs programmes en mémoire Exigences pour multiprogrammation
pour la multiprogrammation
l Interruptions
l afin de pouvoir exécuter d’autres jobs lorsqu’un job attend
après E/S
l Protection de la mémoire: isole les jobs
l Gestion du matériel
l plusieurs jobs prêts à être exécutées demandent des
ressources:
l UCT, mémoire, unités E/S
l Langage pour gérer l’exécution des travaux:
interface entre usager et OS
l jadis JCL, maintenant shell, command prompt ou
semblables

Spoule ou spooling Équilibre de travaux
l Sìl y a un bon nombre de travaux à exécuter, on peut chercher à
obtenir un équilibre
l Travaux qui utilisent peu lÙCT, beaucoup l ’E/S, sont appelés
l Au lieu d ’exécuter les travaux au fur et à tributaires de lÈ/S
mesure qu’ils sont lus, les stocker sur l Nous parlons aussi de travaux tributaires de l ’UCT
l Le temps dÙCT non utilisé par des travaux trib. de l ’E/S peut
une mémoire secondaire (disque) être utilisé par des travaux trib. de l ’UCT et vice-versa.
l L ’obtention dùn tel équilibre est le but des ordonnanceurs à long
terme et à moyen terme (à discuter).
l Puis choisir quels programmes exécuter l Dans les systèmes de multiprog. on a souvent coexistence de
travaux longs et pas urgents avec travaux courts et urgents
et quand l Le SE donne priorité aux deuxièmes et exécute les premiers

l Ordonnanceur à long terme, à discuter quand il y a du temps de machine disponible.

16


Chaque terminal a sa propre partition de
Phase 3: Systèmes à temps partagé (TSS) mémoire

Terminaux
‘stupides’

ordinateur principal
(mainframe)

Systèmes à temps partagé
Systèmes à temps partagé (TSS)
(TSS)
l Le traitement par lots multiprogrammé ne supporte pas
l’interaction avec les usagers l Le temps de réponse humain est lent:
l excellente utilisation des ressources mais frustration des supposons qu`un usager nécessite, en
usagers! moyenne, 2 sec du processeur par minute
l TSS permet à la multiprogrammation de desservir plusieurs
usagers simultanément d’utilisation
l Environ 30 usagers peuvent donc utiliser le
l Le temps d ’UCT est partagé par plusieurs usagers système sans délais notable du temps de
réaction de l’ordinateur
l Les usagers accèdent simultanément et interactivement au
système à l’aide de terminaux l Les fonctionnalités du SE dont on a besoin
sont les mêmes que pour les systèmes par
lots, plus
l la communication avec usagers
l le concept de mémoire virtuelle pour faciliter la
gestion de mémoire

17


MULTICS et UNIX Ordinateurs Personnels (PCs)

l MULTICS a été un système TSS des l Au début, les PCs étaient aussi simples
années 60, très sophistiqué pour son que les premiers ordinateurs
époque l Le besoin de gérer plusieurs applications
l Ne réussit pas à cause de la faiblesse du en même temps conduit à redécouvrir la
matériel de son temps multiprogrammation
l Quelques unes de ses idées furent l Le concept de PC isolé évolue
reprises dans le système UNIX maintenant vers le concept d ’ordinateur
de réseau (network computer), donc
extension des principes des TSS.

Aujourd’hui Retour aux concepts de TSS

Terminaux n Plusieurs PC (clients) peuvent être
‘intelligents’ (PCs)’ desservis par un ordi plus puissant
(serveur) pour des services qui sont trop
complexes pour eux (clients/serveurs,
bases de données, telecom)
n Les grands serveurs utilisent beaucoup
des concepts développés pour les
systèmes TSS

ordinateur principal
(mainframe ou serveur)

18


Et puis… Évolution des SE

l Systèmes d’exploitation répartis:

l Le SE exécute à travers un ensemble de
machines qui sont reliées par un réseau

l Pas discutés dans ce cours

(fig. mise à jour par rapport
à votre livre)

Systèmes parallèles (tightly
Une synthèse historique coupled)
Mainframes et grands serveurs
Multics et beaucoup d`autres l Le petit coût des puces rend possible
(1960s) leur composition dans systèmes
Unix Ordinateurs Personnels multiprocesseurs
(1970)
l Les ordinateurs partagent mémoire,
MS-DOS horloge, etc.
(1981)
Mac/OS
(1984) l Avantages:
Windows NT Windows l plus de travail fait (throughput)
Linux (1988) (1990)
Solaris (1995)
(1991) l plus fiable:
Windows 2000 l dégradation harmonieuse (graceful degradation)
Windows XP

19


Systèmes parallèles Systèmes distribués ( = répartis)

l Symétriques l Les réseaux d ’ordinateurs sont en
l Tous les UCTs exécutent le même SE pleine émergence...
l Elles sont fonctionnellement identiques l Systèmes multiprocesseurs faiblement
l Asymétrique couplés (loosely coupled)
l Les UCTs ont des fonctionnalités l consistent d ’ordinateurs autonomes, qui
différentes, par exemple il y a un maître et communiquent à travers lignes de
des esclaves. communication
l Aujourd’hui, tout ordinateur puissant est
un système parallèle.

Systèmes distribués ( = répartis) Systèmes à temps réel

l SE répartis l Doivent réagir à ou contrôler des événements
externes (p.ex. contrôler une usine). Les
l il y a un SE qui fonctionne entre ordinateurs délais de réaction doivent être bornés
l l ’usager voit les ressources éloignées l systèmes temps réel souples:
comme si elles étaient locales l les échéances sont importantes, mais ne sont pas
l SE en réseau (network operating critiques (p.ex. systèmes téléphoniques)

systems) fournissent: l systèmes temps réel rigides (hard):
l le échéances sont critiques, p.ex.
l partage de fichiers (systèmes client- l contrôle d’une chaîne d`assemblage
serveur) l graphiques avec animation

l patrons de communication (protocoles)

l autonomie des ordinateurs

20


Concepts importants du Chapitre
n Processus
u Création, terminaison, hiérarchie
Gestion de Processus n États et transitions d’état des processus
n Process Control Block
n Commutation de processus
Chapitre 3 u Sauvegarde, rechargement de PCB
n Files d’attente de processus et PCB
n Ordonnanceurs à court, moyen, long terme
n Processus communicants
u Producteurs et consommateurs

Processus et terminologie Création de processus
(aussi appelé job, task, user program)

l Concept de processus: un programme en l Les processus peuvent créer d’autres
exécution processus, formant une hiérarchie
l Possède des ressources de mémoire, périphériques, etc
(instruction fork ou semblables)

l Ordonnancement de processus

l Opérations sur les processus

l Processus coopérants

l Processus communicants

21


Terminaison de processus Arbre de processus en UNIX

l Un processus exécute sa dernière
instruction
l pourrait passer des données à son parent
l ses ressources lui sont enlevées
l Le parent termine l’exécution d’un fils
(avortement) pour raisons différentes
l le fils a excédé ses ressources
l le fils n`est plus requis
l etc.

État de processus Diagramme de transition d`états
IMPORTANT d`un processus
l Au fur et a mesure qu’un processus
exécute, il change d’état
l nouveau: le processus vient d ’être créé
l exécutant-running: le processus est en train
d ’être exécuté par l ’UCT
l attente-waiting: le processus est en train
d ’attendre un événement (p.ex. la fin d ’une
opération d ’E/S)
l prêt-ready: le processus est en attente
d’être exécuté par l ’UCT
l terminated: fin d ’exécution
Ordonnanceur = angl. scheduler

22


États Nouveau, Terminé: Transitions entre processus
l Nouveau
l Le SE a créé le processus l Prêt → Exécution
l a construit un identificateur pour le processus
l a construit les tableaux pour gérer le processus
l Lorsque l ’ordonnanceur UCT choisit un
l mais ne s’est pas encore engagé à exécuter le processus pour exécution
processus (pas encore admis) l Exécution → Prêt
l pas encore alloué des ressources
l Résultat d’une interruption causée par un
l La file des nouveaux travaux est souvent appelée
spoule travaux (job spooler) événement indépendant du processus
l Il faut traiter cette interruption, donc le
l Terminé:
processus courant perd l’UCT
l Le processus n ’est plus exécutable, mais ses l Cas important: le processus à épuisé son intervalle de
données sont encore requises par le SE temps (minuterie)
(comptabilité, etc.)

Transitions entre processus Sauvegarde d’informations processus

l En multiprogrammation, un processus exécute sur
l Exécution → Attente l ’UCT de façon intermittente
l Lorsqu’un processus fait un appel de l Chaque fois qu’un processus reprend l ’UCT
système (interruption causée par le processus lui- (transition prêt → exécution) il doit la reprendre dans
même) la même situation où il l’a laissée (même contenu de
registres UCT, etc.)
l initie une E/S: doit attendre le résultat
l Donc au moment où un processus sort de l’état
l a besoin de la réponse d’un autre processus
exécution il est nécessaire de sauvegarder ses
l Attente → Prêt informations essentielles, qu’il faudra récupérer quand
l lorsque l'événement attendu se produit il retourne à cet état

23


PCB = Process Control Block: Process Control Block (PCB)
Représente la situation actuelle d ’un processus, pour le
reprendre plus tard IMPORTANT

l pointeur: les PCBs sont rangés dans des
listes enchaînées (à voir)
l état de processus: ready, running, waiting…

l compteur programme: le processus doit
reprendre à l ’instruction suivante
Registres UCT
l autres registres UCT

l bornes de mémoire

l fichiers qu’il a ouvert

l etc., v. manuel

Commutation de processeur Commutation de processeur
Aussi appelée commutation de contexte ou context switching
(context switching)
l Quand l’UCT passe de l’exécution d ’un
processus 0 à l ’exécution d`un proc 1, il faut
l mettre à jour et sauvegarder le PCB de 0
l reprendre le PCB de 1, qui avait été
sauvegardé avant
l remettre les registres d ’UCT tels que le
compteur d ’instructions etc. dans la même
situation qui est décrite dans le PCB de 1

Il se peut que beaucoup de temps passe avant le retour au
processus 0, et que beaucoup d’autres proc soient exécutés
entre temps

24


Le PCB n ’est pas la seule information à
sauvegarder
La pile d’un processus
l Quand un processus fait appel à une procédure, à une méthode,
l Il faut aussi sauvegarder l ’état des etc., il est nécessaire de mettre dans une pile l’adresse à laquelle
le processus doit retourner après avoir terminé cette procédure,
données du programme méthode, etc.
l Aussi on met dans cette pile les variables locales de la procédure
l Ceci se fait normalement en gardant qu’on quitte, les paramètres, etc., pour les retrouver au retour
l Chaque élément de cette pile est appelé stack frame ou cadre de
l ’image du programme en mémoire pile
primaire ou secondaire (RAM ou disque) l Donc il y a normalement une pile d’adresses de retour après
interruption et une pile d’adresses de retour après appel de
l Le PCB pointera à cette image procédure
l Ces deux piles fonctionnent de façon semblable, mais sont
indépendantes
l Les informations relatives à ces piles (base, pointeur…) doivent
aussi être sauvegardées au moment de la commutation de
contexte

Pointeurs de pile processus à
La Pile d’un processus sauvegarder: base et borne

P
A
B pointeur de borne
Appel A Appel B cadre 4
Données B
cadre 3
Données A cadre 2

Données P
pointeur de base cadre 1

PILE La pile fait normal. partie de l’image du programme, mais les pointeurs sont normal. des
registres d’UCT donc il sont sauvegardés dans le PCB

25


Rôle du matériel et du logiciel dans le
traitement d’interruptions
Files d’attente IMPORTANT
MATÉRIEL LOGICIEL
Infos mises à jour et
l Les ressources d ’ordinateur sont souvent limitées par
sauvegardées dans PCB rapport aux processus qui en demandent
Signal d’interruption généré
l Chaque ressource a sa propre file de processus en
Le code de traitement de attente
l’interruption est exécuté
UCT termine l’instruction courante l À un moment donné, un proc ne peut se trouver que
et détecte interruption
dans une seule des différentes files du SE
L’ordonnanceur choisit un l En changeant d’état, les processus se déplacent
Registres d’UCT sont processus dans la file prêt
sauvegardés dans une pile d ’une file à l`autre
l File prêt: les processus en état prêt=ready
Les infos relatives à ce processus l Files associés à chaque unité E/S
UCT saute à l’adresse trouvée dans sont rétablies à partir de son PCB
le vecteur d’interruption l etc.
dispatcher
Les registres d’UCT sont rechargés
avec ce qu’on avait sauvegardé
dans PCB pour ce processus,
qui reprend l’exécution

Ce sont les PCBs qui sont dans les files d’attente (dont le Cet ensemble de files inclut donc la table de
besoin d ’un pointeur dans le PCB) statut périphériques
file prêt

Nous ferons l’hypothèse que le premier processus dans une file est celui
qui utilise la ressource: ici, proc7 exécute, proc3 utilise disque 0, etc.
2 fois la même erreur ici: imprimante devrait être disque 3

26


Les PCBs ne sont pas déplacés en mémoire pour être mis dans les différentes files:
Une façon plus synthétique de décrire la même ce sont les pointeurs qui changent.
situation (pour les devoirs et les examens)

prêt à 7 à 2
bandmag0 à
bandmag1 à term. unit 0 ready

disq0 à 3 à 14 à 6
. . . PCB2 PCB3 PCB4 PCB5 PCB6 PCB7 . . . PCB14

term0 à 5
disk unit 0

Ordonnanceur travaux = long terme
Ordonnanceurs (schedulers) et ordonnanceur processus = court terme

l Programmes qui gèrent l ’utilisation de Ordonnanceur travaux
ressources de l`ordinateur
l Trois types d`ordonnanceurs :
l À court terme = ordonnanceur processus:
sélectionne quel processus doit exécuter la
transition prêt → exécution
l À long terme = ordonnanceur travaux: Ordonnanceur processus
sélectionne quels processus peuvent
exécuter la transition nouveau → prêt
(événement admitted) (de spoule travaux à file
prêt)
l À moyen terme: nous verrons

27


Ordonnanceurs Ordonnancement de processus (court terme)

l L`ordonnanceur à court terme est exécuté très
souvent (millisecondes)
l doit être très efficace
l L`ordonnanceur à long terme doit être exécuté
beaucoup plus rarement: il contrôle le niveau
de multiprogrammation
l Un des ses critères pourrait être la bonne utilisation
des ressources de l’ordinateur
l P.ex. établir une balance entre travaux liés à l’UCT
et ceux liés à l ’E/S

Disponibilité Ress.

Ordonnanceur à moyen terme Ordonnanceurs à court et moyen terme

l Le manque de ressources peut parfois forcer
moyen
le SE à suspendre des processus
l ils seront plus en concurrence avec les autres pour
des ressources
l ils seront repris plus tard quand les ressources
deviendront disponibles
l Ces processus sont enlevés de mémoire
centrale et mis en mémoire secondaire, pour court
être repris plus tard
l `swap out`, `swap in` , va-et-vien

28


États de processus dans UNIX Processus coopérants
Un exemple de diagramme de transitions d’états pour un SE réel

l Les processus coopérants peuvent
affecter mutuellement leur exécution
l Avantages de la coopération entre
processus:
l partage de l ’information
l efficacité en faisant des tâches en parallèle

l modularité

l la nature du problème pourrait le demander
Kernel, user mode = l P.ex. gestion d’événements indépendants
monitor, user mode l Un proc traite le clavier, un autre traite le modem

Le pb du producteur - consommateur Tampons de communication
l Un problème classique dans l ’étude des processus
Prod Prod
communicants
l un processus producteur produit des données (p.ex.des
enregistrements d ’un fichier) pour un processus
consommateur 1 donn 1 donn 1 donn 1 donn
l un pgm d’impression produit des caractères -- consommés
par une imprimante
l un assembleur produit des modules objet qui seront Cons Cons
consommés par le chargeur
l Nécessité d’un tampon pour stocker les items produits
(attendant d’être consommés Si le tampon est de longueur 1, le producteur et consommateur doivent
forcement aller à la même vitesse
Des tampons de longueur plus grandes permettent une certaine
indépendance. P.ex. à droite le consommateur a été plus lent

29


Le tampon borné (bounded buffer) Utilisation du concept du tampon borné
une structure de données fondamentale dans les SE
bleu: plein, blanc: libre
in: 1ère
b[0] b[1] pos. libre b[0] b[1] b[2] b[3] b[4] b[5] b[6] b[7] l Les tampons bornés sont partout en
b[7] b[2] informatique, et partout dans les SE
b[6] b[3] ou l Les files utilisées dans un SE sont des
in: 1ère out: 1ère
b[5] b[4] pos. libre pos.
pleine
tampons bornés:
out: 1ère
pos. tampon borné
Le pleine se trouve dans la mémoire partagée entre l Files d’attente pour ressources: file prêt,
consommateur et usager files pour imprimante, pour disque, etc.
À l’écriture d’une nouvelle info dans le tampon, le producteur met à l Les protocoles de communications
jour le pointeur in
utilisent des tampons bornés: TCP, et
Si le tampon est plein, le prod devra s’endormir, il sera plus tard
réveillé par le consommateur
autres
Le rôle du consommateur est symétrique l Un client communique avec un serveur
par des tampons bornés, etc.

Aperçu du chapitre

l Concepts de base
Ordonnancement Processus l Critères d’ordonnancement
l Algorithmes d’ordonnancement

Chapitre 4 l Ordonnancement de multiprocesseurs
l Ordonnancement temps réel
l Évaluation d’algorithmes

30


Files d’attente de processus pour ordonnancement
Diagramme de transition d`états d`un processus

file prêt

Nous ferons l’hypothèse que le premier processus dans une file est celui
qui utilise la ressource: ici, proc7 exécute

Concepts de base Les cycles d’un processus

l La multiprogrammation vise à obtenir une
l utilisation optimale des ressources, surtout l’UCT
l et aussi à un bon temps de réponse pour l’usager
l L`ordonnanceur UCT est la partie du SE qui
décide quel processus dans la file ready/prêt
obtient l ’UCT quand elle devient libre
l L ’UCT est la ressource la plus précieuse dans
un ordinateur, donc nous parlons d’elle
l Cependant, les principes que nous verrons l Cycles (bursts) d’UCT et E/S: l’exécution d’un
s ’appliquent aussi à l ’ordonnancement des autres processus consiste de séquences d’exécution sur
ressources (unités E/S, etc). UCT et d’attentes E/S

31


Histogramme de durée des cycles UCT Quand invoquer l’ordonnanceur UCT

l L ’ordonnanceur UCT doit prendre sa décision chaque fois que
le processus exécutant est interrompu, c’e-à.-d.
1. un processus se se présente en tant que nouveau ou se termine
2. un processus exécutant devient bloqué en attente
3. un processus change d’exécutant/running à prêt/ready
4. un processus change de attente à prêt/ready
• en conclusion, tout événement dans un système cause une interruption
de l’UCT et l’intervention de l’ordonnanceur,
l Observation expérimentale: • qui devra prendre une décision concernant quel proc ou thread aura
l dans un système typique, nous observerons un grand nombre de court cycles, et un l’UCT après
petit nombre de long cycles
l Les programmes tributaires de l ’UCT auront normalm. un petit nombre de long l Préemption: on a préemption si on enlève l’UCT à un processus
cycles UCT qui l’avait et ne l’a pas laissée de propre initiative
l Les programmes tributaires de l’E/S auront normalm. un grand nombre de court l P.ex. préemption dans le cas 3, pas de préemption dans le cas 2
cycles UCT l Plusieurs pbs à résoudre dans le cas de préemption, v. manuel

Dispatcheur
Critères d’ordonnancement
l Le processus qui donne le contrôle au l Il y aura normalement plusieurs processus dans la file prêt
processus choisi par l’ordonnanceur. Il doit se
préoccuper de: l Quand l’UCT devient disponible, lequel choisir?
l changer de contexte
l Critères généraux:
l changer à mode usager
l Bonne utilisation de l’UCT
l réamorcer le processus choisi l Réponse rapide à l’usager
l Attente de dispatcheur (dispatcher latency)
l le temps nécessaire pour exécuter les fonctions du l Mais ces critères peuvent être jugés différemment...
dispatcheur
l il est souvent négligé, il faut supposer qu’il soit petit
par rapport à la longueur d’un cycle

32


Critères d’ordonnancement:
Critères spécifiques d’ordonnancement maximiser/minimiser
l Utilisation UCT: pourcentage d’utilisation
l Utilisation UCT: pourcentage d ’utilisation
l ceci est à maximiser
l Débit = Throughput: nombre de processus qui l Débit = Throughput: nombre de processus qui complètent dans
complètent dans l ’unité de temps l ’unité de temps
l ceci est à maximiser
l Temps de rotation = turnaround: le temps pris l Temps de rotation (turnaround): temps terminaison moins temps
par le proc de son arrivée à sa termin. arrivée
l à minimiser
l Temps d’attente: attente dans la file prêt
l Temps d’attente: attente dans la file prêt
(somme de tout le temps passé en file prêt) l à minimiser
l Temps de réponse (pour les systèmes l Temps de réponse (pour les systèmes interactifs): le temps entre
une demande et la réponse
interactifs): le temps entre une demande et la
l à minimiser
réponse

Premier arrive, premier servi (First
come, first serve, FCFS)
Exemple: Processus Temps de cycle
P1 24
P2 3
P3 3
Examinons maintenant plusieurs méthodes Si les processus arrivent au temps 0 dans l’ordre: P1 , P2 , P3
d’ordonnancement et voyons comment elles se Le diagramme Gantt est:
comportent par rapport à ces critères
P1 P2 P3

0 24 27 30

Temps d’attente pour P1= 0; P2= 24; P3= 27
Temps attente moyen: (0 + 24 + 27)/3 = 17

33


Premier arrive, premier servi Tenir compte du temps d’arrivée!

l Utilisation UCT = 100% l Dans le cas où les processus arrivent à moment
différents, il faut soustraire les temps d’arrivée
l Débit = 3/30 = 0,1
l Exercice: répéter les calculs si:
l 3 processus complétés en 30 unités de temps
l P1 arrive à temps 0 et dure 24
l Temps de rotation moyen: (24+27+30)/3 = 27 l P2 arrive à temps 2 et dure 3
l P3 arrive à temps 5 et dure 3
P1 P2 P3 l Donc P1 attend 0 comme avant
l Mais P2 attend 24-2, etc.
0 24 27 30
P1 P2 P3

0 24 27 30
arrivée P2

Effet d’accumulation (convoy effect) dans
FCFS Scheduling (Cont.) FCFS
Si les mêmes processus arrivent à 0 mais dans l’ordre
l Supposons un processus tributaire de l’UCT et plusieurs
P2 , P3 , P1 . tributaires de l`E/S (situation assez normale)
Le diagramme de Gantt est:
l Les processus tributaires de l’E/S attendent pour l ’UCT: E/S
P2 P3 P1 sous-utilisée (*)
l Le processus tributaire de l’UCT fait une E/S: les autres proc
0 3 6 30 exécutent rapidement leur cycle UCT et retournent sur l’attente
E/S: UCT sous-utilisée
l Processus tributaire de l’UCT fini son E/S, puis les autres procs
l Temps d’attente pour P1 = 6 P2 = 0 P3 = 3 aussi : retour à la situation (*)
l Temps moyen d’attente: (6 + 0 + 3)/3 = 3
l Donc dans ce sens FCFS favorise les procs tributaires de l’UCT
l Temps de rotation moyen: (3+6+30)/3 = 13
l Et peut conduire à une très mauvaise utilisation des ressources
l Beaucoup mieux! l Tant d’UCT que de périphériques
l Donc pour cette technique, les temps peuvent varier grandement l Une possibilité: interrompre de temps en temps les proc
par rapport à l’ordre d’arrivée de différent processus tributaires de l’UCT pour permettre aux autres procs d’exécuter
l Exercice: calculer aussi le débit, etc. (préemption)

34


Plus Court d’abord = Shortest Job First (SJF) SJF avec préemption ou non

l Le processus qui demande moins l Avec préemption: si un processus qui dure
moins que le restant du processus courant se
d’UCT part le premier présente plus tard, l’UCT est enlevée au proc
l Optimal en principe du point de vue courant et donnée à ce nouveau processus
du temps d’attente moyen l SRTF: shortest remaining-time first
l Sans préemption: on permet au processus
l (v. le dernier exemple) courant de terminer son cycle
l Mais comment savons-nous quel l Observation: SRTF est logique pour l’UCT car le processus
exécutant sera interrompu par l’arrivée du nouveau processus
processus demande moins d’UCT! l Il est retourné à l’état prêt
l Il est impossible pour les unités qui ne permettent pas de préemption
l p.ex. une unité disque, imprimante…

Example de SJF sans préemption Exemple de SJF avec préemption
Processus Arrivée Cycle
Processus Arrivée Cycle P1 0 7
P1 0 7 P2 2 4
P2 2 4
P3 4 1
P3 4 1
P4 5 4
P4 5 4
l SJF (préemptive)
l SJF (sans préemption) P1 P2 P3 P2 P4 P1
P1 P3 P2 P4
0 2 4 5 7 11 16
0 3 7 8 12 16
P2 arr. P3 arr.
P4 arr
P2 arr. P3 arr.
P4 arr l Temps moyen d`attente = (9 + 1 + 0 +2)/4 = 3
l P1 attend de 2 à 11, P2 de 4 à 5, P4 de 5 à 7
l Temps d’attente moyen = (0+(8-2)+(7-4)+(12-5))/4
l (0 + 6 + 3 + 7)/4 = 4 l Temps de rotation moyen = 16+ (7-2) + (5-4) + (11-5) = 7
l Temps de rotation moyen = 7+(12-2)+(8-4)+(16-5) = 8

35


Tourniquet = Round-Robin (RR)
Le plus utilisé en pratique
Performance de tourniquet
l Chaque processus est alloué une tranche de temps l S ’il y a n processus dans la file prêt et la
(p.ex. 10-100 millisecs.) pour exécuter
l Tranche aussi appelée quantum
tranche est t, alors chaque processus
l S’il exécute pour tranche entière sans autres interruptions, reçoit 1/n du temps UCT dans unités de
il est interrompu par la minuterie et l ’UCT est donnée durée max. t
à un autre processus
l Si t grand ⇒ FIFO
l Le processus interrompu redevient prêt (à la fin de la file)
l Méthode préemptive l Si t petit... nous verrons
P[0] P[1]
La file prêt est un
P[7] P[2]
cercle (dont RR)
P[6] P[3]

P[5] P[4]

Exemple: Tourniquet tranche = 20 Priorités
Processus Cycle
P1
P2
53
17
l Affectation d’une priorité à chaque
P3 68 processus (p.ex. un nombre entier)
P4 24
l souvent les petits chiffres dénotent des
P1 P2 P3 P4 P1 P3 P4 P1 P3 P3 hautes priorités
l 0 la plus haute
0 20 37 57 77 97 117 121 134 154 162
l Observez l L’UCT est donnée au processus prêt
l temps de rotation et temps d’attente moyens beaucoup plus élevés que SJF

l mais aucun processus n’est favorisé
avec la plus haute priorité
l avec ou sans préemption
l il y a une file prêt pour chaque priorité

36


Problème possible avec les priorités Files à plusieurs niveaux (multiples)

l Famine: les processus moins prioritaires l La file prêt est séparée en plusieurs files, p.ex.
l travaux `d’arrière-plan` (background - batch)
n’arrivent jamais à exécuter l travaux `de premier plan` (foreground - interactive)
l Solution: vieillissement: l Chaque file a son propre algorithme d ’ordonnancement,
p.ex.
l modifier la priorité d ’un processus en l FCFS pour arrière-plan
fonction de son âge et de son historique l tourniquet pour premier plan
d ’exécution l Comment ordonnancer entre files?
l le processus change de file d`attente l Priorité fixe à chaque file → famine possible, ou

l Chaque file reçoit un certain pourcentage de temps UCT,
l Plus en général, la modification p.ex.
dynamique des priorités est une politique l 80% pour arrière-plan
l 20% pour premier plan
souvent utilisée (v. files à rétroaction ou retour)

Ordonnancement avec files multiples Files multiples et à retour

l Un processus peut passer d ’une file à
l ’autre, p.ex. quand il a passé trop de
temps dans une file
l À déterminer:
l nombre de files
l algorithmes d ’ordonnancement pour chaque file
l algorithmes pour décider quand un proc doit passer
d ’une file à l`autre
l algorithme pour déterminer, pour un proc qui
devient prêt, sur quelle file il doit être mis

37


Exemple de files multiples à
Files multiples et à retour
retour
PRIO = 0 l Trois files:
la + élevée l Q0: tourniquet, tranche = 8 msecs
l Q1: tourniquet, tranche = 16 msecs
l Q2: FCFS
l Ordonnancement:
PRIO = 1 l Un nouveau processus entre dans Q0, il reçoit 8 msecs
d ’UCT
l S ’il ne finit pas dans les 8 msecs, il est mis dans Q1, il reçoit
16 msecs additionnels
l S ’il ne finit pas encore, il est interrompu et mis dans Q2
PRIO = 2 l Si plus tard il commence à avoir des cycles plus courts, il
pourrait retourner à Q0 ou Q1

En pratique... Aussi…
l Les méthodes que nous avons vu sont toutes utilisées l Notre étude des méthodes d’ordonnancement est théorique, ne
en pratique (sauf plus court servi pur qui est considère pas en détail tous les problèmes qui se présentent
impossible) dans l’ordonnancement UCT
l Les SE sophistiqués fournissent au gérant du système l P.ex. les ordonnanceurs UCT ne peuvent pas donner l’UCT à un
une librairie de méthodes, qu’il peut choisir et processus pour tout le temps dont il a besoin
combiner au besoin après avoir observé le l Car en pratique, l’UCT sera souvent interrompue par quelque

comportement du système événement externe avant la fin de son cycle
l Cependant les mêmes principes d’ordonnancement s’appliquent
l Pour chaque méthode, plusieurs params sont à unités qui ne peuvent pas être interrompues, comme une
disponibles: p.ex. durée des tranches, coefficients, imprimante, une unité disque, etc.
etc.
l Dans le cas de ces unités, on pourrait avoir des infos complètes
l Ces méthodes évidemment sont importantes concernant le temps de cycle prévu, etc.
seulement pour les ordis qui ont des fortes charges de l Aussi, cette étude ne considère pas du tout les temps d’exécution
travail de l’ordonnanceur, du dispatcheur, etc.

38


Systèmes temps réel:
Systèmes temps réel Problèmes d’attente dans plus. systèmes (ex. UNIX)
l systèmes temps réel rigides (hard):
l les échéances sont critiques (p.ex. contrôle d’une chaîne
l Dans UNIX ‘classique’ il n ’est pas permis d ’effectuer
d`assemblage, animation graphique) changement de contexte pendant un appel du
l il est essentiel de connaître la durée des fonctions système - et ces appels peuvent être longs
critiques l Pour le temps réel il est nécessaire de permettre la
l il doit être possible de garantir que ces fonctions sont
préemption des appels de systèmes ou du noyau en
effectivement exécutées dans ce temps (réservation de
ressources)
général
l ceci demande une structure de système très particulière l Donc ce système n’est pas considéré approprié pour
l systèmes temps réel souples (soft): le temps réel
l les échéances sont importantes, mais ne sont pas l Mais des variétés appropriées de UNIX ont été
critiques (p.ex. systèmes téléphoniques) conçues (p.ex. Solaris)
l les processus critiques reçoivent la priorité

Inversion de priorité et héritage de
priorités

l Quand un processus de haute priorité Synchronisation de Processus
doit attendre pour des processus de
moindre priorité (p.ex. a besoin de données
produites par ces derniers)
Chapitre 5
l Pour permettre à ces derniers de finir
rapidement, on peut lui faire hériter la
priorité du processus plus prioritaire

39


Problèmes avec concurrence = Un exemple
parallélisme
l Deux threads exécutent M. X demande une
l Les threads concurrents doivent parfois cette même procédure et réservation
partager données (fichiers ou mémoire partagent la même base d’avion
commune) et ressources de données
l On parle donc de tâches coopératives Base de données
l Ils peuvent être dit que fauteuil
l Si l’accès n’est pas contrôlé, le résultat de interrompus n’importe où A est disponible
l’exécution du programme pourra dépendre de
l Le résultat de
l’ordre d’entrelacement de l’exécution des Fauteuil A est
l ’exécution concurrente assigné à X et
instructions (non-déterminisme).
de P1 et P2 dépend de marqué occupé
l Un programme pourra donner des résultats l`ordre de leur
différents et parfois indésirables de fois en fois entrelacement

Vue globale d’une exécution Deux opérations en parallèle sur une var a partagée
(b est privé à chaque processus)
possible
P1 P2 P1 P2
Interruption interruption
M. Leblanc demande une ou retard b=a
réservation d’avion
M. Guy demande une
b=a
b++
Base de données dit
que fauteuil 30A est
a=b
disponible Base de données dit
que fauteuil 30A est
disponible
b++
a=b
Fauteuil 30A est Fauteuil 30A est
assigné à Leblanc et assigné à Guy et Supposons que a soit 0 au début
marqué occupé marqué occupé P1 travaille sur le vieux a donc le résultat final sera a=1.
Sera a=2 si les deux tâches sont exécutées l’une après l’autre
Si a était sauvegardé quand P1 est interrompu, il ne pourrait pas être partagé avec P2 (il y aurait deux
a tandis que nous en voulons une seule)

40


3ème exemple Autres exemples
Thread P1 Thread P2
Des threads qui travaillent en simultanéité sur une
static char a; static char a; matrice, par ex. un pour la mettre à jour, làutre pour
en extraire des statistiques
void echo() void echo()
{ { l Problème qui affecte le programme du tampon borné,
cin >> a; v. manuel
cin >> a;
cout << a; l Quand plusieurs threads exécutent en parallèle, nous ne pouvons
} pas faire d’hypothèses sur la vitesse d’exécution des threads, ni
cout << a; leur entrelacement
l Peuvent être différents à chaque exécution du programme
}
Si la var a est partagée, le premier a est effacé
Si elle est privée, l’ordre d’affichage est renversé

Section Critique Le problème de la section critique
l Lorsqu’un thread manipule une donnée (ou ressource) partagée, nous
disons qu’il se trouve dans une section critique (SC) (associée à cette
donnée)
l Le problème de la section critique est de trouver un algorithme
l Partie d’un programme dont l’exécution dèxclusion mutuelle de threads dans lèxécution de leur SCs afin que le
résultat de leurs actions ne dépendent pas de l’ordre d’entrelacement
de doit pas entrelacer avec autres de leur exécution (avec un ou plusieurs processeurs)
programmes l L’exécution des sections critiques doit être mutuellement exclusive: à
tout instant, un seul thread peut exécuter une SC pour une var donnée
(même lorsqu’il y a plusieurs processeurs)
l Ceci peut être obtenu en plaçant des instructions spéciales dans les
sections dèntrée et sortie
l Une fois qu’un tâche y entre, il faut lui l Pour simplifier, dorénavant nous faisons l’hypothèse qu’il n’y a q’une
permettre de terminer cette section sans seule SC dans un programme.

permettre à autres tâches de jouer sur les
mêmes données

41


Structure du programme Application
l Chaque thread doit donc demander une permission
M. X demande une
avant d’entrer dans une section critique (SC)
l La section de code qui effectue cette requête est la
section d’entrée Section d’entrée
l La section critique est normalement suivie d’une
section de sortie Base de données dit que
l Le code qui reste est la section restante (SR): non-
repeat fauteuil A est disponible
Section
critique section d’entrée critique Fauteuil A est assigné à X et
section critique
section de sortie marqué occupé
section restante
forever Section de sortie

Critères nécessaires pour solutions Critères nécessaires pour
valides solutions valides
l Exclusion Mutuelle
l À tout instant, au plus un thread peut être dans une
section critique (SC) pour une variable donnée
l Progrès:
l Non interférence:
l absence d`interblocage (Chap 8)
l Si un thread s’arrête dans sa section restante, ceci
ne devrait pas affecter les autres threads l si un thread demande d`entrer dans une
l Mais on fait l ’hypothèse qu’un thread qui section critique à un moment où aucun
entre dans une section critique, en sortira. autre thread en fait requête, il devrait être
en mesure d’y entrer

42


Aussi nécessaire Types de solutions

l Solutions par logiciel
l des algorithmes dont la validité ne s’appuie pas sur
l’existence d`instruction spéciales
l Solutions fournies par le matériel
l Absence de famine: aucun thread l s’appuient sur l’existence de certaines instructions (du
processeur) spéciales
éternellement empêché d’atteindre sa l Solutions fournies pas le SE
l procure certains appels du système au programmeur
SC
l Toutes les solutions se basent sur l’atomicité de l’accès à la
mémoire centrale: une adresse de mémoire ne peut être affectée
que par une instruction à la fois, donc par un thread à la fois.
l Difficile à obtenir, nous verrons… l Plus en général, toutes les solutions se basent sur l ’existence
d’instructions atomiques, qui fonctionnent comme SCs de base

Atomicité = indivisibilité

Solutions par logiciel Algorithme 1: threads se donnent mutuellement le tour
(pas pratiques, mais intéressantes pour comprendre le pb)

l La variable partagée turn est
l Nous considérons d’abord 2 threads initialisée à 0 ou 1
l Algorithmes 1 et 2 ne sont pas valides l La SC de Ti est exécutée ssi Thread Ti:
l Montrent la difficulté du problème turn = i repeat
l Algorithme 3 est valide (algorithme de Peterson) l Ti est occupé à attendre si Tj while(turn!=i);
est dans SC. SC
l Fonctionne pour l’exclusion turn = j;
l Notation mutuelle! SR Rien
l Débutons avec 2 threads: T0 et T1 l Mais critère du progrès n’est forever faire
l Lorsque nous discutons de la tâche Ti, Tj dénotera toujours pas satisfait car l’exécution
l’autre tâche (i != j) des SCs doit strictement
alterner
Ex 1: T0 possède une longue SR et T1 possède une courte SR. Si turn==0, T0 entre
dans sa SC et puis sa SR (turn==1). T1 entre dans sa SC et puis sa SR (turn==0), et
tente d’entrer dans sa SC: refusée! il doit attendre que T0 lui donne le tour.

43


initialisation de turn à 0 ou 1 Algorithme 2 ou l’excès de courtoisie...
Thread T0: Thread T1: l Une variable Booléenne par
repeat repeat Thread: flag[0] et flag[1]
l Ti signale qu’il désire exécuter Thread Ti:
while(turn!=0); while(turn!=1); sa SC par: flag[i] =vrai repeat
SC SC l Mais il n’entre pas si l’autre est flag[i] = vrai;
turn = 1; turn = 0; aussi intéressé!
while(flag[j]);
SR SR l Exclusion mutuelle ok
Rien SC
forever forever l Progrès satisfait:
faire flag[i] = faux;
l Considérez la séquence:
SR
Algorithme 1 vue globale l T0: flag[0] = vrai forever rien faire
l T1: flag[1] = vrai
Ex 2: Généralisation à n threads: chaque fois, avant qu’un thread puisse rentrer dans l Chaque thread attendra
sa section critique, il lui faut attendre que tous les autres aient eu cette chance! indéfiniment pour exécuter
sa SC: on a un
interblocage

Algorithme 3 (dit de Peterson): bon!
Après vous, monsieur
Après vous, monsieur
combine les deux idées: flag[i]=intention d’entrer; turn=à qui le tour

Thread T0: Thread T1:
repeat repeat
l Initialisation: Thread Ti:
flag[0] = vrai; flag[1] = vrai;
repeat
while(flag[1]); while(flag[0]); l flag[0] = flag[1] = faux
flag[i] = vrai;
SC SC l turn = i ou j // je veux entrer
flag[0] = faux; flag[1] = faux; turn = j;
SR SR l Désire d’exécuter SC // je donne une chance à l’autre
forever forever est indiqué par flag[i] = do while
vrai (flag[j] && turn==j);
SC
Algorithme 2 vue globale l flag[i] = faux à la section flag[i] = faux;
de sortie SR
T0: flag[0] = vrai forever
T1: flag[1] = vrai
interblocage!

44


Entrer ou attendre? Thread T0: Thread T1:
repeat repeat
flag[0] = vrai; flag[1] = vrai;
// T0 veut entrer // T1 veut entrer
turn = 1; turn = 0;
l Thread Ti attend si: // T0 donne une chance à T1 // T1 donne une chance à 0
l Tj veut entrer est c’est la chance à Tj while while
(flag[1]&&turn=1); (flag[0]&&turn=0);
l flag[j]==vrai et turn==j
SC SC
flag[0] = faux; flag[1] = faux;
// T0 ne veut plus entrer // T1 ne veut plus entrer
l Un thread Ti entre si: SR SR
l Tj ne veut pas entrer ou c’est la chance à Ti forever forever
l flag[j]==faux ou turn==i
Algorithme de Peterson vue globale
l Pour entrer, un thread dépend de l’autre qu’il
lui donne la chance!

Scénario pour le changement de Autre scénario de changem. de
contrôle contrôle
… … SC
flag[0] = faux;
SC flag[1] = vrai;
// T0 ne veut plus entrer flag[1] = vrai;
flag[0] = faux; // T1 veut entrer
SR // T1 veut entrer
// T0 ne veut plus entrer turn = 0;
flag[0] = vrai; turn = 0;
SR // T1 donne une chance à T0
// T0 veut entrer // T1 donne une chance à T0
while
… (flag[0]&&turn=0) ;
turn = 1; // mais T0 annule cette action
// T0 donne une chance à T1
//test faux, entre while
while
(flag[0]&&turn=0) ;
… (flag[1]==vrai&&turn=1) ;
//test faux, entre
// test vrai, n’entre pas
T1 prend la relève, donne une chance à T0 mais T0 a dit
qu’il ne veut pas entrer.
T1 entre donc dans la SC T0 veut rentrer mais est obligé de donner une chance à T1, qui entre

45


Mais avec un petit décalage, Donc cet algo. n’oblige pas une tâche d’attendre pour
d’autres qui pourraient ne pas avoir besoin de la SC
c’est encore T0!
Thread T0:
Thread T1:
SC
Supposons que T0 soit le seul à avoir besoin de la SC, ou que T1 soit
flag[0] = faux; lent à agir: T0 peut rentrer de suite (flag[1]==faux la dernière fois que T1
// 0 ne veut plus entrer
est sorti)
RS flag[0] = vrai // prend l’initiative
flag[0] = vrai;
// 0 veut entrer turn = 1 // donne une chance à l’autre
flag[1] = vrai;
turn = 1;
// 1 veut entrer while flag[1] && turn=1 //test faux, entre
// 0 donne une chance à 1
// mais T1 annule cette action
turn = 0;
// 1 donne une chance à 0 SC
while while
(flag[1] && turn=1) ; (flag[0]&&turn=0); flag[0] = faux // donne une chance à l’autre
// test faux, entre // test vrai, n’entre pas
Si T0 et T1 tentent simultanément d’entrer dans SC, seule une valeur pour turn
survivra: Cette propriété est désirable, mais peut causer famine pour T1
non-déterminisme (on ne sait pas qui gagnera), mais l’exclusion fonctionne

Algorithme 3: preuve de validité
(pas matière d’examen, seulement pour les intéressés…)
Algorithme 3: preuve de validité (cont.)
l Exclusion mutuelle est assurée car:
l Si Tj a effectué flag[ j]=vrai et se trouve dans le
l T0 et T1 sont tous deux dans SC seulement si while(), alors turn==i ou turn==j
turn est simultanément égal à 0 et 1 l Si
(impossible) l turn==i, alors Ti entre dans SC.
l turn==j alors Tj entre dans SC mais il fera flag[ j]
l Démontrons que progrès et attente limitée =false à la sortie: permettant à Ti d’entrer CS
sont satisfaits: l mais si Tj a le temps de faire flag[ j]=true, il devra
l Ti ne peut pas entrer dans SC seulement si en aussi faire turn=i
attente dans la boucle while() avec condition: l Puisque Ti ne peut modifier turn lorsque dans le
while(), Ti entrera SC après au plus une entrée
flag[ j] == vrai and turn = j. dans SC par Tj (attente limitée)
l Si Tj ne veut pas entrer dans SC alors flag[ j] =
faux et Ti peut alors entrer dans SC

46


A propos de l’échec des threads Extension à >2 threads
l Si une solution satisfait les 3 critères (EM, progrès et
attente limitée), elle procure une robustesse face à L ’algorithme de Peterson peut être
l’échec d’un thread dans sa section restante (SR) généralisé au cas de >2 threads
l un thread qui échoue dans sa SR est comme un thread
ayant une SR infiniment longue... l Cependant, dans ce cas il y a des
l Par contre, aucune solution valide ne procure une algorithmes plus élégants, comme
robustesse face à l'échec d’un thread dans sa section l’algorithme du boulanger, basée sur
critique (SC)
l un thread Ti qui échoue dans sa SC n’envoie pas de
l’idée de ‘prendre un numéro au
signal aux autres threads: pour eux Ti est encore dans comptoir’...
sa SC...
l Pas le temps d’en parler…

Une leçon à retenir… Critique des solutions par logiciel

l À fin que des threads avec des variables l Difficiles à programmer! Et à comprendre!
partagées puissent réussir, il est l Les solutions que nous verrons dorénavant sont
toutes basées sur l’existence d’instructions
nécessaire que tous les threads spécialisées, qui facilitent le travail.
impliqués utilisent le même algorithme
de coordination
l Les threads qui requièrent l’entrée dans leur
l Un protocole commun SC sont occupés à attendre (busy waiting);
consommant ainsi du temps de processeur
l Pour de longues sections critiques, il serait
préférable de bloquer les threads qui doivent
attendre...

47


Solutions matérielles: Solutions matérielles: instructions
désactivation des interruptions machine spécialisées
l Sur un uniprocesseur: l Normal: pendant qu’un thread ou processus
exclusion mutuelle est
préservée mais l’efficacité fait accès à une adresse de mémoire, aucun
se détériore: lorsque dans Process Pi: autre ne peut faire accès à la même adresse
SC il est impossible repeat
d’entrelacer l’exécution
en même temps
inhiber interrupt
avec d’autres threads dans l Extension: instructions machine exécutant
une SR section critique
rétablir interrupt plusieurs actions (ex: lecture et écriture) sur la
l Perte d’interruptions
l Sur un multiprocesseur: section restante même case de mémoire de manière atomique
exclusion mutuelle n’est pas forever (indivisible)
préservée
l Une instruction atomique ne peut être
l Une solution qui n’est
généralement pas exécutée que par un thread à la fois (même en
acceptable présence de plusieurs processeurs)

L’instruction test-and-set L’instruction test-and-set (cont.)
l Un algorithme utilisant
testset pour Exclusion
l Une version C de Mutuelle: l Exclusion mutuelle est assurée: si Ti entre
test-and-set: l Variable partagée b dans SC, l’autre Tj est occupé à attendre
bool testset(int& i) est initialisée à 0
{ l Problème: utilise encore occupé à attendre
l Le 1er Pi qui met b à
if (i==0) { 1 entre dans SC l Peut procurer facilement l’exclusion
i=1;
return true;
Tâche Pi: mutuelle mais nécessite algorithmes plus
while testset(b)==false ;
} else { SC //entre quand vrai complexes pour satisfaire les autres
return false; b=0; exigences du problème de la section
} SR
critique
}
l Lorsque Ti sort de SC, la sélection du Tj
Instruction atomique! qui entrera dans SC est arbitraire: pas de
limite sur l’attente: possibilité de famine

48


Utilisation de xchg pour exclusion
Instruction ‘Échange’ mutuelle (Stallings)
l Variable partagée b est initialisée usage:
à0
l Certains UCTs (ex: Pentium) offrent une l Chaque Ti possède une variable
instruction xchg(a,b) qui interchange le locale k Thread Ti:
l Le Ti pouvant entrer dans SC est repeat
contenue de a et b de manière atomique. celui qui trouve b=0 k = 1
l Mais xchg(a,b) souffre des même lacunes l Ce Ti exclue tous les autres en
assignant b à 1 while k!=0 xchg(k,b);
que test-and-set l Quand SC est occupée, k et b SC
seront 1 pour un autre thread xchg(k,b);
qui cherche à entrer SR
l Mais k est 0 pour le thread qui
est dans la SC
forever

Solutions basées sur des instructions Sémaphores
fournies par le SE (appels du système)
l Les solutions vues jusqu’à présent sont l Un sémaphore S est un entier qui, sauf pour
difficiles à programmer et conduisent à du l'Initialisation, est accessible seulement par ces 2
mauvais code. opérations atomiques et mutuellement exclusives:
l wait(S) (appelé P dans le livre)
l On voudrait aussi qu`il soit plus facile d’éviter
l signal(S) (appelé V dans le livre)
des erreurs communes, comme interblocages,
famine, etc. l Il est partagé entre tous les procs qui
l Besoin d’instruction à plus haut niveau s`intéressent à la même section critique
l Les méthodes que nous verrons dorénavant l Les sémaphores seront présentés en deux
utilisent des instructions puissantes, qui sont étapes:
implantées par des appels au SE (system l sémaphores qui sont occupés à attendre (busy waiting)
calls) l sémaphores qui utilisent des files d ’attente
l On fait distinction aussi entre sémaphores compteurs
et sémaphores binaires, mais ce derniers sont moins
puissants (v. livre).

49


Spinlocks d’Unix: Sémaphores occupés à attendre
(busy waiting) Atomicité
l La façon la plus simple wait(S): Wait: La séquence test-
d’implanter les sémaphores. while S=0 ; décrément est atomique,
l Utiles pour des situations où S--; mais pas la boucle!
l’attente est brève, ou il y a V
beaucoup d’UCTs Attend si no. de threads qui
Signal est atomique. S=0
l S est un entier initialisé à une peuvent entrer = 0
F
valeur positive, de façon que Rappel: les sections atomiques ne
un premier thread puisse peuvent pas être exécutées atomique S--
entrer dans la SC signal(S): simultanément par différent threads
l Quand S>0, jusqu’à n threads S++;
(ceci peut être obtenu un utilisant un des
peuvent entrer mécanismes précédents) SC
l S ne peut pas être négatif Augmente de 1 le no des threads qui
peuvent entrer

Utilisation des sémaphores pour
Atomicité et interruptibilité SC
sections critiques

interruptible S++ autre thr.
Thread Ti:
V l Pour n threads
S=0 repeat
l Initialiser S à 1 wait(S);
F SC
l Alors 1 seul thread
S-- peut être dans sa SC signal(S);
atomique
SR
l Pour permettre à k forever
threads d’exécuter
SC
SC, initialiser S à k
La boucle n’est pas atomique pour permettre à un autre thread
d’interrompre l’attente sortant de la SC

50


Initialise S à >=1
Utilisation des sémaphores pour
synchronisation de threads
repeat repeat l On a 2 threads: T1 l Synchronisation
wait(S); wait(S); et T2 correcte lorsque T1
SC SC contient:
signal(S); l Énoncé S1 dans T1
signal(S);
SR SR doit être exécuté S1;
forever forever avant énoncé S2 signal(S);
dans T2
l Définissons un l et que T2 contient:
Semaphores: vue globale sémaphore S wait(S);
l Initialiser S à 0 S2;
Peut être facilement généralisé à plus. threads

Interblocage et famine avec les wait(S):
Sémaphores: observations
while S=0 ;
sémaphores S--;
l Famine: un thread peut n’arriver jamais
à exécuter car il ne teste jamais le l Quand S >= 0:
sémaphore au bon moment l Le nombre de threads qui peuvent exécuter
l Interblocage: Supposons S et Q wait(S) sans devenir bloqués = S
S threads peuvent entrer dans la SC
initialisés à 1 l

l noter puissance par rapport à mécanismes déjà vus
T0 T1 l dans les solutions où S peut être >1 il faudra avoir un 2ème
sém. pour les faire entrer un à la fois (excl. mutuelle)
wait(S)
wait(Q)
l Quand S devient > 1, le thread qui entre
le premier dans la SC est le premier à
tester S (choix aléatoire)
wait(Q) wait(S)
l ceci ne sera plus vrai dans la solution
suivante

51


Comment éviter l’attente occupée et le Sémaphores sans attente
choix aléatoire dans les sémaphores occupée
l Un sémaphore S devient une structure de données:
l Quand un thread doit attendre qu’un l Une valeur
sémaphore devienne plus grand que 0, il est l Une liste d’attente L
mis dans une file d’attente de threads qui
l Un thread devant attendre un sémaphore S, est bloqué et ajouté
attendent sur le même sémaphore. la file d’attente S.L du sémaphore (v. état bloqué = attente chap 4).
l Les files peuvent être PAPS (FIFO), avec
priorités, etc. Le SE contrôle l`ordre dans
lequel les threads entrent dans leur SC.
l wait et signal sont des appels au SE comme
les appels à des opérations d’E/S.
l signal(S) enlève (selon une politique juste, ex: PAPS/FIFO) un
l Il y a une file d ’attente pour chaque thread de S.L et le place sur la liste des threads prêts/ready.
sémaphore comme il y a une file d’attente
pour chaque unité d’E/S.

Implementation
(les boîtes réprésentent des séquences non-interruptibles)
Figure montrant la relation
wait(S): S.value --; entre le contenu de la file et
if S.value < 0 { // SC occupée la valeur de S
add this thread to S.L; (Stallings)
block // thread mis en état attente
(wait)

}

Quand S < 0: le nombre
signal(S): S.value ++; de threads qui attendent
if S.value ≤ 0 { // des threads attendent
sur S est = |S|

remove a process P from S.L;
wakeup(P) // thread choisi devient prêt
S.value doit être initialisé à une valeur non-négative (dépendant de l’application,
v. exemples) }

52


Wait et signal contiennent elles Problèmes classiques de
mêmes des SC! synchronisation
l Les opérations wait et signal doivent être
exécutées atomiquement (un seul thr. à la
fois)
l Dans un système avec 1 seule UCT, ceci peut
l Tampon borné (producteur-
être obtenu en inhibant les interruptions quand consommateur)
un thread exécute ces opérations l Écrivains - Lecteurs
l Normalement, nous devons utiliser un des l Les philosophes mangeant
mécanismes vus avant (instructions spéciales,
algorithme de Peterson, etc.)
l L’attente occupée dans ce cas ne sera pas
trop onéreuse car wait et signal sont brefs

Le pb du producteur - consommateur Tampons de communication

Prod Prod
n Un problème classique dans l ’étude des
threads communicants
u un thread producteur produit des données 1 donn 1 donn 1 donn 1 donn
(p.ex.des enregistrements d ’un fichier) pour un
thread consommateur Cons Cons

Si le tampon est de longueur 1, le producteur et consommateur
doivent forcement aller à la même vitesse
Des tampons de longueur plus grandes permettent une certaine
indépendance. P.ex. à droite le consommateur a été plus lent

53


Le tampon borné (bounded buffer) Pb de sync entre threads pour le tampon borné
une structure de données fondamentale dans les SE

in: 1ère n Étant donné que le prod et le
b[0] b[1] pos. libre b[0] b[1] b[2] b[3] b[4] b[5] b[6] b[7] consommateur sont des threads
b[7] b[2]
indépendants, des problèmes pourraient
b[6] b[3] ou se produire en permettant accès simultané
in: 1ère out: 1ère
b[5] b[4] pos. libre pos.
pleine
au tampon
out: 1ère bleu: plein, blanc: libre
pos. pleine n Les sémaphores peuvent résoudre ce
problème
Le tampon borné se trouve dans la mémoire partagée entre
consommateur et usager

Sémaphores: rappel. Solution avec sémaphores
Soit S un sémaphore sur une SC
n
l Un sémaphore S pour exclusion
u il est associé à une file d ’attente
u S positif: S threads peuvent entrer dans SC mutuelle sur l’accès au tampon
u S zéro: aucun thread ne peut entrer, aucun thread en attente l Les sémaphores suivants ne font pas l’EM
u S négatif: |S| thread dans file d ’attente
n Wait(S): S - - l Un sémaphore N pour synchroniser
u si après S >= 0, thread peut entrer dans SC producteur et consommateur sur le
u si S < 0, thread est mis dans file d ’attente
nombre d’éléments consommables dans
n Signal(S): S++
u si après S<= 0, il y avait des threads en attente, et un thread
le tampon
est réveillé
l Un sémaphore E pour synchroniser
n Indivisibilité = atomicité de ces ops
producteur et consommateur sur le
nombre d’espaces libres

54


Solution de P/C: tampon circulaire fini de dimension k Points importants à étudier
Initialization: S.count=1; //excl. mut.
N.count=0; //esp. pleins
E.count=k; //esp. vides n dégâts possibles en inter changeant les
append(v): instructions sur les sémaphores
b[in]=v;
Producer: Consumer:
In ++ mod k; u ou en changeant leur initialisation
repeat repeat
produce v; wait(N);
n Généralisation au cas de plus. prods et
wait(E); wait(S);
take(): wait(S); w=take(); cons
w=b[out]; append(v); signal(S);
Out ++ mod k; signal(S); signal(E);
return w; signal(N); consume(w);
forever forever

Sections critiques

États sûr et non sûr
l On dit d'un état qu'il est sûr s'il n'est pas l 1 si demande(Pi)<=besoin(Pi)
bloqué et qu'il existe un 2 aller à 5
3 sinon
ordonnancement selon lequel chaque 4 erreur(demande supèrieur aux besoins)
processus peut s'exécuter jusqu'au 5 si demande (Pi)<=disponible
6 aller à 9
bout, 7 sinon
8 bloquer Pi;
9 dèterminer_ètat avec:
l même si tous demandent d'un seul 10 disponible=disponible -demande(Pi)
11 allouè(Pi)=allouè(Pi)+DEmande (Pi)
coup leur nombre maximum de 12 si etat sur alors faire la maj des structure de
ressources. donnèes

21
9

55


banquier
l 5 processus sont actifs (A,B,C,D,E) et il existe 4
catégories de périphériques P1 à P4 (exemple : P4
=imprimante). Le tableau de gauche donne les
ressources déjà allouées et le tableau de droite les
ressources qui seront encore demandées pour
achever l'exécution.
l Un état est dit sûr s'il existe une suite d'états ultérieurs
qui permette à tous les processus d'obtenir toutes
leurs ressources et de se terminer. L'algorithme
suivant détermine si un état est sûr :
l 1. Trouver dans le tableau de droite une ligne L dont
les ressources demandées sont toutes inférieures à
celles de dispo ( Li <= dispoi, i). S'il n'existe pas L
vérifiant cette condition, il y a interblocage

États sûrs et non sûrs (1)
l 2. Supposer que le processus associé à L obtient les
ressources et se termine. Supprimer sa ligne et
actualiser dispo
l 3. Répéter 1 et 2 jusqu'à ce que tous les processus
soient terminés (l'état initial était donc sûr) ou jusqu'à
un interblocage (l'état initial n'était pas sûr)
l Ici, par exemple, l'état actuel est sûr car :
l - on allouera à D les ressources demandées et il
s'achèvera
l - puis on allouera à A ou E les ressources demandées
Démonstration que l'état de (a) est sûr
et A ou E s'achèvera
l - enfin les autres
On suppose qu’il y a 10 ressources en
tout. 22
4

56


L'algorithme du banquier pour une ressource unique
États sûrs et non sûrs (2) (Dijkstra 1965)

Démonstration que l'état de (b) n'est pas sûr l 3 états d'allocation de ressource
l (a) sûr
Si A demande et obtient une ressource supplémentaire l (b) sûr
(figure b) alors on est dans un état non sur l (c) non sûr
22 22
5 6

L'algorithme du banquier pour plusieurs L'algorithme du banquier pour plusieurs
ressources ressources

1. Rechercher une rangée R dont les demandes de
ressources non satisfaites sont inférieur ou égales à A
2. Marquez le processus R comme achevé et ajouter
toutes ses ressources au vecteur A
3. Recommencer les étapes 1 et 2 jusqu'à ce que tous les
processus soient terminés (état sûr) où jusqu'à ce qu'un
interblocage se produise (état non sûr).

l Si B demande un scanner, on peut lui accorder car l’état
reste sur
C R l Si E en demande un aussi alors on ne peut pas lui
22 accorder et il devra patienter. 22
7 8

57


Prévention des interblocages S'attaquer à la condition de détention et d'attente
S'attaquer à la condition de l'exclusion mutuelle
l Exige que les processus demandent toutes ses
l Certains périphériques (tel que l'imprimante) ressources avant l'exécution
peuvent être spoolés (traités en différé) l le processus n'attend jamais après une ressource
l seul le démon d'imprimante peut directement utiliser
l'imprimante
l cela élimine les interblocages
l Problèmes
l peut ignorer le nombre de ressources qu'il aura besoin
l Tous les périphériques ne peuvent être spoulés.
(sinon on pourrait utiliser l’algorithme du banquier)
l Principe: l les ressources ne sont pas utilisées de manière
l éviter d'attribuer une ressource lorsque cela n'est pas optimale
absolument nécessaire
l le plus petit nombre possible de processus peuvent
réclamer la ressource
l Variation:
l un processus doit libérer toutes les ressources qu'il
détient
22 23
9 l il obtient ensuite tout ce dont il a besoin en une seule 0

S'attaquer à la condition de non-préemption S'attaquer à la condition de l'attente circulaire (1)

l Ressources ordonnées
l Cette option est difficilement réalisable numériquement
l Considérer un processus utilisant une
imprimante l Un processus peux demander
plusieurs ressources mais il doit
l au milieu de la tâche respecter l’ordre
l réquisitionner l'imprimante
l !!?? l Dans l’exemple, si i<j alors
l Solution dans ce cas: utiliser l A peux demander i
l B ne peux pas demander i
le disque et le sansd’abord libérer j
démon d’impression
l Le problème est qu’il est difficile de
23 23
1 trouver un ordonnancement adéquat 2

58


Autres considération Les interblocages de communication
Le verrouillage en deux phases
l Méthode utilisé pour des applications spécifiques:
l Exemple: Bases de données l Deux processus se bloquent
l Première phase
l Le processus tente de verouiller plusieurs enregistrements mutuellement
(un à la fois)
l Si un enregistrement est déjà verrouillé, il libère les verrous l chacun attend que l'autre accomplisse une
et recommence. tâche
l (aucun véritable travail est effectué)
l Lorsque la première phase se termine, on commence l Par exemple, A envoie à B un message qui
la seconde se perd. A attend la réponse de B et B
l effectuer les modifications
l libérer les verrous attend le message de A.
l Similaire à demander toutes les ressources à la fois
l Cette solution n'est pas toujours possible
l Exemple: systèmes à temps réel

23 23
3 4

Les interblocages actifs La privation des ressources
l Se produit, par exemple lorsque deux l Algorithme d'allocation des ressources
processus utilise l’attente circulaire pour l peut être de servir les tâches les plus courtes en
premier
obtenir des ressources.
l A obtient la ressource R1 et boucle pour obtenir
l Fonctionne bien pour les petites tâches
R2
l B obtient R2 et boucle pour obtenir R1
l Les deux processus utilisent inutilement le l Peut affamer les longues tâches
processeur. l même si elles ne sont pas bloquées
l Autre exemple. Supposons que la table des
processus contiennen 100 entrées l Solution:
l politique premier arrivé, premier servi
l 10 processus ont besoin d’en créer 12 chacun
l Ils en obtiennent chacun 9
23 23
l Les 10 processus boucleront sans fin 5 6

59


Concepts importants de cette
Glossaire
partie du Chap 7
l Le problème de la section critique l Atomicité, non-interruptibilité:
l L’entrelacement et l’atomicité l La définition précise d’atomicité, non-déterminisme
etc. est un peu compliquée, et il y en a aussi des
l Problèmes de famine et interblocage différentes… (les curieux pourraient faire une
l Solutions logiciel recherche Web sur ces mot clé)
l Instructions matériel l Ce que nous discutons dans ce cours est une 1ère
approximation: une séquence d’ops est atomique si
l Sémaphores occupés ou avec files elle est exécutée toujours sans être interrompue
l Fonctionnement des différentes solutions par aucune autre séquence sur les mêmes
l L’exemple du tampon borné données
l Ou son résultat ne dépend jamais de l’existence d’autres
l Par rapport au manuel: ce que nous n’avons séquences en parallèle…
pas vu en classe vous le verrez au lab

60

Cours système d'exploitation

Contenu connexe

Tendances

En vedette

Similaire à Cours système d'exploitation

Plus de Amel Morchdi

Cours système d'exploitation