Transcript interblocage

Systèmes d’exploitation
Processus interblocage
Introduction
De nombreuses applications nécessitent un accès exclusif à plusieurs ressources (ex
: impression d’un fichier depuis une disquette)
PB : dans un système multiprogrammé, plusieurs processus peuvent désirer accéder
aux mêmes ressources exclusives
Ex : 2 processus qui veulent imprimer un fichier contenu sur une disquette
– Proc A requiert l’imprimante et l’obtient
– Proc B monte la disquette
– A essaye de monter la disquette, malheureusement B ne la libère pas et demande
l’imprimante
– A ce stade les 2 processus sont bloqués et le resteront indéfiniment
Cette situation est appelée interblocage (deadlock)
Les interblocages peuvent intervenir dans bien d’autres situations que l’accès à des
périphériques d’E/S
Ex : l’accès à 2 enregistrements d’une BD
Les interblocages peuvent donc se produire sur des ressources matérielles et
logicielles
Les ressources
Une ressource est un objet allouable par un seul processus à la fois
Elle peut être un périphérique matériel ou une information
2 types de ressources : préemptibles ou non
Ressource préemptible = ressource qui peut être retirée sans risque
au processus qui la détient (ex : le CPU)
En général, les interblocages concernent les ressources non
préemptibles (ex : imprimante)
L’utilisation d’une ressource produit 3 événements :
1.
2.
3.
Demande de la ressource
Utilisation de la ressource
Libération de la ressource
Nous considérons qu’un processus demandant une ressource déjà
allouée est bloqué (ou en sommeil)
Interblocages : définition
Un ensemble de processus est en interblocage si chaque
processus attend un événement que seul un autre de
l’ensemble peut engendrer
Comme tous les processus attendent, aucun ne pourra
produire l’événement pour réveiller un des autres processus
La plupart du temps, l’événement attendu par un processus
est la libération d’une ressource détenue par un autre
Le nombre de processus, le nombre de ressources et la
nature des ressources n’importent pas.
Conditions de survenue
d’un interblocage
Coffman et al. (1971) ont montré qu’il faut réunir 4 conditions pour
provoquer un interblocage :
1.
L’exclusion mutuelle : chaque ressource est soit attribuée, soit disponible
2.
La détention et l’attente : les processus qui détiennent des ressources
précédemment obtenues peuvent en demander des nouvelles
3.
Pas de réquisition : les ressources obtenues par un processus ne peuvent lui
être retirées contre son gré ; elles doivent être explicitement libérées par le
processus qui les détient
4.
L’attente circulaire : il doit y avoir un cycle d’au moins 2 processus chacun
attendant une ressource détenue par un autre processus du cycle
Aucun interblocage possible si l’une de ces conditions n’est pas
vérifiée
Modélisation des interblocages
Holt en 1972 a montré comment modéliser ces 4 conditions à l’aide de graphes
2 types de nœuds (des cercles pour les processus, des carrés pour les ressources)
Un arc orienté d’une ressource vers un processus signifie que cette ressource est
attribuée à ce processus
Un arc orienté d’un processus vers une ressource signifie que le processus est
bloqué en attente de cette ressource
Un cycle dans le graphe signale un interblocage
A détient R
A
B demande S
Interblocage
C
S
U
T
R
B
D
Exemple d’interblocage
3 processus (A,B,C) et 3 ressources (R,S,T)
1. A demande R
2. B demande S
A
B
C
R
S
T
3. C demande T
4. A demande S
5. B demande T
6. C demande R
CYCLE INTERBLOCAGE
SE face aux interblocages
Le SE n’est pas tenu d’exécuter les processus dans un
ordre particulier
S’il constate que l’allocation d’une ressource peut conduire
à un interblocage, il peut simplement suspendre le
processus qui effectue la requête
En général, il existe 4 stratégies pour traiter les
interblocages :
1.
2.
3.
4.
Ignorer complètement le problème
Les détecter et y remédier
Les éviter dynamiquement en allouant les ressources avec
précaution
Les prévenir en empêchant l’apparition d’une des 4 conditions
La politique de l’autruche
Approche la + simple : mettre la tête dans le sable
en prétendant qu’il n’a aucun
Un problème
problème
mais où çà ?
Pour les matheux : comportement inacceptable
Pour les ingénieurs : cherchent à connaître la fréquence du phénomène et le nombre
de fois où le système s’arrête pour d’autres raisons !
UNIX ne détecte pas les interblocages
Ex : Table des processus (100 places), 10 programmes s’exécutent et créent chacun
12 fils  table pleine lorsque les 10 processus originaux auront chacun créé 9 fils,
chacun des processus effectuant une boucle infinie en essayant de créer un nouveau
processus : il y a interblocage !
PB : le prix à payer pour éliminer les interblocages est élevé !
Trouver un compromis entre commodité et exactitude et tenter de déterminer lequel
de ces facteurs est le plus important pour quelle catégorie d’utilisateurs
Difficile de trouver des solutions générales !
Détection et reprise
Deuxième technique : la détection et la reprise
Le système ne cherche pas à empêcher les
interblocages
Il les laisse se produire, puis tente de les détecter et
d’y remédier à posteriori
Détection avec une seule
ressource d’un type donné
Cas le plus simple : il n’existe qu’une seule ressource d’un certain
type
Dans ce cas, la recherche de cycle dans le graphe d’allocation des
ressources est suffisant
Un algo simple de recherche de cycle :
1.
2.
3.
4.
5.
6.
Pour chaque nœud N du graphe :
Initialiser L à vide et démarquer les arcs
Si NL alors cycle, sinon ajouter N à L
S’il existe des arcs non marqués partants de N goto 5,
sinon goto 6
Prendre un arc et le marquer,
atteindre le nœud destination et goto 3
Revenir au nœud précédent et goto 4
Détection avec plusieurs
ressources d’un type donné (1)
Soit, n le nombre de processus Pi
Soit m, le nombre de catégorie de ressources Ei ; Ei=2 => 2 ressources de ce type
E est le vecteur de ressources existantes
A un instant donné, certaines ressources sont utilisées,
soit A le vecteur des ressources disponibles
2 matrices : C (matrice des allocations courantes) et R (matrice des demandes)
– Cij représente le nombre d’instances de la catégorie j détenues par Pi
– Rij représente le nombre d’instances de la catégorie j demandées par Pi
n
Propriété : Cij AjEj (une ressource est soit allouée, soit libre)
Ex :
i1
C=
E=(4 2 3 1)
A=(2 1 0 0)
0 0 1 0
2 0 0 1
2 0 0 1
0 1 2 0
R=
1 0 1 0
2 1 0 0
Détection avec plusieurs
ressources d’un type donné (2)
L’algo de détection des interblocages consistent à effectuer
une comparaison de vecteurs
2 vecteurs V et W : VW ssi  i Vi Wi
Idée : marquer les processus qui peuvent se terminer et
qui ne sont pas en interblocage
1.
2.
3.
Rechercher Pi non marqué dont Ri A
Si ce processus existe : A=A+Ci, marquer Pi et goto 1
Sinon fin de l’algo
Tout processus non marqué est en interblocage
0 0 1 0
Exemple :
E=(4 2 3 1)
A=(2 1 0 0)
C=
2 0 0 1
0 1 2 0
R=
2 0 0 1
1 0 1 0
2 1 0 0
Quand détecter les interblocages ?
Première possibilité : à chaque demande de ressource
– Détection rapide
– Coûteux en temps CPU
Deuxième possibilité : tous les k minutes ou lorsque l’utilisation du
CPU est inférieure à un certain seuil
La prise en compte de l’utilisation du CPU est intéressante, car les
processus en interblocage ne s’exécutant pas, le CPU est souvent libre
Reste une question : que faire lorsque l’on a détecté un interblocage ?
– Il faut permettre au système de se rétablir et de poursuivre son exécution
– Plusieurs méthodes existent, aucune n’est vraiment satisfaisante !
Reprise au moyen de la
préemption
Retirer temporairement une ressource à un processus pour l’attribuer à
un autre
Dans de nombreux cas, une intervention manuelle est nécessaire
Ex : impression : récupérer les feuilles déjà imprimer, suspendre le
processus, laisser un autre imprimer, replacer les feuilles et permettre
au processus de reprendre son impression
La possibilité de retirer une ressource à un processus pour l’attribuer à
un autre avant de le restituer au premier (sans qu’il ne s’en rende
compte) dépend beaucoup de la nature de la ressource
Le choix du processus à suspendre dépend des ressources qui
peuvent être le plus facilement retirées
Ce type de reprise est souvent difficile, voire impossible
La reprise au moyen du rollback
Si les concepteurs du système pensent que les interblocages
sont probables, ils peuvent poser régulièrement des points
de reprise (checkpoints) sur les processus
L’état des processus est sauvegardé dans un fichier, pourra
être restauré ultérieurement
Le checkpoint contient l’état l’image mémoire du processus
ansi que les ressources attribuées à ce processus
Un nouveau checkpoint ne doit pas remplacer le précédent
Lorsqu’un interblocage survient, il faut déterminer la
ressource incriminée et restaurer le processus dans un état
antérieur à l’acquisition de la ressource
Tout le travail effectué depuis ce point de reprise est perdu
La reprise au moyen de la
suppression des processus
Méthode la plus radicale et la plus simple : tuer un ou
plusieurs processus !
Possibilité de tuer un processus du cycle, avec un peu de
chance, les autres pourront poursuivre ; cette opération peut
être répétée jusqu’à ce que le cycle soit rompu
Autre possibilité, tuer un processus qui n’est pas dans le
cycle de manière à libérer ses ressources ; le processus est
choisi en fonction des ressources qu’il détient et qui sont
demandées par un des processus du cycle
Il est préférable de tuer un processus qui peut être
entièrement réexécuté sans effets secondaires (ex : une
compilation à l’inverse d’un m.a.j. de BD)
L’évitement des interblocages
Idée : le système ne peut-il pas attribuer une
ressource que s’il est sûr que celle-ci ne provoquera
pas d’interblocage ?
Un tel algo existe mais il implique la nécessité de
connaître à l’avance certaines informations
Dans cette partie, nous allons étudier le moyen
d’éviter les interblocages grâce à une allocation
prudente des ressources.
La trajectoire des ressources
Principaux algos d’évitement sont basés sur le concept d’état sûr
Représentation graphique du concept :
Région où les processus
demandent l’imprimante
B
I8
inaccessible
Sûre
u
(les 2 processus
sont terminés)
I7
Sûre
Imprimante
DAT
I6
Sûre
I5
r
p
q
I1
Imprimante
Non sûre
t
Région où les processus
demandent le DAT
Sûre
s
I2
DAT
Sûre
I3
I4
A
Les états sûrs et non sûrs
Un état est dit sûr, s’il n’existe pas d’interblocage et s’il existe un moyen de satisfaire
toutes les requêtes en attente, en exécutant les processus dans un certain ordre
Ex : 10 instances d’une ressource unique
colonne 1: processus, colonne 2 : allouée, colonne 3 : Max demande
Etat
sûr
A 3 9
A 3 9
A 3 9
A 3 9
A 3 9
B 2 4
B 4 4
B 0 -
B 0 -
B 0 -
C 2 7
C 2 7
C 2 7
C 7 7
C 0 -
Libre : 3
Libre : 1
Libre : 5
Libre : 0
Libre : 7
A 4 9
Etat
non sûr
B 2 4
C 2 7
Libre : 2
Un état non sûr ne conduit pas nécessairement à un
interblocage.
La  entre un état sûr et non sûr est que à partir d’un état sûr,
le système peut garantir que tous les processus termiront
leur exécution (garantie non assurée pour un état non sûr)
L’algorithme du banquier
pour une ressource unique
Djikstra (65) a proposé un algorithme d’ordonnancement, l’algorithme du banquier, qui
permet d’éviter les interblocages
Il s’inspire de la manière dont un banquier accorde des prêts à ses clients
L’algo du banquier consiste à examiner chaque nouvelle requête pour voir si elle
conduit à un état sûr. Si c’est le cas, la ressource demandée est allouée, sinon la
requête est mise en attente.
Pour voir si l’état est sûr, le banquier (l’ordonnanceur) vérifie si le nombre de
ressources non allouées permet de satisfaire le client (le processus) le plus près de
son maximum
Si ce nombre est suffisant, l’algorithme suppose que les ressources de ce client sons
restituées, puis il vérifie qu’il peut satisfaire le client qui est maintenant le plus prêt de
son maximum, etc.
Si tous les prêts (les ressources) peuvent être remboursées (restituées), l’état initial
est déclaré sûr.
L’algorithme du banquier
pour plusieurs ressources (1)
L’algo précédent peut être généralisé pour gérer des ressources
multiples
2 matrices (ressources attribuées C et ressources encore
demandées R) et 3 vecteurs (E les ressources existantes, A les
ressources disponibles et P les ressources détenues [P=E-A])
Algo qui détermine si un état est sûr :
1.
2.
3.
Trouver une rangée Ri de R, telle que Ri  A. Si aucune rangée, il y a interblocage
Supposer que Pi obtienne toutes les ressources qu’il demande et se termine.
Indiquer que ce processus est achevé et ajouter ses ressources à A
Répéter 1. et 2. jusqu’à ce que tous les processus soient marquées comme
terminés, l’état initial dans ce cas est sûr, ou jusqu’à ce qu’il y ait un interblocage,
ce ui indique que l’état initial est non sûr.
Si plusieurs processus vérifient les conditions de 1., on peut prendre
n’importe lequel d’entre eux puisque le nombre de ressources
disponibles augmentera, ou au pire des cas, restera invariant
L’algorithme du banquier
pour plusieurs ressources (2)
C=
P1
P2
P3
P4
P5
CD
3
0
1
1
0
DAT LPR cdR
0
1
1
1
0
0
1
1
0
1
0
1
0
0
0
E=(6342)
R=
P=(5322)
P1
P2
P3
P4
P5
CD
1
0
3
0
2
DAT LPR cdR
1
0
0
1
1
2
1
0
0
0
1
0
1
1
0
A=(1020)
Exemple : P2 demande l’imprimante, cette requête peut être satisfaire puisque P4 peut
se terminer, puis P1 ou P5 et enfin les autres ; donc l’état résultant est sûr
P5 demande maintenant l’imprimante, si on lui accorde A=(1000) ce qui conduit à un
interblocage, P5 doit donc être suspendue
Cet algo, en théorie est excellent, mais en pratique peu utile, les processus connaissant
rarement à l’avance le nombre et le type de ressources dont ils auront besoin
De +, le nbre de ressources n’est pas fixe, mais varie en fonction du nbre d’utilisateurs
Enfin, des ressources peuvent disparaître brutalement (ex : panne)
Dans, la pratique peu de systèmes mettent en œuvre l’algo du banquier
La prévention des interblocages
Évitement des interblocages impossible car nécessite
des informations relatives à des requêtes futures qui
ne sont pas connues
Seul moyen d’interdire les interblocages empêcher
l’apparition d’une des conditions de Coffman et al.
–
–
–
–
La condition d’exclusion mutuelle
La condition de détention et d’attente
La condition de non-réquisition
La condition d’attente circulaire
La condition d’exclusion mutuelle
Si aucune ressource n’est attribuée de manière exclusive, on n’aura jamais d’interblocage
Cependant impossible de permettre à 2 processus d’imprimer en même temps
Idée : le spoule d’impression
– permet à plusieurs processus de générer des résultats simultanément
– le démon d’impression est le seul processus qui accède à l’imprimante
– ce démon ne demande aucune autre ressource, le problème de l’interblocage est résolu
Problèmes :
– cette technique ne peut s’appliquer à tous les périphériques (ex : la table des processus)
– concurrence des accès au disque lors du spoule peut conduire à un interblocage
Ex : 2 processus ont épuisé l’espace disponible pour le spoule et aucun des deux n’a
terminé => interblocage au niveau disque
Mauvaise solution
Néanmoins, il y a une idée qui peut être fréquemment mis en œuvre :
– Éviter d’allouer une ressource si cela n’est pas absolument nécessaire
– S’assurer qu’il y a le moins de processus possible qui peuvent la demander
La condition de détention et
d’attente
On peut éliminer les interblocages, si l’on arrive à empêcher les processus qui
détiennent déjà des ressources d’attendre pour en acquérir de nouvelles
Pou cela, on peut imposer aux processus de demander les ressources dont ils ont
besoin avant de commencer à s’exécuter :
– Si les ressources sont dispo, elles lui sont attribuées et le processus peut terminer son
exécution
– Sinon (au moins une ressource n’est pas dispo), aucune ressource ne lui est allouée, le
processus attend la libération de toutes les ressources dont il a besoin
Malheureusement, beaucoup de processus ne connaissent pas à l’avance les
ressources dont ils ont besoin (sinon algo du banquier et plus de problème !)
Par ailleurs, les ressources ne sont pas attribuées de manière optimale (ex : un
processus fait un calcul pendant une heure et l’imprime => il monopolise l’imprimante
pendant une heure pour imprimer une ligne !)
Néanmoins quelques systèmes à traitement par lots utilisent cette méthode
Approche légèrement différente : imposer aux processus qui demandent une (ou
plusieurs) nouvelle(s) ressource(s) de libérer celles qu’ils détiennent.
Ils tentent ensuite d’obtenir toutes les ressources demandées en une seule fois
La condition de non-réquisition
Difficile de « jouer » sur cette condition !
Comment retirer l’imprimante à un processus qui est
en train d’imprimer ?
Mais je n’ai pas
Ras le bol, cela fait 2
heures que tu
imprimes !!!
SUPPRIMER
LES RESSOURCES
fini, espèce de

