Cours SystDist

Cours sur les Systèmes Distribués
1. Introduction
1.1 Définitions
1.2 Objectifs et caractéristiques
1.3 Concepts matériels
1.4 Concepts logiciels
2. Communication dans les systèmes distribués

2.1 Couches de protocoles
2.2 Modèle Client Serveur
2.3 Appels de procédure
2.4 Communications de groupe
2.5 Quelques approches pratiques
3. Synchronisation dans les systèmes distribués

3.1 Gestion du temps
3.2 Election
3.3 Exclusion mutuelle
3.4 Transactions atomiques
3.5 Interblocage
1 Pr. Mustapha LALAM

1. Introduction
Un système informatique distribué peut être

caractérisé par les propriétés suivantes :
• Le système est constitué d’un ensemble de

composants matériels (ordinateurs, organes
d’E/S, processeurs spécialisés, dispositifs de
commande de mesure, . . )
• Les composants du système ne fonctionnent pas

de manière indépendante, mais coopèrent pour
l’exécution de tâches communes.
• Le système peut continuer à fonctionner

(éventuellement en mode dégradé) malgré les
défaillances partielles des composants ou du
réseau de communication.

1.2 Définitions du système distribué
Un système d’exploitation distribué fournit

aux utilisateurs l’accès aux diverses ressources
(matérielles et logicielles) proposées par le
système. Le système d’exploitation contrôle
l’accès à ces ressources.
Il existe fondamentalement deux schémas

complémentaires permettant de proposer ces
services :
• Systèmes d’exploitation de réseaux : les

utilisateurs sont au courant de la multiplicité
des machines et ils doivent accéder à ces
ressources, soit en se connectant à la machine
éloignée appropriée, soit en transférant les
données de la machine éloignée à leurs propres
machines.

• Systèmes d’exploitation distribués : les
utilisateurs n’ont pas besoin d’être au courant
de la multiplicité des machines. Ils accèdent aux
ressources éloignées de la même manière
qu’aux ressources locales.
Leslie Lamport donne une définition d’un

système d’exploitation distribué :
"One on which I cannot get any work done
because some machine I have never heard of has
crashed"
(Traduction : Un système sur lequel je ne peux

pas obtenir tout travail fait parce que, quelque
part, une machine dont je n'ai jamais entendu
parler est tombée en panne).
Un système distribué est un système qui

s’exécute sur un ensemble de machines sans
mémoire partagée, mais que l’utilisateur voit
comme une seule et unique machine au point
que la défaillance d’une machine dont
l’utilisateur ignore jusqu’à l’existence peut
rendre sa propre machine inutilisable . . .

Caractéristiques :
• Possédant un mécanisme de communication
inter processus unique et global permettant
le dialogue entre deux processus
quelconques.
• Possédant un mécanisme de protection

unique et global.
• Possédant un mécanisme de gestion de

processus unique.
• Possédant un ensemble d’appels système

disponibles sur toutes les machines.
• Possédant un noyau de système

d’exploitation identique, implanté sur toutes
les machines.
• Possédant un mécanisme de gestion de

mémoire identique.

Il existe plusieurs systèmes répartis. Ils
fournissent des services variés allant des
services d’exploitation de ressources aux
applications réparties :
- Les systèmes de fichiers répartis : NFS,

AFS (Andrew File System)
- Les systèmes Client-Serveur : Corba –
DEC – DCE – DCOM, . . .
- Les mémoires virtuellement réparties.
- Les systèmes de répartition des tâches.
- Etc . . .

1.2 Objectifs et caractéristiques
• Coût : plusieurs processeurs à bas prix.

• Puissance de calcul et de stockage : aucune
machine centralisée ne peut rivaliser.
• Transparence : la répartition de ressources
est masquée.
Transparence : ce terme s’applique à la
propriété d’indépendance, par rapport à la
localisation physique pour l’accès aux
services et aux informations. Cette propriété
permet, par exemple, d’utiliser un service
distant de la même manière qu’un service
local, ou de déplacer des informations ou des
services d’un site à un autre sans
changement visible pour les programmes ou
les personnes qui les utilisent. Il faut
néanmoins noter que, dans certains cas, la
transparence doit au contraire être évitée.

Citons deux cas :
- Mise au point d’applications réparties.

Lorsqu’on recherche l’origine d’une
défaillance, il faut pouvoir connaître la
localisation physique des données
manipulées ou le site d’exécution d’un
programme.
- Contrôle de l’exécution. Pour des raisons

de performance (répartition des charges
= load balancing), d’administration de
ressources, ou de sécurité, on peut
vouloir contrôler ou imposer
explicitement le site d’exécution d’un
service.

Parmi les Objectifs et caractéristiques, il y a
également :
• Localisation : la localisation des ressources

est non perceptible (on a l’impression que les
ressources sont locales).
• Migration : la migration des ressources est

possible sans transformation de
l’environnement utilisateur.
• Invisibilité : invisibilité de la duplication des

ressources.
• Concurrence : concurrence d’accès aux

ressources non perceptible (l’utilisateur ne la
perçoit pas).
• Invisibilité du parallélisme : invisibilité du

parallélisme sous-jacent offert par
l’ensemble de l’environnement d’exécution.

• Flexibilité/Modularité :
→ Noyaux systèmes monolithiques
contre micro noyau.
- L’approche micro noyau consiste à

disposer d’un noyau de système le plus
petit possible sur chaque machine et à
disposer de la plus grande partie des
services sur des serveurs distants.
- Cette approche s’oppose à l’approche du

noyau monolithique (chaque machine a
un noyau comportant la plupart des
services).
- Rien ne peut lui être enlevé sans

mettre en péril son fonctionnement,
- Aucune possibilité de voir les

ressources (ex fichiers) autrement
que par la vue fournie par le
système*.

* Pas complètement vrai . . . Si on
prend Unix System V R4.0 ou 4.4
BSD, le système permet de voir des
systèmes de fichiers de différents
types : UFS (Berkeley ⇒ rapide ), S5
(traditional System V ⇒ lent), NFS
en particulier, grâce au mécanisme de
Virtual File System et de Virtual
mode (VFS/V-mode) empruntés à
NFS.
- Les micro noyaux sont modulaires, très

souples, adaptables, répartis.
- Dans le micro noyau se trouvent : threads

(processus légers), ports, régions,
messages, identificateurs, etc . . .

- Au-dessus des micro noyaux se trouvent
des services qui créent des abstractions
utilisables à partir du noyau : processus,
fichiers, sockets, IPC, etc . . .
- Le micro noyau se caractérise par les

