View
5
Download
0
Category
Preview:
Citation preview
Mise à niveau Systèmes d’Exploita7on
Master 1 Informa.que des Organisa.ons -‐ MIDO
Joyce EL HADDAD elhaddad@lamsade.dauphine.fr
1
Plan q Généralités
1. Historique 2. Fonc.ons 3. Architectures
q Ges.on des processus 1. Défini.on 2. Ordonnancement 3. Concurrence 4. Communica.on
2
LA Référence q Andrew Tanenbaum, Modern opera3ng
system, Pren.ce Hall, 3th Edi.on, 2007
3
Plan q Généralités
1. Historique 2. Fonc.ons 3. Architectures
q Ges.on des processus 1. Défini.on 2. Ordonnancement 3. Concurrence 4. Communica.on
4
Historique
5
q 1945-‐1955 : premiers ordinateurs
Ø Peu répandus, sans interface, peu fiable, programmes en binaire
Ø Ges.on mul.-‐u.lisateurs par réserva.on
Ø U.lisateurs « mul.fonc.ons » : inser.on du programme et des données, exécu.on, interpréta.on des résultats…
Ø Inconvénients : temps d’inac.vité, tâches perdues
U1 U2 U3 U4 U5
Historique
6
q 1955-‐1965 : traitement par lots Ø Programmes en langages évolués (Fortran, …)
Ø Lots de cartes à l’opérateur : cartes Fortran en entrée et cartes en langage assembleur en sor.e
Ordinateur auxiliaire Lecteur de cartes
Dérouleur de bandes
Ordinateur principal
Dérouleur système
Dérouleur sor.es
Ordinateur auxiliaire Dérouleur de bandes
Imprimante
Opérateur
Opérateur
Programmeurs
Programmeurs
Historique
7
q 1955-‐1965 : traitement par lots Ø Traitements par lots séquen.el : exécu.on successives
d’un ensemble de programmes
Ø Contrainte : assigner à chaque programme une durée maximale. Les tâches inachevées sont abandonnées
Ø Inconvénients : temps d’inac.vité entre les Entrées/ Sor.es (E/S), tâches perdues
U1 U2 U3 U4 U5
Historique
8
q 1965-‐1980 : mul.programma.on Ø Traitements par lots parallèle : exécu.ons parallèles d’un
ensemble de programmes
Programmeurs
Mémoire principale
Lecteur de cartes Disque entrées
Ordinateur principal
Programme 1 Programme 2
Disque sor.es Imprimante
Système
Opérateur
Programmeurs
…
Historique
9
q 1965-‐1980 : mul.programma.on Ø À chaque E/S ou Fin, changement de programme
Ø Fins des E/S signalées par des interrup.ons
Ø Les tâches inachevées sont abandonnées
Ø Inconvénients : temps d’inac.vité entre les E/S pour les dernières tâches, tâches perdues, temps de réponse indépendant de la durée de la tâche
U1
U2
U3
U4
U5 Alloca.on processeur
E/S
E/S
Fin
Fin
E/S Fin
Abandon
Historique
10
q 1980-‐ : temps partagé Ø Les programmes n’ont plus de temps d’exécu.on
maximum Ø Le partage du temps en quanta
Mémoire principale
…
Programme 1
Programme 2
Système
Ordinateur principal
Terminal Terminal Terminal
Programmeurs
Historique
11
q 1980-‐ : temps partagé Ø Affecta.on du processeur à un programme durant un
quantum
Ø Interrup.on du programme si E/S, Fin, ou quantum épuisé
Ø Avantage : prise en compte rapide des nouveaux programmes
U1
U2
U3
Alloca.on processeur
QT
QT
Fin E/S
E/S QT
Historique
12
q 1980-‐ : les ordinateurs personnels (deux principaux systèmes d'exploita.on MSDOS et UNIX)
q 1990-‐ : les ordinateurs personnels portables ( systèmes d ’exp lo i ta.on micronoyau ou modulaires)
q 2000-‐ : les ordinateurs de poches et les tablekes (systèmes d’exploita.on iOS, Android,…)
q … et l’évolu.on con.nue
Fonc.ons d’un S.E.
13
q Deux catégories de programmes : Ø Les programmes u.litaires ou systèmes (éditeurs,
compilateurs,…) des.nés aux programmeurs
Ø Les programmes d’applica.ons (tableurs, traitement de texte,…) des.nés aux u.lisateurs finaux
U.lisateur
Machine (matériel)
Programmes u.litaires (compilateurs, interpréteur de commandes, …)
Programmes d’applica.ons (jeu, messagerie, traitement de texte,…)
Système d’Exploita.on
Programmeur
Fonc.ons d’un S.E.
14
q Un système d’exploita.on (S.E.) est un programme qui : Ø Contrôle l’exécu.on des programmes u.litaires Ø Contrôle les ressources de l'ordinateur Ø Fournit la base sur laquelle seront construits les
programmes d'applica.ons
q Deux fonc.ons d’un S.E. Ø Machine étendue : Interface entre l’u.lisateur et la
machine Ø Ges.onnaire des ressources de la machine
Fonc.ons d’un S.E.
15
q Interface Machine/U.lisateur Ø Rôle : masquer des éléments fas.dieux liés au matériel,
comme les interrup.ons, les horloges, la ges.on de la mémoire, la ges.on des périphériques…
Ø Un S.E. fournit des services évolués; ces services sont d’autant plus évolués que l’u.lisateur est novice
15
U.lisateur
Machine (matériel)
Programmes u.litaires
Programmes d’applica.on
Système d’Exploita.on
Programmeur
Exécu.on de programmes (chargement, redirec3on,…)
Ges.on des fichiers (localisa3on, protec3on,…)
Accès aux périphériques E/S (lecture, écriture,…)
Ges.on des u.lisateurs (créa3on, passwd, droits,…)
Fonc.ons d’un S.E.
16
q Interface Machine/U.lisateur : Appels Systèmes Ø Les programmes applica.ons et u.litaires s’exécutent en
mode u.lisateur alors que le S.E. s’exécutent en mode noyau ou superviseur (kernel en anglais, la par.e fondamentale d’un S.E.)
Ø Pour obtenir un service d’un S.E., un u.lisateur doit faire un Appel Système (System Call en anglais)
Ø Un appel système est une fonc.on fournie par le noyau d'un S.E. et u.lisée par les programmes s'exécutant dans l'espace u.lisateur
Fonc.ons d’un S.E.
17
q Interface Machine/U.lisateur : Appels Systèmes Ø Les appels systèmes sont des procédures atomiques
classiques : v appelées depuis un programme de l’espace u.lisateur; v exécutées dans l’espace noyau; v dont le retour est effectué dans le programme appelant
dans l’espace u.lisateur.
Ø Ils permekent au S.E. de réaliser un service demandé : v Ges.on de processus (fork, wait, exit, kill,…) v Ges.on du système des fichiers (open, close, read, write,…) v Ges.on des u.lisateurs et des protec.ons (chmod,…) v …
Fonc.ons d’un S.E.
18
q Interface Machine/U.lisateur : Interpréteur Ø Une connexion à un terminal ac.ve un programme
(processus) qui: v akend une commande (ex. cat file1 file2 | sort > /dev/lp) v l’interprète et v l’exécute directement ou indirectement par créa.on d’un
processus (ex. concaténa3on de file1 et file2, le résultat est envoyé à sort qui trie dans l’ordre alphabé3que et le résultat est envoyé à l’imprimante)
Ø Ce processus exécute un programme appelé l’interpréteur de commandes
Fonc.ons d’un S.E.
19
q Interface Machine/U.lisateur : Interpréteur Ø Un interpréteur traite les commandes tapées au clavier
par l'u.lisateur et lui masque les appels systèmes
Ø Un interpréteur est un programme u.litaire ne faisant pas par.e du noyau d’un S.E. mais faisant par.e des composants de base
Ø Plusieurs interpréteurs possibles : sh (shell), csh (cshell), ksh (korn shell) sous Unix, cmd.exe sous Windows NT et ses dérivés , tcsh ou bash sous Mac OS X et ses dérivés.
Fonc.ons d’un S.E.
20
q Ges.on des ressources Ø Un ordinateur est cons.tué d’un ensemble de ressources
v Processeur (CPU), Mémoire (principale), Périphériques E/S (disques, imprimantes,…)
Ø Plusieurs fonc.onnalités de ges.on v Processeur : alloca.on du processeur aux différents
programmes v Fichiers v Entrées/Sor.es : accès aux périphériques v Mémoire : segmenta.on et pagina.on v Concurrence : synchronisa.on pour l'accès à des
ressources partagées v Protec.on : respect des droits d'accès aux ressources
Fonc.ons d’un S.E.
21
q Ges.on des ressources Ø Le noyau d’un S.E. gère l’alloca.on des ressources aux
programmes avec pour objec.fs : v Efficacité : u.lisa.on maximale des ressources v Equité : pas de programme en akente indéfinie v Cohérence : entre les accès consécu.fs v Protec.on : contre des accès interdits
Fonc.ons d’un S.E.
22
q Ges.on des ressources : Processus Ø Processus = un programme en cours d’exécu.on
Ø Un processus est caractérisé par : son code exécutable, ses données et sa pile, son compteur ordinal et son pointeur de pile, l’u.lisateur qui l’a lancé, sa durée d’exécu.on, les fichiers qu’il accède…
Ø Un processus est crée par un autre processus
Ø Les processus sont les « éléments ac.fs » du système
Fonc.ons d’un S.E.
23
q Ges.on des ressources : Processus Ø Le système .ent à jour l’état des processus : en
exécu.on, prêt, en akente d’évènement, en mémoire principale ou secondaire
Ø Ges.on de processus : créa.on d’un processus (exécu.on), terminaison d’un processus (retour), akente de terminaison (père), défini.on de comportement sur évènement (interrup.on clavier), alloca.on mémoire, communica.on entre processus (envoi de signaux),…
Fonc.ons d’un S.E.
24
q Ges.on des ressources : Fichiers Ø Fichier = un ensemble de données conservées
indépendamment des exécu.ons des programmes
Ø Un fichier est caractérisé par : la structure et le contenu de ses enregistrements, sa localisa.on, son propriétaire, ses droits d’accès, ses dates de créa.on, modifica.on,…
Ø Les fichiers sont les principaux « éléments passifs » du système
Ø Ges.on des fichiers : créa.on, destruc.on, ouverture, fermeture, lecture, écriture, accès à un fichier, protec.on d’un fichier, …
Fonc.ons d’un S.E.
25
q Ges.on des ressources : Fichiers Ø Les fichiers sont regroupés en Système de Fichiers
organisés de manière hiérarchique (un fichier contenant d’autres est un répertoire)
Ø Un SGF con.ent différents types de fichiers : v Les fichiers de données : structure et contenu sont
accessibles aux processus u.lisateurs v Les répertoires : seulement le contenu est accessible aux
processus u.lisateurs v Les fichiers spéciaux (périphériques) : inaccessibles aux
processus u.lisateurs v Les fichiers de communica.on (pipe) : durée de vie ou
contenu limitée à l’exécu.on du processus
Fonc.ons d’un S.E.
26
q Ges.on des ressources : Fichiers Ø Ges.on du système de fichiers : rakachement/
détachement d’un fichier à un répertoire, montage/démontage d’un système de fichiers,…
Ø Ges.on des protec.ons : consulta.on/modifica.on des protec.ons (ou du propriétaires) d’un fichier, consulta.on /modifica.on de l’u.lisateur associé à un processus,…
Architecture d’un S.E.
27
q Objec.fs de l’architecture Ø Efficacité de l’exécu.on : rapide (pas de perte de temps),
stable (pas de bug), complet (accès à toutes les E/S) Ø Taille réduite du code Ø Maintenance et évolu.on aisée : compa.bilité avec les
versions successives, correc.ons des bugs, introduc.on de nouvelles possibilités (E/S)
q Typologie de l’architecture Ø Systèmes monolithiques Ø Systèmes en couches Ø Machines virtuelles Ø Modèle client/serveur
Architecture d’un S.E.
28
q Systèmes Monolithiques Ø Ensemble de procédures à interface bien définie
(paramètres, code retour) s’appelant mutuellement et qui, compilées, forment le système
Ø Pb : difficile d’introduire de nouvelles fonc.onnalités, de réécrire certaines procédures (bugs)
Programme u.lisateur
Système
déroutement passage en mode système
sélec.on du service
exécu.on du service
1
2 3
4 retour en mode u.lisateur
Architecture d’un S.E.
29
q Systèmes en Couches Ø Une descrip.on en couches : chaque couche offre des
services à la couche supérieure et u.lise les services de la couche inférieure
Ø Premier système en couches : le système de traitement par lots avec opérateur THE (Dijkstra 1968) v Première tenta.ve de créer un S.E. conçu sur des
superposi.ons de niveaux d'abstrac.on nekement séparés
0 : Alloca.on processeur et mul.programma.on
1 : Ges.on de la mémoire
2 : Ges.on communica.on processus-‐operateur
3 : Ges.on des E/S
4 : Ges.on processus u.lisateur
5 : Processus operateur du système
Architecture d’un S.E.
30
q Machines Virtuelles Ø Une machine virtuelle est une illusion d'un appareil
informa.que créée par un logiciel d'émula.on
Ø Le logiciel simule la présence de ressources matérielles et logicielles telles que la mémoire, le processeur, le disque dur, le système d'exploita.on et les pilotes, permekant d'exécuter des programmes dans les mêmes condi.ons que celles de la machine simulée
Ø Les machines virtuelles sont u.lisées pour exploiter une machine unique comme s'il y en avait plusieurs (virtualisa3on)
Architecture d’un S.E.
31
q Machines Virtuelles Ø La créa.on de plusieurs environnements d'exécu.on sur
un seul ordinateur, dont chacun émule l'ordinateur hôte (le système produit n copies de la machine réelle)
Ø Chaque u.lisateur a l'illusion de disposer d'un ordinateur complet alors que chaque machine virtuelle est isolée des autres
Ø Le système VM/370 (IBM 1970) v CMS (Conversa.onal Monitor System) : un S.E. léger
mono-‐u.lisateur u.lisé pour le temps partagé
CMS
virtuel 370s
CMS CMS
VM 370 (mul3programma3on)
Machine IBM 370
Architecture d’un S.E.
32
q Modèle Client/Serveur Ø Recherche de simplicité et de flexibilité
Ø Réduire le système à un noyau minimal microkernel et bâ.r les autres fonc.ons évolués par des processus u.lisateurs spécialisés : les serveurs
Ø Le noyau gère la communica.on entre clients et serveurs
Processus client
Microkernel (noyau)
Processus client
Terminal serveur
Fichier serveur
Mémoire serveur … mode
u3lisateur
mode noyau
envoi de messages
Architecture d’un S.E.
33
q Modèle Client/Serveur Ø Avantages :
v Plus de flexibilité v Plus grande facilité de maintenance v Tolérance aux pannes (un serveur peut planter sans que
cela n’entraîne la panne de la machine) v adapté à un environnement distribué
noyau
Client
Réseau Client/serveur dans un système distribué
noyau
Fichier serveur
noyau
Mémoire serveur
noyau
Terminal serveur … …
Machine 1 Machine 2 Machine 3 Machine 4
Architecture d’un S.E.
34
q Fonc.ons/Architecture d’un S.E. Ø Chaque couche a une interface bien définie par en
ensembles d’appels système
0 : Ges.on des processus (ordonnancement, ges3on des interrup3ons, E/S de bas niveau)
1 : Ges.on de la mémoire
2 : Ges.on des E/S
3 : Ges.on des fichiers
4 : IHM, Interpréteur de commandes
Plan q Généralités
1. Historique 2. Fonc.ons 3. Architectures
q Ges.on des processus 1. Défini.on 2. Ordonnancement 3. Concurrence 4. Communica.on
35
Défini.on d’un processus
36
q Un programme est l’expression d’un algorithme à l’aide d’un langage de programma.on
q Une tâche est la jonc.on d’un programme et des données auxquelles il s’applique
q Un processus est l’exécu.on d’une tâche. Il est caractérisé par la tâche et son contexte d’exécu.on (son compteur ordinal, ses données, sa place en mémoire,…)
Défini.on d’un processus
37
PROGRAM Exemple VAR a,b,c : integer; BEGIN a:=1;b:=1;c:=1; a=b+c; END
mémoire PROGRAM Exemple VAR a,b,c : integer; BEGIN a:=1;b:=1;c:=1; a=b+c; END
1 1 1
a
b c
CO CO
a=b+c;
mémoire PROGRAM Exemple VAR a,b,c : integer; BEGIN a:=1;b:=1;c:=1; a=b+c; END
2 1 1
a
b c
Défini.on d’un processus
38
q Créa.on et hiérarchie entre processus sous Unix Ø Un processus peut en créer un autre (processus père) Ø Le processus init est le premier lancé. Il crée un certain
nombre de processus système (daemon) sans u.lisateur qui se chargent des tâches : surveillance d’une connexion réseau, akente d’une connexion au clavier, sauvegardes périodiques,…
q Le S.E. permet aux processus de communiquer entre eux
q Le S.E. .ent à jour une table des processus contenant leur emplacements mémoires, les fichiers ouverts, l’u.lisateur, leur états …
Défini.on d’un processus
39
q Etats standards d’un processus Ø Un processus peut être dans les états suivants : élu, prêt,
bloqué
Ø L’unique processus élu est le processus qui s’exécute
Ø Les processus prêts sont suscep.bles d’être exécutés s’ils sont choisis par le système
Ø Les processus bloqués ne peuvent être choisis v ils leurs manquent une ressources matérielle (mémoire)
ou système (accès à un fichier), soit v ils sont en akente d’un évènement matériel (fin E/S) ou
système (message ou signal)
Défini.on d’un processus
40
q Etats standards d’un processus
1. Le processus a les ressources nécessaires à son exécu.on 2. Le processus est élu : l'ordonnanceur sélec.onne le processus pour
lui donner le processeur 3. Akente d’un évènement (ressource, fin d’un autre processus,
demande d’une E/S) : au cours de son exécu.on le processus se bloque
4. L’évènement akendu arrive : l'origine du blocage du processus a disparu
5. Le temps alloué au processus est épuisé (fin de quantum), le processus perd le processeur qui lui est re.ré par l’ordonnanceur
6. Le système re.re une ressource nécessaire à l’exécu.on d’un processus
Prêt
Elu Bloqué
1
2
3 4
6 5
Ordonnancement
41
q L’ordonnanceur (Scheduler en anglais) est le composant du noyau du S.E. qui choisit les processus qui vont être exécutés par le(s) processeur(s) d’un ordinateur
q Le rôle de l’ordonnanceur se décompose en deux par.es Ø Le mécanisme de commuta.on entre les processus Ø Le choix du prochain processus à être exécuter
q Objec.fs de l’ordonnanceur Ø Efficacité de la commuta.on: maximiser le taux d’u.lisa.on
du CPU et minimiser le temps système Ø Sa.sfac.on des u.lisateurs : minimiser le temps de réponse
Ordonnancement
42
q Dans un système en batch, il n’y a commuta.on que si le processus ac.f doit effectué une E/S
q Dans un système en temps partagé, un processus peut
perdre le CPU s’il fait une E/S ou s’il épuise son quantum
q Les interrup.ons sont u.lisées pour commuter les processus Ø Une interrup.on périodique est déclenchée par une horloge
(quantum) et l'ordonnanceur est alors mis en ac.on. Il peut commuter les processus en modifiant le processus de retour de l'interrup.on
q Une stratégie doit être adoptée par l’ordonnanceur pour le choix du prochain processus
Ordonnancement
43
q Mise en œuvre de la commuta.on : Ø Une interrup.on est un arrêt temporaire de l'exécu.on
d'un processus par le processeur afin d'exécuter un autre processus, appelé rou.ne d'interrup.on
Ø Lors d'une interrup.on, le processeur sauve tout ou une par.e de son état interne, et exécute ensuite la rou.ne d'interrup.on
Ø La rou.ne se finit par une (ou plusieurs) instruc.on de retour d'interrup.on, qui restaure l'état sauvé et soit fait repar.r le processeur de l'endroit où il avait été interrompu soit modifie les adresses de retour, pour effectuer des commuta.ons de processus
Ordonnancement
44
q Mise en œuvre de la commuta.on :
Processus A
Système
1
Processus B
élu
prêt
Interrup(on horloge Passage en mode noyau
Rou(ne d’interrup(on
sauvegarde contexte (processus A)
Détec(on fin quantum
2
3
Choix du nouveau élu 4
prêt
élu
prêt
prêt
chargement contexte (processus B)
Ordonnancement
45
q Les stratégies typiques : Ø First In First Out (FIFO) (premier arrivé, premier servi)
v Exécu.on suivant les ordres d’arrivée v Inconvénients: temps de réponse dépendant du
processus qui s’exécute (tant qu'il ne se bloque pas, les autres doivent akendre), pénalise les processus courts (propor.on temps d'akente/temps d'exécu.on) et favorise les processus longs
Ø Shortest Job Next (SJN) (plus court processus en premier) v Le choix se fait en fonc.on du temps d’exécu.on es.mé
du processus v L’ordonnanceur va laisser passer d'abord le plus court des
processus de la file d’akente
Ordonnancement
46
q Les stratégies typiques : Ø Shortest Remaining Time (SRT) (plus court temps restant en
premier) v Le processus dont le temps restant est le plus pe.t est
choisi v Quand un processus arrive dans la file d’akente, sa durée
d’exécu.on est comparer à la durée d’exécu.on restante du processus en cours. Si la durée du processus entrant est plus courte que la durée d’exécu.on restante du processus en cours, alors ce dernier est suspendu et le processus entrant prend sa place
v SJN avec préemp.on (priorité 0/1)
Ordonnancement
47
q Les stratégies typiques : Ø Tourniquet (Round Robin en anglais )
v FIFO avec préemp.on v Les processus prêt sont mis dans une file d’akente
circulaire v Des tranches de temps (quantum) sont akribués à chaque
processus en propor.on égale, sans accorder de priorité aux processus
v Une fois le quantum épuisé, le processus passe la main et retourne à la fin dans la file d'akente
Fin quantum 2
7
3
4 5
élu
2
7
3
4 5
élu
Ordonnancement
48
q Les stratégies typiques : Ø Tourniquet
v Choix du quantum : quantum court implique trop de commuta.on, quantum long implique temps de réponse (du processus) long
v Ceke stratégie suppose une équité entre les processus
v ... plus de raffinement… les priorités
Ordonnancement
49
q Les stratégies typiques : Ø Principe des méthodes avec priorité
v A chaque processus est assignée une priorité (fonc.on du temps)
v L'ordonnanceur choisit le processus prêt de plus haute priorité
Ø Priorités sta.ques v Une file d’akente par niveau de priorité (ex. temps de
calcul es3mé) v A leur créa.on, les processus sont affectés à un niveau de
priorité et sont insérés dans la file correspondante v Risque de famine : pour élire une tâche d’une file, il faut
que toutes les files de niveau supérieur soient vides
Ordonnancement
50
q Les stratégies typiques : Ø Priorités dynamiques
v Priorité calculée avant et pendant l'exécu.on (ex. -‐1 à chaque élec.on)
v La modifica.on des priorités des processus permet de prendre en compte, au moins de manière approchée, le comportement des processus (ex. pénalisa.on des processus qui u.lisent de nombreuses ressources)
v Diminu.on du temps alloué aux processus qui ont été élus
v Favori.sme envers les processus courts
Ordonnancement
51
q Les stratégies typiques : Ø Files d’akente mul.ples
v Principe : N files (F0 à FN-‐1) correspondant à N niveaux de priorité (0 étant le niveau le plus prioritaire)
v Les files sont rangées par ordre de priorité v A la créa.on, les processus sont rangés dans des files en
fonc.on de leur temps d’exécu.on v Les processus changent de file au cours de temps :
} Le premier processus prêt de la première file non vide et la plus prioritaire s’exécute
} Les processus dans la file F0 s’exécutent durant 1 quantum, ceux de la file F1 s’exécutent durant 2 quantum…
} Fin des i quantums d’un processus issue de Fi, alors réinser.on du processus dans la file Fi+1
Ordonnancement
52
q Les stratégies typiques : Ø Files d’akente mul.ples
v Des nombreux paramètres doivent être définis : } le nombre de niveaux, la ou les stratégies de sélec.on
u.lisées pour sélec.onner un processus à l’intérieur de chaque file, les condi.ons qui vont provoquer un passage d’un processus dans un niveau inférieur ou supérieur, le mécanisme pour déterminer dans quel niveau se situe un nouveau processus,…
Files des processus prêts Elec.on
CPU Fin
E/S
Fin quantum
F0
Fi
FN-‐1
+ prioritaire
-‐ prioritaire
Créa.on
Ordonnancement
53
q Les stratégies typiques : Ø Files d’akente mul.ples
v Avantage : plus une tâche s’exécute, moins elle est prioritaire, cela permet de favoriser les tâches courtes => Approxima.on de SJN
v Risque de famine : Il est possible qu’une tâche reste bloquée dans une file intermédiaire (F1 à FN-‐1) } Solu.on : régulièrement (tous les X quanta), le système
remonte d’un niveau toutes les tâches. Après un certain temps les tâches se retrouveront donc à nouveau dans F0
Ø Ordonnancement dans systèmes actuels v Trois ordonnancements sont normalisés et cohabitent dans
les systèmes actuels : FIFO (processus temps réel), Tourniquet (processus système) et Files d’akente mul.ples (processus u3lisateur)
Concurrence
54
q Accès concurrents des processus Ø Soit une pile T des demandes d’impression gérer par un
processus système Ø Un processus u.lisateur qui souhaite imprimer l’indique
dans la cellule in puis l’incrémente
Proc 1 demande l’impression de d T[in] := d
commuta.on
Proc 2 demande l’impression de e T[in] := e; in:=(in+1)
in
out
d c b a
in:=(in+1)
in
out
e c b a
commuta.on
in
out
e c b a
Concurrence
55
q Accès concurrents des processus Ø Une Sec3on Cri3que (S.C.) est une suite d’instruc.ons
qui doit être exécutée de manière indivisible <début_sec7on_cri7que> T[in] := d; in:=in+1; <fin_sec7on_cri7que>
Ø Pb : Comment réaliser des sec.ons cri.ques?
Ø Solu.ons : les interrup.ons, les variables partagées, les sémaphores,…
Concurrence
56
q Accès concurrents des processus Ø Les interrup.ons :
v Les commuta.ons ont lieu sur les interrup.ons : masquer, puis démasquer les interrup.ons assure qu’un processus ne sera pas interrompu pendant son accès à la sec.on cri.que
v Inconvénient : une très longue sec.on cri.que monopolise le processeur
Ø Les variables partagées v Deux processus p et q désirent entrer en sec.on cri.que
Algo. de p Algo. de q dem[p] :=vrai; dem[q] :=vrai; AQendre (dem[q] ==faux); AQendre (dem[p] ==faux); <sec7on_cri7que> <sec7on_cri7que> dem[p] :=faux; dem[q] :=faux;
v => Blocage !!
Concurrence
57
q Accès concurrents des processus Ø Les variables partagées
v Introduc.on d’un tour (ini.alement au processus p) Algo. de p Algo. de q
AQendre (tour ==p); AQendre (tour==q); <sec7on_cri7que> <sec7on_cri7que> tour:=q; tour :=p;
v => dépendance des processus : si le processus p désire exécuter 5 sec.ons cri.ques et q ne désire exécuter que 2 sec.ons cri.ques alors p sera bloqué indéfiniment !!
Concurrence
58
q Accès concurrents des processus Ø Les variables partagées
v Solu.on : Algorithme de Peterson qui combine les demandes et le tour Algo. de p Algo. de q dem[p] :=vrai; dem[q] :=vrai; tour :=q; tour :=p; AQendre ((dem[q] ==faux) AQendre ((dem[p] ==faux) or (tour==p)) or(tour==q)) <sec7on_cri7que> <sec7on_cri7que>
dem[p] :=faux; dem[q] :=faux;
v Fonc.onnement : v Si pas de concurrence, les variables « dem » autorisent
l’entrée en S.C. v Si concurrence, la variable « tour » permet l’entée en S.C.
Concurrence
59
q Accès concurrents des processus Ø Les sémaphores [Dijkstra 1965] :
v Un sémaphore s est une variable composé d’un compteur et d’une file de processus bloqués
v Un sémaphore est manipulé par trois primi.ves : I(s,nb) : ini.alisa.on du compteur à nb (posi.f ou nul) autorisa.ons P(s) -‐ Puis-‐je (Proberen) -‐ contrôle d’autorisa.on + blocage éventuel du demandeur : masquer l’interrup7on, nb=nb-‐1, si nb < 0 alors blocage du processus et inser7on dans la file, démasquer l’interrup7on.
Concurrence
60
q Accès concurrents des processus Ø Les sémaphores [Dijkstra 1965] :
v Un sémaphore est manipulé par trois primi.ves : V(s) -‐ Vas-‐y (Verhogen) -‐ ajout d’une autorisa.on + déblocage éventuel d’un demandeur : masquer l’interrup7on, nb=nb+1, si nb <= 0 alors extrac7on de la file et déblocage d’un processus, démasquer l’interrup7on.
v Solu.on simple et efficace par sémaphore s ini.alisé à 1 Algo. de p Algo. de q P(s); P(s);
<sec7on_cri7que> <sec7on_cri7que> V(s); V(s);
Communica.on
61
q Communica.on entre processus Ø Les moyens de communica.ons entre processus
dépendent de la nature de la communica.on : v Synchrone/Asynchrone (aYente d’un des interlocuteurs) v Personnelle/impersonnelle (connaissance de l’interlocuteur) v Volume des informa.ons
Ø Plusieurs modes de communica.ons : v Les signaux v Les tubes v Les messages v Les mémoires partagées
Communica.on
62
q Communica.on entre processus Ø Les signaux :
v Mécanisme par lequel un processus est informé d’un évènement par un autre processus
v Événements externes qui changent le déroulement d’un processus de manière asynchrone (à n’importe quel instant lors de l’exécu3on du processus)
v Similaire à une interrup.on logicielle : le processus sauvegarde son contexte, réagit au signal et restaure son contexte
v Les signaux transportent peu d’informa.on (le type du signal et rien d’autre)
Communica.on
63
q Communica.on entre processus Ø Les signaux :
v Il existe différents signaux, iden.fiés par un numéro : SIGHUP 1 : Hang-‐up (fin de connexion) terminaison du processus
leader de session SIGQUIT 3: Interrup.on forte (ctrl-‐\) frappe quit sur terminal de
contrôle SIGKILL 9 : Interrup.on très forte (ne peut être ignorée) signal
de terminaison SIGCHLD 20 : Un des processus fils est mort ou a été arrêté (peut
être ignoré) v La commande kill envoie un signal à un processus : int kill (pid_t pid, int sig); où pid est l'iden.té du processus et sig est le nom d'un signal ou un en.er entre 1 et NSIG (nb de signaux ≈ 30).
Communica.on
64
q Communica.on entre processus Ø Les tubes
v Mécanisme de communica.on synchrone et unidirec3onnel
v Un tube n’a pas toujours de nom : tube ordinaire (sans nom) et tube nommé
v Un tube ordinaire a une durée de vie limitée aux processus créateurs et leurs descendants
v Un tube nommé est un fichier dont la durée de vie va au-‐delà de la terminaison des processus créateurs et leurs descendants. Il sera désigné par une référence dans le système de ges.on des fichiers et sera supprimé lorsque plus aucun processus ne l'u.lise.
Communica.on
65
q Communica.on entre processus Ø Les tubes
v L'existence d'un tube correspond à la possession d'un descripteur acquis soit par un appel à la primi.ve de créa.on de tube pipe; soit par héritage (un processus fils hérite de son père les descripteurs de lecture et d'écriture de tubes)
v Un tube possède deux extrémités, une pour y lire et l’autre pour écrire
v La lecture dans un tube est destructrice: l’info lue est supprimée du tube
v Avantages tubes nommés : peuvent être u.lisés par des processus différents et sans lien de parenté (exemple clients/serveur) Tube client 1
Tube client 2
Tube requêtes
Serveur
Client 1
Client 2
Communica.on
66
q Communica.on entre processus Ø Les messages
v Mécanisme de boîte aux lekres v Un mode de communica.on personnalisé : envoie à un
processus et récep.on d’un processus v Une informa.on de taille limitée accompagne le message v Émission Synchrone (l'émekeur akend que son message
soit lu) vs. Asynchrone (le message est rangé dans une file du récepteur)
v Récep.on Synchrone (bloquante jusqu'à l'arrivée d'un message) vs. Asynchrone (non bloquante)
Communica.on
67
q Communica.on entre processus Ø Les mémoires partagées
v Un segment de mémoire accessible à plusieurs processus par un nom prédéfini et une clé d’accès. Les divers processus pourront y lire et/ou y écrire
v La communica.on est impersonnelle
v Façon rapide pour échanger des données entre processus.
v Très efficace pour les algorithmes à variables partagées (ex. l'algorithme de Peterson)
v Une mémoire partagée peut contenir des variables et des informa.ons structurées (struct, tableau,…)
v Intérêt : pas de primi.ves bloquantes
Informa.on q Cours et TD disponibles à l’adresse
hYp://www.lamsade.dauphine.fr/~elhaddad/Courses/SAR/
68
Recommended