Chapitre IV : Les problèmes de « deadlock »

IV.4. Eviter les deadlocks

Les stratégies de prévention de deadlock consistent à éliminer l’une des conditions de

deadlocks. Nous avons vu que ces stratégies ne sont pas toujours applicables. Une
stratégie d’évitement de deadlock consiste à ne pas opérer sur 3 conditions nécessaires
et faire des choix judicieux qui assurent qu’un deadlock ne se produise jamais. Dans ces
stratégies une décision est faite dynamiquement pour savoir si l’allocation d’une
ressource va potentiellement donner lieu à un deadlock. Pour développer ces stratégies
un système a besoin de connaître les besoins futures en ressources pour chaque
processus.

Considérons un système avec n processus et m types différents de ressources et

définissons les matrices et vecteurs suivants :

• Vecteurs de ressources : quantité totale de chaque type de ressource

• Vecteurs de ressources disponibles : quantité disponible de chaque type de ressource

à un instant donné
 Chapitre IV : Les problèmes de « deadlock »
• Matrice des besoins maximums : besoins maximums de chaque processus pour
chaque ressource

• Matrice allocation : nombre d’unités de chaque type de ressources allouées à chacun

des processus

La matrice B (besoins) exprime les besoins maximum de chaque processus pour

chaque type de ressource ; c'est-à-dire Bij : le nombre maximum de ressources de
type j que le processus numéro i pourra demander pendant son exécution. Cette
information doit être déclarée à l’avance par chaque processus pour permettre
d’éviter un deadlock.

D’un autre côté, la matrice A exprime la situation d’allocation de ressources aux

processus à un instant donné ; c'est-à-dire Aij : : le nombre de ressources de type j
actuellement allouées au processus numéro i.
Chapitre IV : Les problèmes de « deadlock »

Les propriétés suivantes doivent être vérifiées :

A- Toutes les ressources sont soit

allouées soit disponibles.

B-Aucun processus n’a le droit de

demander plus de ressources
que celles existantes dans le
système.

C-Aucun processus n’a le droit de

demander plus de ressources
que le nombre qu’il a déclaré au
départ (pour chaque type de
ressources).

Nous pouvons maintenant définir deux stratégies qui permettent d’éviter un

deadlock.
Chapitre IV : Les problèmes de « deadlock »

IV.4.1. Interdire le démarrage d’un processus

Cette politique consiste à refuser de démarrer un processus si son exécution risque de

produire un deadlock. Un nouveau processus Pn+1 est démarré uniquement si :

C'est-à-dire, un processus n’est démarré que si les demandes maximum en

ressources de tous les processus en cours d’exécution plus la demande maximum du
nouveau processus ne dépassent pas les ressources disponibles dans le système.

Il est clair qu’en appliquant cette politique il n’y aura jamais de demande de ressource
no satisfaite, donc pas de deadlock. Néanmoins cette stratégie n’est pas optimale car
elle suppose le pire des cas : tous les processus font leurs demandes maximales (pour
une ou plusieurs ressources) en même temps (ce qui n’est pas nécessairement le cas).
 Chapitre IV : Les problèmes de « deadlock »

IV.4.2. Interdire l’allocation d’une ressource

La stratégie appliquée dans ce cas s’appelle l’algorithme du banquier (Banker’s

Algorithm). Nous commençons d’abord par définir la notion d’état du système et
d’état sûr. Considérons un système avec un nombre fixe de processus et un nombre
fixe de ressources.

Etat du système :
Une état du système est tout simplement la situation actuelle d’allocation de
ressources. Ainsi, l’état consiste en les deux vecteurs (R et D) et les deux matrices (B et
A).

Etat sûr (safe state) :

Un état sûr est un état du système à partir duquel il existe au moins une séquence
d’exécution qui ne produit pas de deadlock (tous les processus peuvent être exécutés
jusqu’à la fin).

Etat non sûr :

Un état non sûr est tout simplement un état qui n’est pas sûr (impossibilité de construire
une séquence d’exécution qui permet à tous les processus de terminer leur exécution).
 Chapitre IV : Les problèmes de « deadlock »

Exemple 1 :

Soit l’état initial actuel d’un système (avec 4 processus et 3 types de ressources) :