services minima :
- un mécanisme de commutation
interprocessus,
- La gestion de peu de mémoire,
- La gestion et l’ordonnancement de
quelques processus,
- Des E/S de bas niveau.
- Le micro noyau ne fournit pas de

systèmes de fichiers.
- Les micro noyaux les plus connus :

MACH-OSF1 (1986, CMU- Open
System Foundation) – CHORUS (1986,
INRIA) – AMOEBA (ACE, Université
d’Amsterdam) – GRAPEVINE (Xeros) –
SPRITE (Université de Berkeley) –

- V-SYSTEM ( Université de Stanford)
WINDOWS NT (Microsoft), etc . . .
• Flexibilité : Tolérance aux pannes / sûreté de

fonctionnement.
- mode normal : le système rend un

service qui respecte à tout moment les
spécifications* sur lesquelles reposent sa
conception.
* Spécification : comportement vérifiable
par un ensemble de prédicats/assertions
qui tient compte des entrées, des sorties
du système et du temps qui lui est imparti
pour exécuter son travail.
- mode dégradé : la perte de

fonctionnalité n’empêche pas les
spécifications d’être respectées mais avec
éventuellement une baisse de
performance.
- Mode panne : le comportement du

système est hors spécifications.

• Sécurité : Protection contre les accès non
autorisés.
- Propriétés visées :
- Contrôle d’accès,
- Authentification,
- Intégrité,
- Confidentialité,
- Non répudiation.
- Les techniques utilisées :
- Cryptographie à clefs privées ou à
clefs publiques,
- Fonctions univoques ou hachage,
- Signature,
- Protocoles de sécurité.

• Performances :
- Temps de réponse,
- Taux d’utilisation du système,
- Débit (nombre de travaux /heure),
- Pourcentage utilisé de la bande passante
du réseau.
• Gérer le grand nombre

- Beaucoup d’utilisateurs,
- Beaucoup de machines,
- Beaucoup de services,
- Beaucoup de trafics.
⇒ La centralisation est impossible.
Hétérogénéité–Intégrabilité–Extensibilité .
• Maintenabilité : pas pour les concepteurs . . .

mais pour les ingénieurs systèmes.

Remarques :
- Pour un Système d’exploitation distribué,
il faut des mécanismes de communication
logiciels pour faire coopérer :
- les noyaux des systèmes d’exploitation
locaux,
- les clients avec les serveurs offrant des
services systèmes (ex : Clients et
Serveurs NFS),
- les différents serveurs pour des soucis
de tolérance aux pannes, . . .
⇒ on utilise couramment des
sockets (points de communication)
ou des RPCs entre processus.
- Pour une application distribuée
(répartie), il faut des mécanismes de
communication similaires entre :
- Les exécutifs des langages,
- Les entités programmées dans ces
langages (ex entre objets JAVA),
⇒ on utilise couramment des
envois de messages qui seront
construits au-dessus de ceux offerts
par un système d’exploitation
distribué.
1.3 Concepts matériels/logiciels
Voir cours sur les architectures parallèles.

2.Communications dans les systèmes
distribués
• Dans un système distribué, il n’y a pas de

mémoire commune partagée. La
communication inter-processus est donc
complètement différente de celle qu’on a sur
les systèmes centralisés (avec les
sémaphores, les moniteurs, . . . ) ; elle
s’appuie sur le support de communication
(réseau) qui relie les ordinateurs.
• Un système (ou une architecture) réparti est

composé d’un certain nombre de processeurs
ou sites (entités de calcul), interconnectés
par un certain nombre de liaisons,
généralement appelées voies ou canaux ou
lignes de communication.

- Cette définition est très large et inclut les
réseaux à grande distance, les réseaux
locaux tout autant que les machines
parallèles à mémoires réparties.
- Le point commun à toutes ces structures

de calcul est l’absence de mémoire
partagée : tout échange d’information ne
peut se faire que par des opérations
d’envoi (Send) et de réception (Receive)
de messages, véhiculés sur des lignes de
communication.

• Dans les systèmes informatiques répartis, les
voies de communication, comme les
systèmes eux-mêmes, sont généralement
organisés comme une hiérarchie de couches.
Chacune de ces couches réalise un niveau
d’abstraction particulier, en permettant la
communication entre des entités définies à
ce niveau.

2.1 Couches de protocoles
- Les règles qui gèrent les communications

sont formalisées et on les appelle
protocoles.
- Un protocole est avant tout un accord sur

la façon dont les communications
doivent s’effectuer.
- Ne pas se conformer au protocole, rend

la communication très difficile voir
même impossible.

- Pour résoudre les problèmes posés par
les communications sans protocole,
l’ISO (International Standards
Organization :Organisation
Internationale de Normalisation) a défini
un modèle de référence qui identifie
clairement les différents niveaux d’une
communication, leur donne des noms
standards et décrit leurs fonctions.

- Dans le modèle ISO, la communication
est partagée en sept niveaux (07) ou
couches :
- Couche n°7 couche application,

- Couche n°6 couche présentation,
- Couche n°5 couche session
- Couche n°4 couche transport,
- Couche n°3 couche réseau,
- Couche n°2 couche liaison,
- Couche n°1 couche physique.

A chaque couche est associé un protocole.
Machine 1 Machine 2
Processus A Processus B
Protocole d’application
Couche 7 Application Application
Protocole Présentation
Présentation Présentation
Protocole de session
Session Session
Transport Transport
Réseau Réseau
Liaison Liaison
Protocole physique
Physique Physique
Support de communication

Description des couches :
• La couche physique : est responsable de la

manipulation des détails mécaniques et
électrique de la transmission physique d’un
flot de bits (adéquation des signaux). Cette
couche est implantée dans le matériel du
périphérique de gestion des signaux.
• Couche de liaison des données : est

responsable de la manipulation des trames
ou des parties de longueur fixe des paquets,
y compris toute détection et reprise en cas
d’erreur du périphérique de gestion des
signaux.

• Couche réseau : a la responsabilité de
fournir des connexions et d’effectuer le
routage des paquets dans le réseau de
communication, y compris la manipulation
d’adresse des paquets sortants, le décodage
des adresses de paquets entrants et le
maintien de l’information de routage. Les
routeurs travaillent à ce niveau.
• Couche de transport : est responsable des

accès de bas niveau au réseau et du transfert
des messages entre clients, y compris le
découpage des messages en paquets, le
maintien de l’ordre des paquets, le contrôle
de flux et la génération des adresses
physiques.

• Couche de session : est responsable de
l’implémentation des sessions ou des
protocoles de communication de processus à
processus.
• Couche de présentation : est responsable de

