CHAPITRE II : PROBLEMES FONDAMENTAUX DES

SYSTEMES D’EXPLOITATION REPARTIS

Le but de ce chapitre est de faire une tour d’horizon des problèmes fondamentaux auxquels sont
confrontés les systèmes d’exploitation répartis, ainsi que les différentes solutions qui ont été
proposées pour les résoudre.

2.1 ORDRE ET TEMPS DANS LES SYSTEMES REPARTIS :

Les systèmes répartis sont caractérisés par une évolution asynchrone des différents sites, et ceci en
raison de l’absence d’une mémoire commune et d’une horloge commune. D’autres facteurs
contribuent à l’asynchronie du système réparti ; ils sont en rapport avec les propriétés du système de
communication :

• temps de communication potentiellement longs par rapport aux temps de transition locaux
• temps de transmission variables
• éventuellement non-préservation de l’ordre des messages

Ces paramètres ont comme conséquence sur le système réparti :

• perception différente des mêmes événements depuis des sites distincts

• impossibilité de définir simplement un “état global instantané”
• conséquences sur : la synchronisation, l'observation et la mise au point, la tolérance aux fautes,
…etc.

Dans les sections suivantes nous décrirons les trois concepts fondamentaux des systèmes
d’exploitation répartis : ordres entre les événements, temps et état global.

Exemple : Problème du parking

Problème du parking avec plusieurs gardiens : Chaque gardien joue le rôle d’un allocateur des places
du parking. Supposons qu’il y ait 4 gardiens et qu’à un certain instant il y ait exactement 100 places
libres dans le parking. Chaque gardien dispose de cette information ; l’état du système est donc
cohérent. Trois de ces gardiens diffusent ensuite aux autres les trois messages suivants :

- M1 : 20 places de plus sont libres.

- M2 : 10 places de plus sont occupées.
- M3 : Je réserve 10% des places libres pour le nettoyage du parking.

On peut facilement constater que si on n’impose pas de contrainte sur l’ordre de traitement des
messages par les gardiens, ceux-ci vont obtenir pour le nombre de places libres des valeurs
différentes. Si chaque gardien entretient un exemplaire de l’état d’allocation des places, il faut, pour
que ces exemplaires demeurent cohérents entre eux, exécuter la séquence de mises à jour dans le
même ordre sur chaque site.

Le tableau suivant illustre un scénario de réception des messages par les sites, provoquant un état
incohérent.
 2

Gardien 1 Gardien 2 Gardien 3 Gardien 4

Ordre Message Valeur Message Valeur Message Valeur Message Valeur
normal
100 100 100 100
1 M1 +20 120 M1 +20 120 M3 -10 90 M2 -10 90
2 M3 -12 108 M2 -10 110 M1 +20 110 M3 -9 81
3 M2 -10 98 M3 -11 99 M2 -10 100 M1 +20 101

On constate que l’état obtenu est devenu incohérent. En effet, le nombre de places disponibles pour
les gardiens 1, 2, 3 et 4 est égal respectivement à : 98, 99, 100, 101. La raison en est que l'ordre de
traitement des messages n'a pas été le même pour chaque site (gardien).

Cet exemple montre la nécessite l’établissement d’un ordre unique sur l’ensemble des messages du
système.

2.1.1 Ordre des évènements

Dans les systèmes centralisés, la mise en œuvre des outils de synchronisation repose sur un
mécanisme d'exclusion mutuelle. Dans un système réparti, la synchronisation repose uniquement sur
l’établissement d’un ordre entre événements. Entre sites différents, cet ordre ne peut être réalisé que
par l’échange de messages.

Supposons défini un tel ordre sur l’ensemble des événements d’un système réparti, au moyen d’une
relation notée → et nommée précèdence, on dit aussi précédence causale ou dépendance causale. ou
relation de causalité. Cette relation doit satisfaire au minimum les contraintes suivantes :

Contrainte 1 : Si A et B sont des événements d’un même site et si A est exécuté avant B, selon un
ordre local au site, alors : A→B.
Contrainte 2 : Si A est l’émission d’un message par un site et si B est la réception de ce message, on
a : A→B.

Exemple : Un système est composé de deux sites A et B. Au niveau du site A il existe un ordre local
des événements : A1→A2→A3→A4→A5. Au niveau du site B, il existe aussi un ordre local :
B1→B2→B3→B4. De plus, on suppose que les sites A et B se sont échangés des messages dont la
causalité est décrite par les deux relations suivantes : A2→B2 et B3→A4 (A a envoyé un message à B.
Ce message a été reçu. Ensuite, B a envoyé un message à A qui l’a reçu). On peut représenter l’ordre
des événements par le schéma suivant.

A partir de ce schéma on peut déduire par transitivité l’ordre existant entre certains événements :

- A1→A2→B2→B3→B4
- B1→B2→B3→A4→A5
- A1→A2→B2→B3→A4→A5