La condition d’attente circulaire
Première approche : limiter à 1 le nombre de ressources détenues pas un processus
à un instant donné
Solution inacceptable : ex : impression d’un fichier se trouvant sur bande magnétique
Autre solution, numéroter toutes les ressources et appliquer la règle suivante :
– Les processus peuvent demander toutes les ressources qu’ils souhaitent à condition que
les numéros des ressources demandées soient croissants
Cette règle empêche les interblocages
Preuve pour 2 processus :
– Interblocage si A possède la ressource i, demande j et B possède j et demande i
– Si i>j, A ne pourra pas demander j (violation de la règle)
– Si i<j, B ne pourra pas demander i (violation de la règle)
Le même raisonnement s’applique à un nombre quelconque de processus
Variante : ne peut demander une ressource que si son numéro est supérieur à celui
de la plus haute ressource qu’il détient (au lieu d’imposer un ordre croissant)
Le classement numérique élimine l’interblocage, mais il existe des cas où il ne peut
pas satisfaire tous les processus
Prévention des interblocages
Synthèse
Condition
Méthode
Exclusion mutuelle
Spoule
Détention et attente
Demander toutes les ressources à l’avance
Pas de réquisition
Supprimer les ressources
Attente circulaire
Ordonner numériquement les ressources
Le verrouillage à 2 phases
Évitement et prévention pas efficace dans le cas général
Cependant pour des applications spécifiques, il existe des algo
généraux
Ex : dans de nombreuses BD, on pose des verrous sur les
enregistrements avant la maj => risque d’interblocage non négligeable
Solution le verrouillage à 2 phases :
– Dans la première phase, le processus tente de verrouiller tous les
enregistrements dont il a besoin l’un après l’autre
– S’il réussit, il entre en 2ème phase, effectue les maj et retire les verrous
– Sinon (un enregistrement était déjà verrouillé), le processus retire tous les
verrous et recommence entièrement depuis la première phase
Méthode relativement similaire à celle consistant à demander toutes
les ressources à l’avance
Les interblocages non liés
aux ressources
Des interblocages peuvent se produire dans des situations indépendantes des
ressources
Ex : 2 processus peuvent être en interblocage chacun attendant que l’autre effectue
une certaine action
Ceci arrive souvent avec les sémaphores
Ex :
Proc A
P(mutex1)
P(mutex2)
…
Proc B
P(mutex2)
P(mutex1)
…
Ou avec des signaux ou tout autre méthode de synchronisation
Ex :
Proc A
pause();
kill(B,SIGHUP);
…
Proc B
pause();
kill(A,SIGHUP);
…
La famine
La famine (starvation) est un problème lié aux interblocages
Dans un système dynamique, les demandes de ressources arrivent à tout instant, il
faut décider à qui attribuer une ressource et à quel moment le faire => certains
processus peuvent alors ne jamais obtenir de ressource sans être en interblocage !
Ex : allocation d’une imprimante
– Plusieurs processus demandent en même temps l’imprimante
– Auquel faut-il l’allouer ?
– Politique adoptable : à celui qui a le plus petit fichier à imprimer, cette approche augmente
le nbre de clients heureux et semble équitable
– PB : un proc P veut imprimer un énorme fichier et avant que l’imprimante se libère des
processus avec des petits fichiers arrivent => P meurt de faim (il est différé indéfiniment,
tout en n’étant pas bloqué !)
La famine peut être évitée en utilisant une politique d’allocation des ressources :
premier-arrivé, premier-servi (first-come, first-serve)
Cette méthode donne la ressource au processus qui attend depuis le plus longtemps
Au cours du tps, tout processus sera à un instant donné le plus vieux et obtiendra la
ressource