la résolution des différences de formats entre
les divers sites d’un réseau, y compris la
conversion des caractères et les modes semi-
duplex, duplex (échos caractère).
• Couche application : est responsable de

l’interaction directe avec les utilisateurs.
Cette couche traite le transfert de fichiers, les
protocoles de connexion à distance et le
courrier électronique ainsi que les schémas
pour les bases de données réparties.

Comment se fait la communication entre deux
machines ?
- Dans le modèle ISO, quand le processus

A de la machine 1 veut communiquer
avec le processus B de la machine 2, il
élabore un message et passe ce message
à la couche application de la machine 1.
Cette couche peut être, par exemple, une
procédure d’une bibliothèque mais elle
peut aussi être implantée d’une autre
façon (c’est-à-dire dans le système
d’exploitation, dans un coprocesseur
externe, . . . ). Le logiciel de la couche
application ajoute un entête (header) au
début du message et passe le message qui
en résulte à la couche présentation au
travers de l’interface des couches 6 et 7.
La couche présentation rajoute son entête
et passe le résultat à la couche session et
ainsi de suite.

- Certaines couches ne se contentent pas
d’ajouter des informations en début de
message, elles en ajoutent également à la
fin. Quand le message arrive en bas de la
pile (des couches), la couche physique
transmet le message.
- Quand le message arrive sur la machine

2, il remonte les couches et chacune de
celles-ci prend et examine l’entête qui lui
correspond.
- Le message finit par arriver au récepteur,

c’est-à-dire au processus B qui peut alors
répondre en suivant le chemin inverse.
- L’information qui est contenue dans

l’entête de la couche n° n est utilisée par
le protocole de la couche n° n.

Remarques :
- Le modèle ISO formalise certains des

premiers travaux réalisés sur les
protocoles des réseaux, mais il a été
développé à la fin des années 70 et il
n’est pas encore d’une utilisation
répandue.
- Une partie des fondements de l’ISO

constitue la pile de protocoles la plus
vulnérable et la plus largement utilisée
sous Unix pour l’Arpanet (devenu
Internet) .
- La plupart des sites Internet

communiquent encore par l’intermédiaire
du TCP/IP (Transmission Control
Protocol/Internet Protocol).

- La pile de protocoles TCP/IP possède
moins de couches que le modèle ISO.
Processus d’application des

Utilisateurs finaux
- Protocole de transfert de fichiers, FTP

- Protocole des terminaux à distance,
Telnet
Couches
- Protocole de transfert de messagerie
5-7
simple, SMTP
- Protocole du serveur de noms, NSP
- Protocole simple de gestion réseaux,
SNMP
Couche 4 TCP UDP
Couches IP
1-3
IEEE 802.X/X.25
Réseau local / Réseau

à distance
Légende :
- TCP : protocole de contrôle des transmissions.
- UDP : protocole des datagrammes utilisateurs.
- IP : protocole Internet.
- Datagramme : message de longueur fixe, appelé
paquet ou trame ou datagramme.

2.2 Modèle Client Serveur
Le modèle de base pour la structuration des

systèmes répartis met en jeu un processus
client qui demande l’exécution d’un service et
un processus serveur qui réalise ce mécanisme.
Client et serveur sont localisés sur deux

machines reliées par un réseau de
communication.
Le modèle client serveur garantit la protection

mutuelle du client et du serveur par la
séparation de leurs espaces d’adressage. Il
permet de localiser dans un serveur une
fonction partagée par plusieurs clients.

Le schéma classique d’organisation d’un
serveur est celui d’un processus cyclique :
While do begin receive (client, message) ;
Extract (message, service_id

<params>) ;
Case service_id of . . . id :begin do_service

[id](<params>, results) ; send (client, results) ;
End . . . end end.

Nous avons supposé que le serveur peut
exécuter plusieurs types de services, identifiés
par un nom service_id différent (par exemple,
pour un serveur de fichiers : lire_fichier,
écrire_fichier, imprimer_catalogue, etc. . . ).
Lorsque le serveur peut servir plusieurs

clients, il est intéressant de l’organiser comme
une famille de processus coopérants pour
permettre l’exécution concurrente de plusieurs
requêtes et exploiter ainsi un multi-processus
ou des E/S simultanées.

Le schéma classique comporte un
processus cyclique, le veilleur (daemon) qui
attend les demandes des clients. Lorsqu’une
demande arrive, le veilleur active un processus
exécutant qui réalise le travail demandé. Les
exécutants peuvent être crées à l’avance et
constituer un pool fixe, ou être crées à la
demande par le veilleur. Ce dernier schéma est
illustré ci-après :

Processus veilleur
While true do
begin
Receive (client, message) ;
Extract (message, service_id, <params>) ;
p :=create_processus (client, service_id,
<params>) ;
end ;
Processus exécutant
processus p :
Begin
do_service[service_id] (<params>,
results) ; Send (client, results) ;
exit ; . . . auto_destruction ;
end.

Notons qu’il n’y a pas identité entre la notion
de serveur et la notion de site. Plusieurs
serveurs peuvent coexister sur un même site.
Un serveur peut être réparti sur plusieurs sites

pour augmenter sa disponibilité ou ses
performances.

Inconvénient majeur du modèle Client Serveur
Bien que le modèle client serveur soit un

moyen élégant de structurer un système
d’exploitation distribué, il souffre d’une plaie
incurable :
les communications sont basées sur les

E/S.
Les procédures Send et Receive

correspondent principalement à des E/S. Or le
but des concepteurs de traitement réparti est
qu’il ressemble au traitement centralisé.
Avoir les E/S comme principe de base pose

donc un problème puisqu’elles ne sont pas un
concept clé des systèmes centralisés.

La solution à cet inconvénient est
l’introduction des appels de procédures à
distance (RPC = Remote Procedure Call) faite
par Birell et Nelson (1984). Ils suggèrent de
permettre aux programmes d’appeler des
procédures situées sur une autre machine.

2.3 Appels de procédure à distance (RPC)
• Le modèle des RPC apporte une solution

simple mais difficile à mettre en œuvre : une
machine demande l’exécution d’une
procédure à distance et pendant le
déroulement de la procédure, le processus
demandeur est suspendu (il se bloque sur
receive). Dans le principe, il ressemble à
l’appel de procédure dans un système
centralisé.
• Transparence pour l’utilisateur (même

interface des procédures), c’est-à-dire que
les RPC sont transparentes. La procédure
appelante n’a pas à savoir où se trouve la
procédure appelée et réciproquement.