En revanche certains autres événements sont incomparables (ne peuvent pas être classés
par une relation d’ordre). Exemple :

- B1 et A1, A2, A3
- A3 et B2, B3, B4
Systèmes d’exploitation des Ordinateurs 3

Site A Site A

A1
B1

A2
B2
A3
B3

A4

B4
A5

Fig ?? Exemple d’ordonnancement partiel des événements d’un système.

De ce qui précède on peut conclure que problème d’ordonnancement (synchronisation et allocation)

dans les systèmes d’exploitation répartis peut être résolu en utilisant la relation d’ordre entre les
événements.

2.1.2 Temps dans les systèmes répartis :

La mesure du temps est un autre problème fondamental dans les systèmes répartis. En effet,
comment dater et ordonner des événements entre des sites physiquement éloignés et ne possédant
pas la même valeur d’horloge. Ainsi plusieurs méthodes de mesure de temps ont été proposées :
horloges logiques (scalaires), horloges vectorielles, horloges matricielles.Nous décrivons ci-après la
méthode des horloges logiques

Chaque site gère un compteur dont la valeur est un entier : les valeurs des horloges sont donc
comparables en tant que valeurs entières. Sur chaque site ce compteur est initialisé à 0 au lancement
du système. La valeur de l'horloge logique d'un site est incrémentée chaque fois qu'un événement
local s'y produit : un tel événement est soit une opération purement locale, soit l'envoi d'un message.
Dans ce dernier cas la valeur courante (après incrémentation) de l'horloge de l'émetteur est
embarquée avec le message et sert à l'estampiller.

La réception d'un message permet de synchroniser l'horloge du récepteur avec celle de l'émetteur du
message qui est transportée par le message. Le principe est simple : il consiste à attribuer à l'horloge
du récepteur une valeur supérieure à la fois à la valeur courante de l'horloge du site et à celle de
l'estampille du message reçu. En résumé :

- Chaque site S est muni d’un compteur à valeurs entières, noté Hs et appelé horloge locale, qu’il
incrémente entre deux événements successifs.
- Un site e qui émet un message le marque d’une estampille E égale à la valeur courante de He.
- A la réception du message, le site récepteur r met à jour sa propre horloge Hr de la façon
suivante :

Si Hr < E
Alors Hr := E+1
Sinon Hr := Hr+1
Finsi

LOUKAM Mourad
 4

L’événement « Réception du message » est alors daté par la valeur de Hr. Cet algorithme assure donc
que la réception d’un message est postérieure à celle de son émission. Cette datation permet de
définir une relation d’ordre total que nous notons →.

Un événement a qui se produit par un site i est daté par la valeur courante de l’horloge de ce site, noté
Hi(a). Si a et b sont deux événements localisés respectivement sur les sites i et j, on a, par définition :
a→b ⇔ Hi(a) < Hj(b)

Exemple : La figure suivante donne la valeur des estampilles logiques scalaires associées en
appliquant la méthode décrite précédemment à des événements de 3 sites entre lesquels des
messages estampillés sont échangés.

Site 1 Site 2 Site 3

0
0 0

1
1 1

2
3
4
3

4
5

5 4

7 6 6

8 7

10

11
9

12

13
13

14 14

15
16

Fig .. Exemple de datation des événements avec des horloges logiques.

Systèmes d’exploitation des Ordinateurs 5

Remarque : L’ordre induit par la datation avec les horloges logiques n’est pas strict : deux événements
qui se produisent sur deux sites peuvent avoir des dates identiques.

On peut étendre la relation → à une relation d’ordre total strict, notée , en associant un numéro
distinct fixe à chaque site, et en datant chaque événement a du site i par le couple (Hi(a), i).

2.2 SYNCHRONISATION DANS LES SYSTEMES REPARTIS

Plusieurs méthodes de synchronisation en été proposées pour les systèmes d’exploitation répartis.

2.2.1 Algorithme de Lamport :

Cet algorithme exige que les canaux de communication entre les sites fonctionnent en mode FIFO;
c'est à dire que les messages sont reçus dans l'ordre de leur émission.