La question est : est-ce que cet état est sûr ? Autrement dit : Est-il possible de
construire une séquence d’exécution au bout de laquelle les 4 processus terminent
leur exécution.
Si nous considérons le processus P1 qui a une seule unité de R1 et peut demander 2
autres (au maximum), il est clair qu’il ne peut pas continuer jusqu’à la fin de son
exécution.
 Chapitre IV : Les problèmes de « deadlock »

Voyons le processus P2 qui a besoin d’une unité supplémentaire de R3 pour pouvoir

s’exécuter jusqu’à la fin. Si nous assignons l’unité disponible de R3 à P2 il peut donc se
terminer normalement puisqu’il disposera du nombre maximum de ressources dont il a
besoin.
Supposons donc que P2 s’est terminé, ceci va donner lieu à l’état suivant du système :

Dans ce nouvel état nous avons annulé la ligne de P2 dans la matrice B puisqu’il
aurait terminé son exécution (donc il n’a plus besoin de ressources). Nous avons
également annulé la ligne de P2 dans la matrice A puisqu’à la fin de son exécution, P2
retourne toutes les ressources qui lui sont allouées.
 Chapitre IV : Les problèmes de « deadlock »

A partir de ce nouvel état, il est clair que P1 peut terminer son exécution (le nombre de
ressources disponibles est suffisant pour satisfaire sa demande maximale). Nous
supposons donc que P1 termine son exécution. L’état suivant du système est :

En suivant le même raisonnement, P3 peut maintenant terminer son exécution, ce qui

donne l’état suivant :
Chapitre IV : Les problèmes de « deadlock »

Et ensuite, P4 peut terminer son exécution à partir du nouvel état.

Résultat : A partir de l’état initial, nous avons pu construire une séquence

d’exécution <P2,P1,P3,P4> au bout de laquelle tous les processus en cours
d’exécution se terminent normalement : l’état initial est dont un état sûr.
Chapitre IV : Les problèmes de « deadlock »

Algorithme du banquier :
L’algorithme du banquier s’exprime donc somme suit : lorsqu’un processus fait une
demande de ressource, le système suppose que la demande est accordée et calcule le
nouvel état (après satisfaction de la demande). Si le nouvel état est un état sûr la
demande est accordée et le système met à jour son état, sinon la demande n’est pas
accordée et le processus en question est bloqué jusqu’à ce que sa demande puisse être
accordée.
Exemple 2 :
Soit l’état suivant du système de l’exemple ci-dessus (exemple 1) :

Supposons qu’à partir de cet état le processus P2 demande une unité de R1 et une
unité de R3. Est-ce que le système doit répondre favorablement à cette demande ?
 Chapitre IV : Les problèmes de « deadlock »

Application de l’algorithme du banquier :

Supposons que le système accorde la demande de ressources (1, 0, 1) au processus P2.
Le nouvel état du système devient :

Nous avons déjà démontré (exemple 1 ci-dessus) que cet état est un état sûr, donc
la demande de P2 est accordée et le système met à jour son état.
 Chapitre IV : Les problèmes de « deadlock »

Supposons maintenant qu’à partir de l’état précédent (avant la demande de P2), P1

demande une unité de R1 et une unité de R3. Si la demande est accordée, l’état du
système devient :

Est-ce qu’il s’agit d’un état sûr ? La réponse est « non ». En effet, chacun des
processus a au moins besoin d’une unité de R1 et il n’y a aucune de disponible. Il est
donc impossible de construire une séquence d’exécution au bout de laquelle tous les
processus se terminent normalement.

Résultat : La demande de P1 n’est pas accordée. Le système reste dans son état
initial et P1 est bloqué jusqu’à ce que sa demande puisse être satisfaite.
 Chapitre IV : Les problèmes de « deadlock »
Remarques :
• Un état non sûr n’est pas un état de deadlock, mais il peut potentiellement conduire vers
un deadlock.
• Ce qui montre que cette stratégie ne prédit pas le deadlock de façon certaine, mais elle
anticipe les possibilités de deadlock et assure qu’aucune éventualité de deadlock ne se
présente.
• La stratégie suppose le pire puisqu’elle ignore la possibilité d’une transition d’un état
non sûr vers un état sûr. En effet, à partir d’un état non sûr, le système peut revenir à un
état sûr en cas de libération de ressources.
• L’application systématique de l’algorithme du banquier est très coûteuse car il s’agit dans
la réalité d’au moins quelques dizaines de processus et quelques dizaines de types de
ressources. La construction d’une séquence d’exécution est un processus combinatoire ce
qui consomme beaucoup de temps processeur.