• Au niveau système, les paramètres ne sont
pas sauvegardés (pile) localement mais
envoyés à la procédure distante via un
message.
• Le client (client stub = subrogé client)

prépare les paramètres (assemblage) et les
expédie au serveur. Quand le message arrive
au serveur, le noyau le donne à un subrogé
serveur (server stub) associé au serveur. Le
subrogé serveur a normalement appelé
receive et est bloqué en attente de réception
des messages. Il désassemble les paramètres
qui se trouvent dans le message et appelle
ensuite la procédure du serveur de façon
classique.

• Le serveur désassemble le paquet de
paramètres, demande l’exécution, prépare les
résultats, les assemble et les expédie au
client.
• Le client désassemble le paquet de résultats.

L’appel de procédure à distance (Birrel, 1984)
est un mécanisme qui permet à un processus p
implanté sur un site C d’exécuter une
procédure P sur un site S, avec un effet
globalement identique à celui qui serait obtenu
par l’exécution locale de P par C.
Son intérêt est d’étendre à un système réparti

une construction dont la sémantique est bien
connue.
Sa réalisation repose sur l’utilisation d’un

processus s (ou serveur) qui exécute la
procédure P sur le site S. Le processus client p
reste bloqué pendant l’exécution de P et il est
réactivé au retour de P.
Le principe de transparence s’applique aussi

bien pour le processus client que pour le
processus serveur, tout se passe comme si
l’appel était local.

On introduit à cet effet deux procédures,
appelées talons (stub = subrogé). Le talon
client, sur le site appelant, fournit au processus
client une interface identique à celle de la
procédure appelée ;
de même, le talon serveur, sur le site appelé,

réalise par le processus serveur une interface
identique à celle d’un appel local.
Chacun des subrogés, liés au programme du

processus client ou serveur sur le site
correspondant, fonctionne aussi comme un
représentant de l’autre processus (client ou
serveur) sur ce site.

En l’absence de défaillance, les fonctions du
talon client exécutées par le processus appelant
sont :
- mettre les paramètres d’appel sous une

forme permettant leur transport sur le site
réseau vers le site appelé ; c’est la
fonction d’emballage (marshalling),
- envoyer vers le site appelé un message

contenant l’identité de la procédure
appelée et les paramètres,
- provoquer le blocage du processus client,

en attendant la réponse du site appelé,
- lorsque la réponse arrive, le processus
client est réveillé,

- il poursuit son exécution dans le talon
client pour passer aux étapes suivantes :
- extraire du message de réponse les

résultats, s’il y en a, et les transporter
dans leur forme interne ; c’est la
fonction de déballage
(unmarshalling),
- exécuter le retour de procédure, avec

transmission des résultats ; tout se passe
alors, pour le processus client, comme
pour le retour d’appel de procédure
locale.

Sur le site appelé, le processus serveur appelle
le talon serveur et exécute les fonctions
suivantes :
- à partir du message reçu du client,

déterminer la procédure appelée et
déballer les paramètres,
- exécuter la procédure appelée en lui

passant les paramètres (s’il s’agit d’un
appel local).
Au retour de cet appel, l’exécution se poursuit

dans le talon serveur pour exécuter les étapes
suivantes : préparer le message de retour vers
le site appelant en emballant les éventuels
résultats :
- envoyer le message de retour au site
appelant,

- terminer l’exécution : soit par
autodestruction si le processus serveur a
été crée à la demande, soit par blocage,
s’il s’agit d’un serveur pris dans un pool.
La réalisation de programme d’emballage

et de déballage nécessite que soit défini un
format standard pour la représentation des
paramètres.
Comme les processus appelant appelé

s’exécutent dans des espaces d’adressage
différents, ces paramètres ne peuvent être
transmis que par valeur.
En cas de défaillance, l’appel de procédure

à distance doit respecter un comportement
spécifié.
Les spécifications diffèrent selon les

garanties à respecter sur le nombre
d’exécutions de la procédure appelée après une
défaillance du serveur ou du système de

communication, suivi d’une tentative de
reprise.
L’exécution ″au moins une fois″ est

acceptable si la procédure est idempotente
(c’est-à-dire si l’effet de deux appels
successifs est identique à celui d’un appel).
L’exécution ″au plus une fois″ est le cas le

plus fréquent.
L’exécution ″exactement une fois″

nécessite des mécanismes évolués par la
détection des erreurs et la redondance du
serveur.
Les programmes d’application répartis

disposent d’outils pour réaliser l’appel de
procédure à distance sans avoir à connaître le
détail des mécanismes décrits ci-dessus.

Ces outils reposent sur une spécification
des interfaces dans un langage approprié qui
définit pour chaque procédure susceptible
d’être appelée à distance une interface qui
comporte le nom de la procédure et, pour
chaque paramètre, son type et son sens de
transmission (argument ou résultat- conférer
livre Systèmes d’exploitation de Tanenbaum
page 474).
Un langage de spécification d’interfaces

communs à plusieurs langages de
programmation permet la communication entre
des programmes écrits dans différents
langages.
Il existe des générateurs (ou compilateurs)

de talons (stub) qui, à partir de la spécification

d’interfaces de procédures destinées à être
appelées à distance, produisent les talons client
et serveur nécessaires.
Un compilateur de talons engendre les

procédures d’emballage et de déballage, en
fonction de la description des paramètres et
réalise la liaison pour l’appel de procédure à
distance en identifiant la procédure appelée.

Comment se fait la localisation du serveur par
le client ?
- la solution est le nommage dynamique

(dynamic bending).
Le nommage dynamique est la

correspondance client – serveur.

2.3.1 Désignation (Serveur de
noms/Localisation)
Dans un système informatique, le nom

d’un objet est une information qui remplit
deux fonctions :
désigner l’objet, c’est-à-dire le distinguer

des autres objets du système ;
servir de voie d’accès à un objet pour

permettre son utilisation dans le système.

2.3.1.1 Nom et liaison
Un nom n’a pas de signification absolue :

il doit être interprété dans un contexte de
désignation qui définit l’ensemble des noms
valides et les règles d’interprétation de ces
noms.
Par exemple, dans Unix, un même fichier peut

être désigné par au moins quatre noms
différents : par un nom symbolique, par un
numéro attribué lors de son ouverture, par
l’adresse d’un descripteur en mémoire et par
l’adresse d’un descripteur sur disque.

Les règles d’interprétation des noms
spécifient la procédure qui, à partir d’un nom,
permet d’atteindre l’objet désigné.
Cette procédure comporte souvent plusieurs

étapes : l’objet est atteint à partir du nom à
travers une suite d’objets intermédiaires, ou
relais, qui constitue ce que l’on appelle une
chaîne d’accès.
En pratique, la fonction de désignation associe