Chaque site i du réseau peut envoyer des messages de la forme (T, Hi, i) où Hi est l’estampille du
message, c(est à dire son heure logique d’émission et T peut prendre les trois valeurs REQ, REL et
ACQ qui définissent trois types de messages :

- Un message REQ (Request : Requête) est diffusé à tous les sites quand le site i veut entrer en
section critique.
- Un message REL (Release : Libération) est diffusé à tous les sites quand le site i a quitté sa
section critique.
- Un message ACQ (Acknowledge : Accusé de réception) est envoyé par le site j au site i, lorsque le
site j a bien reçu du site i un message REQ.

Structures de données utilisées :

- Chaque site gère une file de messages REQ ordonnée totalement par la relation  suivant le
couple (Estampille, Numéro de site) de chaque message.
- Les sites voulant entrer en section critique maintiennent en plus un ensemble ACKi où seront
stockés les numéros de sites ayant répondu par un ACK.

L’algorithme est le suivant :

Procédure exécutée par un site i qui veut entrer en Section critique

-Il envoie un message (REQ, Hi, i) à tous les sites, y compris lui-même (il place le
message REQ dans sa propre file d’attente Filei).
- Il initialise l'ensemble ACKi des réponses attendues.
Il ne pourra entrer effectivement dans sa section critique que s’il a reçu un accusé de réception (ACK)
de tous les autres sites et que sa requête (REQ) se trouve en tête de sa file d’attente Filei.

Procédure exécutée par un site j qui reçoit un message de type REQ en provenance du site i (REQ,
Hi, i) :

- il met à jour son horloge Hj selon l’algorithme de mise à jour des horloges locales,
- il place le message dans sa file d’attente Filej
- il envoie au site i un message d’accusé de réception (ACK, Hj, j).

Procédure exécutée par un site j qui sort de sa section critique :

- il envoie à tous les autres sites un message de libération (REL, Hj, j),
- il retire sa requête REQ de sa propre file d’attente Filej

LOUKAM Mourad
 6

Procédure exécutée par un site j qui reçoit un message de type REL en provenance du site i (REL, Hi,
i) :

- il met à jour son horloge Hj selon l’algorithme de mise à jour des horloges locales,
- il retire la requête REQ du site i de sa file d’attente Filej ainsi que tous les ACK
correspondant.

Pour un système ayant n sites, le coût (en nombre de messages) pour l'entrée et la sortie d'un seul
site est de : 3 * N messages.

Exemple :

Site 1 Site 2 Site 3

0
0 0

1
1 1

2
2 2

3 REQ, 2, 2 3

REQ, 3, 1
4
4
REQ, 3, 1
REQ, 2, 2
5

4
5
ACK, 5, 1

ACK, 5, 2
5
6
6

ACK, 5, 3 6

7
7
ACK, 7, 3
8

SC

REL, 9, 2 9
10 REL, 9, 2
10
SC

11
REL, 11,1
12
REL, 11,1

12

Fig Exemple de synchronisation avec l’algorithme de Lamport

Systèmes d’exploitation des Ordinateurs 7

3.2.2 Algorithme de Ricart-Agrawala :

Chacun des sites du système utilise une horloge scalaire qu'il synchronise lors de la réception de
messages.
Les messages envoyés sont de la forme (T, Hi, i).Chaque messages sera systématiquement envoyé
à tous les autres sites. Le type de message T peut être :

• REQ : (request) un tel message est envoyé lorsqu'un site veut entrer en section critique ;

• ACK : (acknowledge) un tel message est envoyé (soit immédiatement à la réception d'un
message de type REQ, soit ultérieurement à la sortie de section critique du site).
Un site a trois états possibles :
• OUT : il n'est ni en section critique, ni demandeur pour y entrer;

• IN : il est en section critique;

• READY : il a demandé à entrer en section critique et attend d'obtenir l'accord de tous les
autres sites.
Chaque site gère une file d'attente dans laquelle il place toutes les requêtes qu'il ne peut satisfaire
immédiatement. Les sites demandant l'entrée en SC maintiennent en plus un ensemble ACK où sont
stockées toutes les réponses reçues des autres sites.
L'algorithme est le suivant :
Procédure exécutée par un site i qui veut entrer en Section critique

− Mettre son étati à READY

− Diffuser le message (REQ, Hi, i) à tous les sites. Enregistrer sa propre demande dans Demandei =
(REQ, Hi, i)
− Initialiser l'ensemble ACKi qui va contenir les ACK attendues des autres sites.
− Initialiser la Filei qui va contenir tous les messages de type REQ qu'one ne peut pas satisfaire
immédiatement.
− Le site i entre en SC s'il a reçu les ACK de tous les autres sites. Il met alors son état à IN.

Procédure exécutée par un site j qui reçoit un message de type REQ ou ACK en provenance du site i :

− Mettre à jour l'horloge locale en utilisant la méthode de mise à jour des horloges scalaires.
− Si le message reçu est un ACK, l'ajouter à l'ensemble ACKj.
− Si le message reçu est un REQ , faire le traitement suivant :
Si [ (etatj = OUT) ou (etatj = READY)] et (Hi<Estampille de Demandej )
Alors Envoyer (ACK, Hj, j) au site i
Sinon Mettre le message (REQ, Hi, i) dans la Filej
finsi
Procédure exécutée par un site qui sort de sa section critique :

− Envoyer un ACK à tous les sites dont les REQ sont rangés dan,s la File j
− Mettre son état à OUT

Pour un système ayant n sites, le coût (en nombre de messages) pour l'entrée et la sortie d'un seul
site est de : 2 x (N-1) messages.

LOUKAM Mourad
 8

Exemple :