• De plus, il faut remarquer que l’algorithme du banquier suppose que :

o Les besoins maximum en ressources pour chaque processus doivent être connus
(et déclarés) à l’avance, ce qui n’est pas toujours possibles.
o Les processus considérés doivent être indépendants ; c'est-à-dire l’ordre dans
lequel ils sont exécutés n’obéit ç aucune contrainte de synchronisation.
 Chapitre IV : Les problèmes de « deadlock »

IV.5. La détection de deadlock

Les stratégies vues jusqu’à maintenant essaient de faire en sorte qu’un deadlock ne se
produise jamais en imposant des restrictions. Avec les stratégies de détection les
ressources sont accordées aux processus à chaque fois que ceci est possible.
Périodiquement, le système exécute un algorithme qui lui permet de détecter si une
chaîne d’attente circulaire (donc un deadlock) s’est formée.

Le test de deadlock peut être fait à chaque nouvelle demande de ressources ou moins
fréquemment. Si le test se fait à chaque demande de ressources, on aura deux
avantages :
• Détecter un deadlock le plus tôt possible.
• L’algorithme, dans ce cas, sera relativement simple.

D’un autre côté, ceci consommera beaucoup de temps processeur. L’algorithme de

détection de deadlock est donc appliqué moins fréquemment.
 Chapitre IV : Les problèmes de « deadlock »
IV.5.1. Algorithme de détection de deadlock
Dans l’algorithme de détection de deadlock, nous allons conserver l’utilisation de la
matrice A (allocation) et du vecteur D (ressources disponibles). De plus, nous utiliserons
une matrice Q (demandes) telle que qij (1≤i≤n et 1≤j≤m) représente le nombre de
ressources de type j que le processus numéro i peut encore demander. En d’autres
termes, la matrice Q=B-A. Le principe de l’algorithme est de marquer les processus qui
ne sont pas en deadlock. Initialement aucun processus n’est marqué. Les étapes de
l’algorithme sont :
1. Marquer chaque processus qui a une ligne totalement nulle dans la matrice A (un
processus qui n’a aucune ressource allouée).
2. Utiliser un vecteur temporaire W et copier le vecteur D dans W.
3. Trouver un indice i tel que le processus Pi est actuellement non marqué et la ième ligne
de Q est inférieure ou égale à W ; c'est-à-dire qik≤Wk (1≤k≤m) et passer à l’étape 4. Si
aucun processus ne vérifie cette condition alors « fin de l’algorithme ».
4. Marquer le processus Pi et ajouter la ième ligne de A à W ; c'est-à-dire Wk=Wk+Aik
(1≤k≤m), puis retour à l’étape 3.

Un deadlock existe si et seulement si à la fin de l’algorithme il y a des processus non

marqués. Chaque processus non marqué est en deadlock.
Chapitre IV : Les problèmes de « deadlock »

IV.5.2. Application
Soit l’état actuel d’un système :

L’application de l’algorithme de détection de deadlock donne :

1. Marquer P4 (aucune ressource allouée).
2. W = D = (0, 0, 0, 0, 1).
3. La demande de P3 est inférieure ou égale à W, passer à l’étape 4.
4. Marquer P3 et W = (0, 0, 0, 1, 1). Retour à l’étape 3.
5. Aucun des processus P1 et P2 n’a une ligne dans A inférieure à W. Arrêt de
l’algorithme
 Chapitre IV : Les problèmes de « deadlock »

A la fin de l’algorithme, nous avons P3 et P4 marqués mais P1 et P2 non marqués, donc P1

et P2 sont en deadlock. Ce deadlock peut être illustré comme suit (figure 9 ci-dessous) :

Ressource R2
Détenir

Processus P2 Processus P1 Attendre

Ressource R3

Figure 9 : Illustration du deadlock de l’exemple ci-dessus