un nom symbolique (en général une chaîne de
caractères) et un nom interne interprétable par
les couches basses du système ou directement
par le matériel.

Ce nom interne est souvent une adresse ou
encore un identificateur unique à partir duquel
le système peut retrouver l’adresse par
association statique ou dynamique à un nom
de niveau inférieur.
La liaison est l’action de constitution de la

chaîne d’accès.
La liaison peut être statique ou dynamique.

Dans le premier cas (statique), la
correspondance entre nom symbolique et
adresse est fixée une fois pour toute, soit lors
de l’écriture du programme, soit dans une
phase de chargement et l’édition de liens,
préalable à l’exécution.
Dans le second cas (dynamique), la liaison est

réalisée au moment de l’exécution, soit lors du
premier accès soit à chaque accès.
Une méthode générale pour réaliser la liaison

dynamique repose sur l’indirection à travers un
descripteur dont le nom est connu statiquement
et dont le contenu est modifiable.
Il est souvent utile de restreindre l’ensemble

des noms utilisables à un instant donné par un
processus, notamment pour des raisons de
protection ou d’efficacité.

La notion d’environnement permet d’y
parvenir.
Un environnement définit un sous ensemble

d’un espace de noms et les règles
d’interprétation des noms dans ce sous
ensemble.
Cette notion s’applique aussi bien aux noms

internes qu’aux noms symboliques.
Dans un environnement donné, un objet peut

être désigné par un nom local qui n’est
interprétable que dans cet environnement. Les
notions ci-dessus s’appliquent à tous systèmes
informatiques.

Dans les systèmes répartis apparaissent les
aspects spécifiques suivants :
- L’espace des noms a une grande taille,
- L’espace des noms évolue

dynamiquement, non seulement par
création de nouvelles entités, mais par
l’adjonction permanente de nouveaux
composants au système, ou par la
réorganisation de sa structure interne,
- La recherche de l’indépendance entre

entité logique et localisation physique
(transparence) conduit à utiliser
fréquemment la liaison dynamique entre
noms et objets,
- Des sous ensembles importants du réseau

peuvent ne pas être accessibles à un
instant donné, par suite de pannes ou de
déconnexions. Cela ne doit pas
compromettre la réalisation de la
désignation dans le reste du système.

2.3.1.2 Serveur de noms
2.3.1.2.1 désignation interne
Un nom interne est une information qui

désigne une entité dans un système réparti et
qui est destiné à l’usage interne du système.
Selon l’organisation du système, les noms

internes peuvent désigner des entités
différentes.

Les entités auxquelles on associe le plus
couramment des noms internes sont :
- Les machines sur réseau,
- Les unités d’information : fichiers –

segments ou objet selon l’organisation du
système.
- Les portes servant la communication.

Une porte est souvent associée à un
service : un processus demande le service
en envoyant un message à cette porte. La
notion de porte permet de dissocier
l’interface d’un service de son mode de
réalisation et de sa localisation physique
(une porte pouvant migrer d’un site à un
autre en conservant le même nom).

Les propriétés requises d’un nom interne sont
les suivantes :
- Il doit désigner un objet de manière

unique ; deux objets distincts ne doivent
pas avoir le même nom ; en revanche un
même objet peut être désigné par
plusieurs noms.
- Il doit permettre de retrouver de manière

efficace l’objet désigné ; l’unicité est en
général obtenue en concaténant
l’identification unique de la machine sur
laquelle l’objet désigné a été crée et une
identification unique locale à cette
machine (par exemple la valeur d’un
compteur ou d’une horloge absolue).

Pour retrouver un objet à partir de son nom
interne, une solution possible est d’inclure
dans le nom de l’objet une information sur
sa localisation physique.
L’inconvénient de cette solution est qu’un

objet qui se déplace doit changer de nom,
ce qui est contraire au principe de la
transparence. Si cet événement est très peu
fréquent, on peut tolérer les inconvénients
qui en résultent.
Ainsi une adresse interne permet

d’atteindre une machine en identifiant le
réseau sur lequel elle se trouve, mais doit
être modifiée si une machine est déplacée
d’un réseau à un autre.

Pour des objets plus mobiles, il est
néanmoins souhaitable de maintenir
invariants les noms internes (car ils
peuvent être copiés et il est peu
envisageable de conserver des liens
inverses vers toutes les copies d’un nom).
En conséquence, si la localisation physique

d’un objet figure dans le nom interne, elle
n’a qu’une valeur d’identification si l’objet
peut migrer. Les méthodes utilisées pour
retrouver un objet dépendent entre autres
de la fréquence de la migration.
- Si la migration est peu fréquente, l’objet

est le plus souvent encore sur son site
d’origine. Lorsqu’un objet migre, le
système place sur son site d’origine un
lien de poursuite indiquant son nouveau
site.

- Si la migration est fréquente, la méthode
ci-dessus est coûteuse car les liens de
poursuite sont nombreux.
Dans ce cas, il faut utiliser des méthodes

pour accélérer la recherche, comme
l’entretien d’un cache qui associe sur
chaque site les noms et les localisations
pour éviter de répéter une recherche longue
en cas d’accès rapprochés.
En dernier ressort, on doit recourir à une

méthode de diffusion, mais une telle
recherche alourdie doit rester l’exception
étant donné son coût élevé.

2.3.1.2.2 Désignation symbolique
Un espace des noms qui est un ensemble

d’identificateurs sans structure interne est dit
″plat″.
Cette absence de structure présente deux

inconvénients importants lorsque la taille de
l’espace est importante : la recherche implique
d’explorer tout l’espace ; les risques de conflit
restreignent le libre choix des noms.
C’est pourquoi l’espace des noms symboliques

a généralement une structure hiérarchique qui
réduit ces inconvénients.

Un exemple usuel, dans un système centralisé,
est le mode de désignation des fichiers au
moyen d’une arborescence de catalogues.
Dans un système réparti, il est également très

courant de trouver une structure arborescente
de l’espace des noms.
Le problème de l’évolution d’un tel espace est

important dans un système réparti où la
composition et l’organisation du système
peuvent être modifiées.
Deux cas fréquents d’évolution sont la

combinaison d’espaces préexistants pour
former un nouvel espace unique et la
réorganisation interne.
Le problème de la combinaison d’espaces des

noms existants se pose lorsque l’on souhaite
réunir plusieurs machines ou sous systèmes
dont chacun a déjà son propre espace des
noms, par exemple des fichiers ou des usagers.

On souhaite ne pas modifier le mode de
désignation des fichiers locaux sur une
machine donnée. Nous supposons que chaque
machine utilise localement une organisation
arborescente de l’espace des noms.
Deux méthodes sont couramment utilisées :
- Création d’une super racine virtuelle. Les

espaces des noms existants sont
regroupés sous une ″super racine″ dont
les feuilles sont les racines des espaces
de noms locaux. Chacune de ces racines
doit elle-même recevoir un nom pour la
distinguer des autres. On construit ainsi
un environnement universel, tout en
préservant l’usage antérieur des
environnements locaux.
- Montage logique. On crée un lien entre

une entrée dans un catalogue et une
arborescence sur une machine distante.

On peut ainsi construire un nouvel espace
de noms global qui englobe les espaces
initiaux mais qui n’est plus une
arborescence. La structure de cet espace
peut devenir complexe si des règles
simplificatrices ne sont pas établies pour le
montage. Une règle courante consiste à
monter partout les catalogues complets
d’une machine sous le nom symbolique
attribué à cette machine. Ce qui permet à
un usager de retrouver le même
environnement sur tous les sites.

2.3.1.2.3 Serveur de désignation
La correspondance entre noms

symboliques et noms internes est souvent
réalisée, dans les systèmes répartis, par un
service appelé service de désignation.
Ce service est mis en œuvre par un ensemble

de serveurs de noms (name servers).
Un serveur de noms est un composant

important d’un système réparti.

Le service qu’il fournit doit répondre aux
exigences suivantes :
- Disponibilité, car le bon fonctionnement

du serveur de noms conditionne l’accès
des utilisateurs aux autres services du
système.
- Efficacité, car le serveur de noms est

consulté souvent.
- Capacité d’évolution pour permettre

l’adjonction, la suppression ou le
déplacement de composants du système.

Notons qu’au moins un serveur de noms doit
être connu directement par un nom interne ou
une adresse, défini statiquement ou mis à jour
par l’administration du système, et
communiqué, à tout client lors de sa connexion
au système.
La disponibilité du service de désignation est

obtenue par redondance. Deux méthodes sont
utilisées :
- Plusieurs serveurs indépendants peuvent

chacun assurer la totalité du service et
leur liste est connue à priori de tout
utilisateur du système. En cas de
défaillance d'un serveur, les clients
s'adressent au serveur suivant la liste.
- Plusieurs serveurs coopèrent à la

réalisation du service. L’organisation
doit permettre de continuer à assurer le
service en cas de défaillance d’un ou
plusieurs serveurs.

Par exemple, on peut distribuer les noms
entre les serveurs de manière que les objets
les plus importants soient accessibles via
au moins deux serveurs distincts.

2.3.3 Localisation de ressources
Un objet que l’on veut atteindre peut se

trouver sur n’importe quel site ou même
migrer entre plusieurs sites.
Pour pouvoir accéder à cet objet, il faut

d’abord pouvoir le localiser à partir de
l’information disponible :
un identificateur global unique que nous

appellerons Oid (qui est généralement
construit à l’aide d’une estampille.
L’estampille d’un événement est la valeur de
l’horloge logique pour cet événement).

Si l’objet ne migre pas, la localisation de
l’objet comporte la recherche de l’adresse
réseau de son site de résidence que l’on peut
retrouver grâce à l’estampille constituée de la
référence du site de création et d’un numéro de
génération sur ce site.
Si l’objet peut migrer, il devient nécessaire

d’utiliser une des heuristiques suivantes :

- Recherche sur le site de création. On fait
l’hypothèse que l’objet n’a pas migré et
on le recherche sur le site de création. Si
l’objet a migré, le service de localisation
installe sur ce site un lien de poursuite
indiquant le site détenteur de l’objet. En
cas de migrations fréquentes de l’objet, il
devient nécessaire de raccourcir les liens
de poursuite afin de désigner la
localisation d’un objet avec le minimum
d’indirections.
- Recherche dans un cache de localisation.

Sur chaque site, le service de localisation
entretient un cache contenant la dernière
localisation connue pour les objets
récemment accédés. En cas d’échec dans
la consultation des caches, il peut être
nécessaire de diffuser d’abord
partiellement et de manière non fiable,
puis éventuellement à tous les sites de
manière fiable le signal de recherche.

2.4 Communications de groupe
A l’opposé de la communication ″un vers

un″ entre deux processus, on distingue la
communication de groupe : un vers n.
Un groupe est un ensemble de processus qui

agissent ensemble d’une façon spécifiée par
le système ou l’utilisateur.
Un message envoyé à un groupe doit être

reçu par tous les processus du groupe. Les
problèmes à résoudre sont :
- L’accès au groupe (qui à quel groupe ?),
- L’adressage,
- La gestion des groupes (créer, supprimer,

ajouter un processus, . . .).

2.5 Quelques approches pratiques
Séances de travaux pratiques

3.Synchronisation dans les systèmes distribués
3.1 Gestion du temps
3.5.1 Ordre sur les événements
L’exécution d’une application sur un

système réparti génère un ensemble
d’événements.
Un événement est l’envoi d’un message, la

réception d’un message (ces événements
mettent en jeu un site et un canal) ou toute
autre action exécutée par un site (on parle alors
d’événement interne).

On se place dans le cadre d’un système
asynchrone où les sites et les canaux évoluent
à leurs propres vitesses et l’on suppose qu’un
site est constitué d’un seul processeur et on
confondra les termes processus (processeur) et
site.

Toute exécution d’une application sur un tel
système est caractérisée par deux contraintes
séquentielles fondamentales :
- Les événements produits sur un site

donné sont totalement ordonnés dans le
temps : si l’on considère de tels
événements l’un est produit avant l’autre.
- Si l’on considère un message m,

l’événement émission(m) précède
l’événement réception(m). De plus tous
les événements qui précèdent
émission(m) précèdent également tous
les événements précédés par
réception(m).

Ces deux contraintes séquentielles structurent
l’ensemble des événements en une relation
d’ordre partiel (notée : →) appelée précédence
causale.
S1
S2 b
S3 a
Evénements lors d’une exécution

Si l’on considère 2 événements a et b tel que
a → b alors l’événement a appartient aux
causes potentielles de l’événement b (voir
figure ci-dessus).
Cette relation permet une meilleure

compréhension de ce qu’est une exécution
répartie et en conséquence constitue un
élément de référence pour définir des
primitives de communication et de
synchronisation adaptées aux systèmes
répartis.

3.1.2 L’ordre causal
Définition d’un ordre causal
L’ordre causal étend aux réceptions de

messages les relations de précédence qui
peuvent exister sur leurs émissions.
Considérons donc les émissions de 2 messages

e1=émissiont(m1) et e2=émission(m2) telles que
d’une part e1 → e2 et que d’autre part m1 et m2
aient le même site destinataire.

L’ordre causal indique qu’alors on doit avoir :
réception (m1) → réception(m2)
Ainsi sur la figure suivante le message m1 doit

être délivré à S3 avant le message m2.
S1
m
S2
m1 m2
S3
Illustration de l’ordre causal

Comme on le voit l’ordre causal permet de
réduire le non-déterministe dû aux délais de
transfert arbitraires propres au contexte
asynchrone.
La fourniture d’un message à un site dépend

de l’état du système perçu par l’émetteur de ce
message au moment de l’émission.
Si l’on considère le cas particulier de 2 sites E

et R où E envoie des messages à R alors
l’ordre causal se confond avec la propriété
FIFO du canal de E vers R (canal sans
déséquencement i.e conservant l’ordre des
messages).
La relation de précédence causale est un ordre

partiel ; elle traduit une dépendance
potentielle : pour que a puisse être la cause de
b, il est nécessaire que a → b.

Deux événements sont dits concurrents (ou
causalement indépendants) si aucun des deux
ne précède causalement l’autre, et ne peut
donc influer sur lui. On écrit :
a // b ⇔ non (a → b) et non (b → a).

3.1.3 Ordonnancement par estampille
Une méthode pratique pour ordonner les

événements dans un système réparti est
d’utiliser la relation de précédence causale.
Sur chaque site Si est crée un compteur Hi à

valeurs entières (horloge logique), initialisé à
0 qui sert à dater les événements sur ce site.
A chaque événement e arrivant sur Si la

valeur Hi est incrémentée de 1 et la date de e,
notée Hi(e) est par définition la nouvelle
valeur de Hi.
Pour garantir la précedence causale, tout

message m émis par Si porte une estampille
E(m) qui est sa date d’émission et le site Sj
qui reçoit m exécute :
Hj :=max(Hj, E(m))+1.

La relation ainsi définie n’est pas un ordre
strict ; en effet des événements causalement
indépendants arrivant sur des sites différents
peuvent avoir la même date.
Pour obtenir un ordre strict, il suffit de

définir un ordre arbitraire entre les sites.
Si a et b sont des événements arrivant

respectivement sur les sites Si et Sj, on peut
définir comme suit une relation d’ordre total
strict, notée ⇒ :
a ⇒ b si Hi(a) < Hj(b) ou (Hi(a)=Hj(b) et i
< j).
Un événement est maintenant daté par le

couple (numéro de site, estampille).

3.1.4 Ordonnancement par horloges
vectorielles
La relation d’ordre ⇒ définie par les

estampilles ne suffit pas pour établir une
relation de causalité entre deux événements.
On peut simplement dire que l’ordre total

défini par la relation ⇒ est compatible avec
l’ordre partiel de précédence causale → : si
a⇒ b, ou bien a → b ou bien a et b sont
causalement indépendants (aucun événement
ne peut être la cause de l’autre).
L’ordre total introduit par les estampilles

″efface″ artificiellement la précédence
causale.

Il est néanmoins utile de pouvoir déterminer
la dépendance ou l’indépendance causale
entre deux événements :
- Mise au point de programmes répartis.

La dépendance entre deux événements
est une notion pour la recherche des
causes potentielles d’une erreur.
- Placement d’une application répartie. La

mesure du degré d’indépendance des
calculs est nécessaire pour évaluer les
gains liés à la mise en œuvre d’un calcul
sur différents processeurs.
- Réalisation efficace d’algorithme ne
nécessitant par un ordre total.

Le mécanisme des horloges vectorielles a été
introduit pour caractériser la dépendance
causale.
Soit n le nombre de sites. Sur chaque site Si,

i=1, . . . n, on définit une horloge vectorielle
comme vecteur Vi[1 . . n ] initialisé à 0.
Lorsqu’un événement se produit sur le site Si,

on exécute Vi[i] :=Vi[i]+1. Chaque message m
porte comme estampille Vm l’horloge
vectorielle Vi du site émetteur.
A la réception d’un message (m, Vm), le site

récepteur, soit Si, exécute Vi[j] := max (Vi[j],
Vm[j]) pour j=1, . . . ,m

Appelons passé d’un événement a l’ensemble
constitué de a lui-même et des événements qui
précédent causalement a.
Grâce à leur construction, les horloges

vectorielles peuvent être interprétées comme
suit :
si un événement a est daté par le vecteur
Va, alors :
Va[j]= nombre d’événements du passé de a

sur le site Sj.
S Va[j] = nombre total d’événements du

passé de a.

Définissons une relation d’ordre partiel entre
horloges vectorielles :
V <= W ⇔ quelque soit j, V[j] <= W[j]
V < W ⇔ V <= W et V < > W
V // W ⇔ non (V <= W) et non (W <= V)
La relation d’ordre partiel entre horloges

vectorielles reflète la relation de précédence
causale et peut être exprimée comme suit :
Soit deux événements a et b, datés

respectivement par les vecteurs Va et Vb,
alors :
a → b ⇔ Va < Vb.
a et b causalement indépendants ⇔ Va // Vb.

Comment les processus coopèrent pour
résoudre des problèmes ou utiliser les
ressources ?
La synchronisation est plus difficile dans les

systèmes distribués que dans les systèmes
centralisé. Il n’y pas d’horloge unique, les
algorithmes sont distribués.

3.2 Election
Le problème de l’élection consiste à choisir

un processus et un seul parmi plusieurs.
L’identité du processus élu est indifférente :

les propriétés requises sont l’existence et
l’unicité.
Le problème de l’élection se pose souvent,

dans la pratique, lorsqu’il faut réagir à une
défaillance.
Si plusieurs processus détectent la

défaillance, l’un d’entre eux (et un seul) doit
prendre les mesures appropriées.

Citons deux exemples classiques de
l’élection :
- Système de type maître – esclave. Une

organisation où un processus maître
unique contrôle le travail de plusieurs
processus esclaves est courante,
notamment pour la gestion d’information
en copies multiples ou pour la réalisation
de serveurs constitués de plusieurs sites
coopérant. La défaillance d’un esclave
est traitée par le maître. Lors de la
défaillance du maître, un esclave et un
seul doit se substituer au maître.
L’algorithme d’élection est applicable
pour la désignation d’un nouveau maître.
- Détection de la perte d’information qui

doit être reconstituée. L’élection sert à
déterminer le processus chargé de cette
tâche.

Le traitement de la perte d’un jeton
circulant en est un exemple typique qui sert
de base à la présentation de ce qui suit.
Le jeton circulant de manière continue sur

l’anneau, chaque site peut détecter sa perte
au moyen d’une horloge de garde.
Le choix du délai de garde nécessite de

connaître une limite supérieure de la durée
d’un tour du jeton.
Il faut éviter que plusieurs sites, ayant

détecté la perte, ne régénèrent chacun un
jeton.
Comme le choix de l’élu est arbitraire, on

choisit par convention, le processus restant
de plus grand numéro.

L’algorithme que nous décrivons
maintenant, procède par filtrage :
- Chaque processus initiateur de
l’élection transmet sur l’anneau un
message de candidature portant son
numéro.
Un processus qui reçoit un tel message

l’arrête s’il porte un numéro inférieur
au sien propre et devient lui-même
candidat. Dans le cas contraire, il
transmet le message.
Seul le message du processus de plus

grand numéro fait donc un tour complet
et revient à son émetteur qui est alors le
seul élu.
Cet algorithme d’élection permet de choisir

le processus qui régénère le jeton en cas de
perte.

3.3 Exclusion mutuelle : un algorithme
distribué
L’algorithme demande l’existence d’un
ordre total sur tous les événements du système.
Quand un processus veut entrer en section
critique :
- Il construit un message contenant le nom

de la section critique dans laquelle il veut
entrer, son numéro de processus et
l'heure courante.
- Il envoie ce message à tous les autres

processus y compris lui-même.
En supposant que l’émission des messages est

fiable, chaque message est acquitté.

Quand un processus reçoit un message
demande d’entrée en section critique :
- Il prend une décision qui dépend de son

état et de la section critique sollicitée par
le message.
- Si le récepteur n’est pas dans la

section critique et ne veut pas entrer
dans celle-ci, il retourne simplement
un message OK à l’émetteur.
- Si le récepteur est déjà dans la section

critique, il ne répond pas, il mémorise
la demande dans une file d’attente.
- Si le récepteur veut entrer en section

critique mais ne l’a pas encore fait, il
compare l’estampille du message
venant d’arriver à celle contenue dans
le message qu’il a envoyé aux autres.

La plus ancienne gagne. Si le message
est plus vieux, le récepteur répond par
un message OK. Si c’est l ‘estampille
de son message qui est la plus
ancienne, le récepteur mémorise la
demande et n’envoie rien.
Après avoir envoyé ses demandes d’entrée

en section critique, un processus (demandeur)
se met en état d’attente jusqu’à ce que tous les
autres lui donnent leur autorisation.
Dès que toutes les autorisations sont

accordées, il peut entrer en section critique.
Quand il sort, il envoie un message OK à

tous les processus présents dans la file
d’attente et les supprime tous de la file.

Dans les conditions normales, cet algorithme
fonctionne correctement et réalise l’exclusion
mutuelle sans interblocage ni privation.
L’entrée en section critique nécessite 2(n-1)
messages.
Que se passe-t-il quand une machine est en

panne ?

L’algorithme est distribué. Toutes les
machines y sont impliquées. Quand une
machine est bloquée, tout le reste est bloqué.
Le problème de cet algorithme est que s’il

y a n ordinateurs, il y a n points faibles
(contrairement à un algorithme centralisé où il
y aurait 1 point faible).
Correction
Quand un message arrive, il doit être
acquitté avec accord ou refus.
L’émetteur utilise un temporisateur et arme un

délai quand il envoie une demande vers les
autres machines. Si au bout du délai de
temporisation il n’a pas obtenu d’acquittement,
le message est déclaré perdu et l’algorithme
peut fonctionner sans la machine concernée.

Cours SystDist

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Cours SystDist

Titre original :

Transféré par

Droits d'auteur :

Cours sur les Systèmes Distribués

2. Communication dans les systèmes distribués

3. Synchronisation dans les systèmes distribués

1 Pr. Mustapha LALAM

Un système informatique distribué peut être

• Le système est constitué d’un ensemble de

• Les composants du système ne fonctionnent pas

• Le système peut continuer à fonctionner

2 Pr. Mustapha LALAM

 Un système d’exploitation distribué fournit

Il existe fondamentalement deux schémas

• Systèmes d’exploitation de réseaux : les

3 Pr. Mustapha LALAM

 Leslie Lamport donne une définition d’un

(Traduction : Un système sur lequel je ne peux

 Un système distribué est un système qui

4 Pr. Mustapha LALAM

• Possédant un mécanisme de protection

• Possédant un mécanisme de gestion de

• Possédant un ensemble d’appels système

• Possédant un noyau de système

• Possédant un mécanisme de gestion de

5 Pr. Mustapha LALAM

- Les systèmes de fichiers répartis : NFS,

6 Pr. Mustapha LALAM

• Coût : plusieurs processeurs à bas prix.

7 Pr. Mustapha LALAM

- Mise au point d’applications réparties.

- Contrôle de l’exécution. Pour des raisons

8 Pr. Mustapha LALAM

• Localisation : la localisation des ressources

• Migration : la migration des ressources est

• Invisibilité : invisibilité de la duplication des

• Concurrence : concurrence d’accès aux

• Invisibilité du parallélisme : invisibilité du

9 Pr. Mustapha LALAM

- L’approche micro noyau consiste à

- Cette approche s’oppose à l’approche du

- Rien ne peut lui être enlevé sans

- Aucune possibilité de voir les

10 Pr. Mustapha LALAM

- Les micro noyaux sont modulaires, très

- Dans le micro noyau se trouvent : threads

11 Pr. Mustapha LALAM

- Le micro noyau se caractérise par les

- Le micro noyau ne fournit pas de

- Les micro noyaux les plus connus :

12 Pr. Mustapha LALAM

• Flexibilité : Tolérance aux pannes / sûreté de

- mode normal : le système rend un

- mode dégradé : la perte de

- Mode panne : le comportement du

13 Pr. Mustapha LALAM

14 Pr. Mustapha LALAM

• Gérer le grand nombre

• Maintenabilité : pas pour les concepteurs . . .

15 Pr. Mustapha LALAM

1.3 Concepts matériels/logiciels

Voir cours sur les architectures parallèles.

17 Pr. Mustapha LALAM

• Dans un système distribué, il n’y a pas de

• Un système (ou une architecture) réparti est

18 Pr. Mustapha LALAM

- Le point commun à toutes ces structures

19 Pr. Mustapha LALAM

Un système d’exploitation distribué fournit

Leslie Lamport donne une définition d’un

Un système distribué est un système qui