SUPPORT DE COURS SE2 (CHAPITRE3 COMMUNICATION INTERPROCESSUS) - 2023-2024 - VF - Aff

Université de Bejaia
Faculté des sciences exactes

Département d’Informatique
Systèmes d’exploitation 2 (L3 Info,
SUPPORT DE COURS:
SYSTÈMES D’EXPLOITATION 2
UAMB)
(L3 Informatique)
Chargé de cours:
Année: 2023/2024
Dr.KHENOUS Lachemi 1
UAMB)
Chapitre 3:
INTERPROCESSUS
COMMUNICATION
2
Chapitre 3: Communication Interprocessus
1.Introduction
Les processus ne sont pas des entités indépendantes. Ils
coopèrent souvent pour traiter un même problème ou se mettent en
compétition pour utiliser une ressource partagée. Ces processus

UAMB)
peuvent s’exécuter en parallèle sur un même ordinateur
(monoprocesseur ou multiprocesseurs) ou bien sur des ordinateurs
différents. Ils doivent alors s’échanger des informations
(communication interprocessus).
Processus A Processus B
Moyen de
communica
tion
3
2. Communication interprocessus
La communication interprocessus peut se faire de différentes

manière:
A. Communication par mémoire partagée (systèmes centralisés);
B. Communication par messages (systèmes distribués);
UAMB)
l’implémentation de la communication est réalisée comme suit:
A. Tubes Anonyme (ou ordinaire) / nommé (ou FIFO)
B. Communication IPC:
1) file de message,
2) mémoire mappée,
3) sémaphores.
C. Communication par sockets
4
2.1. Communication interprocessus par variable partagée

Un modèle de communication entre processus par variable

partagée (mémoire commune) est celui où un processus produit une
information et un autre l’utilise. Il existe plusieurs problèmes de ce
type. Nous allons étudier quelques uns en montrant comment
UAMB)
synchroniser l’accès à cette mémoire partagée.
2.1.1. Problème du Producteur / Consommateur

Le producteur doit pouvoir ranger en zone commune de la
mémoire (Tampon ou Buffer) des données qu'il produit en
attendant que le consommateur soit prêt à les consommer. Le
consommateur ne doit pas essayer de consommer des données
inexistantes. Tampon de taille fixe
Producteur Consommateur 5

 Hypothèses :
• les données (messages) sont de taille constante.

• les vitesses respectives des deux processus (producteur
consommateur) sont quelconques.
UAMB)
 Exemples :
• Le processus clavier produit des caractères qui sont consommés par le
processus d’affichage à l’écran.
• Le pilote de l’imprimante produit des lignes de caractères qui sont
consommées par l’imprimante.
• Un compilateur produit des lignes de codes consommés par l’assembleur.
 Spécifications des communications

• Un message donné n’est retiré qu’après avoir été déposé et la place qu’il
occupe n’est libérée qu’après avoir été lue.
6

• Les messages ne doivent pas être perdus ; si le tampon contient N

messages non retirés, on ne peut y déposer de messages supplémentaires.
• Un moyen d’assurer la synchronisation consiste à faire attendre ou à

UAMB)
bloquer un processus qui tente d’exécuter une opération « impossible »

(dépôt dans un tampon plein ou retrait depuis un tampon vide).
• Les conditions de synchronisation peuvent donc s’exprimer ainsi, en

désignant par n le nombre de messages contenus dans le tampon et non
encore1 retirés
Règle : . Un ensemble de règles s’imposent:
PRODUCTEUR
Le producteur ne peut Faire toujour
pas ranger un objet si le <Produire un objet>
tampon est plein : si nb d'objets dans tampon < N alors
<déposer l'objet dans le tampon>
Franchissement fsi
(déposer) : n<N (i.e., Fait
tampon non plein) 7

Règle 2 : CONSOMMATEUR
Le consommateur ne peut Faire toujours
prendre un objet si le tampon si nb d'objets dans tampon > 0 alors
est vide : <prendre l'objet>
<consommer l'objet>
Franchissement (retirer) : fsi
Fait
UAMB)
nb > 0 (i.e., tampon non

vide)
Règle 3 :
Exclusion mutuelle au niveau de l'objet : Le consommateur ne peut
prélever un objet que le producteur est en train de ranger.
Règle 4 :
Si le producteur (resp. consommateur) est en attente parce que le
tampon est plein (resp. vide), il doit être averti dès que cette condition
cesse d'être vraie.
8

 Gestion du tampon:
Un cas fréquent de la politique de gestion du tampon est la façon circulaire:
• les messages sont alors retirés dans l’ordre de leur dépôt.
• deux variables caractérisant l'état du tampon:
 NPLEIN : nombre d'objets dans le tampon (début : 0)
 NVIDE : nombre d'emplacements disponibles dans le tampon (N au début).
UAMB)
CONSOMMATEUR :
Faire toujours
si NPLEIN > 0 alors NPLEIN -- / * s'il existe au moins un
sinon s'endormir objet dans le tampon.*/
finsi
<Prélever l'objet dans le tampon>
si producteur endormi alors réveiller le producteur
sinon NVIDE ++
finsi
<Consommer l'objet>
Fait
9

PRODUCTEUR :
Faire toujours
<Produire un objet>
//début de bloc ininterruptible
si NVIDE >0 alors NVIDE -- /*s'il existe au moins un emplacement
sinon s'endormir vide dans le tampon */
UAMB)
finsi // fin de bloc ininterruptible

<Ranger l'objet dans le tampon>
si consommateur endormi alors réveiller le consommateur
sinon NPLEIN ++
fsi
Fait
10

2.1.2.1) Solution avec des Sémaphores
On peut considérer NVIDE (resp. NPLEIN) comme un sémaphore pour

synchroniser le producteur et le consommateur sur le nombre d’espace
libres (resp. le nombre d’éléments consommable) dans le tampon :
UAMB)
PRODUCTEUR CONSOMMATEUR
Faire toujours Faire toujours
<Produire un objet> P(NPLEIN)
P(NVIDE) <prélever un objet>
<déposer un objet> V(NVIDE)
V(NPLEIN) <consommer l'objet>
Fait
Fait 11

2.1.1.1) Solution avec des Sémaphores

 Cas où le nombre de producteur (consommateur) est supérieur à 1
Un sémaphore Mutex (initialisé à 1) pour exclusion mutuelle sur
l’accès au tampon.
PRODUCTEUR () CONSOMMATEUR ()
UAMB)
Faire toujours Faire toujours

<Produire un objet> P(NPLEIN);
P(NVIDE); P (MUTEX);
P (MUTEX); objet = tampon [tete];
tampon[queue] = objet; tete = (tete ++) % N;
queue = (queue ++) % N; V (MUTEX);
V (MUTEX); VNVIDE);
V(NPLEIN); <consommer l'objet>
Fait 12
2.1.1.2) Solution avec les moniteurs

Moniteur ProdCons (* moniteur, condition : types prédéfinis*)

Condition plein, vide ;
Entier nb ; /*pour compter le nombre d’objets dans le tampon, sa valeur est entre 0 et N */
procédure deposer (e : element)
debut
UAMB)
si nb = N alors plein,wait; /* on met le processus producteur en attente dans la file

correspondant à la condition plein si le tampon est plein */
fin // Seul un plein.signal réveillera le processus.
Entrer (e) ; //ranger le message dans le tampon
nb nb+1 ; // incrémenter le nombre d’éléments dans le tampon.
si nb = 1 alors vide.signal ; /* s’il y à un élément dans le tampon càd, le tampon
était vide avant le dépôt de l’élément alors on réveille un processus endormi*/
fin
fin
13

Procedure retirer (var e: element)

debut
si nb = 0 alors vide.wait ; fin /* on met le processus consommateur en attente dans
la file correspondant à la condition si le tampon est vide */
// seul un vide.signal réveillera le processus.

<Sortir (e) > //retirer l’ élément du tampon.
UAMB)
nb nb - 1; // décrémenter le nombre d’éléments dans le tampon
si nb = N-1 alors plein.signal ; /*réveille du processus (producteur) endormi,

fin parce que le tampon était plein avant le retrait. */
Fin
Debut (*initialisation du moniteur*)
nb=0 ;
Fin
Fin ProdCons. /* fin du moniteurs*/
Remarque : Dans cette solution, le code de la SC est à l’intérieur du moniteur. 14


Codes des processus producteur/consommateur
Processus Producteur Processus Consommateur

Début début
répéter répéter
<Produire un élément > ProdCons .retirer (element)
UAMB)
ProdCons.deposer (element) < Consommer l’élément>

Jusqu'à faux Jusqu'à faux
fin Fin
 Exécution des deux processus producteur et consommateur en parallèle,

en utilisant les instructions ParBegin / ParEnd ou fork/join.
ParBegin producteur; Consommateur ParEnd.
15

2.1.2. Problème des lecteurs et des rédacteurs
 Ce problème modélise bien les accès d'un processus à un objet (base
de données, fichier ou enregistrement);

UAMB)
 On distingue les processus en deux types: Lecteurs et rédacteurs;
 On accepte que plusieurs processus lisent l’objet en même temps;
 Les rédacteurs sont exclusifs entre eux (Un rédacteur à la fois);
 Un rédacteur est exclusif avec les lecteurs.
16

Ils existe plusieurs versions classiques du problème:
A. priorité aux lecteurs : s’il existe des lecteurs sur le fichier, toute
UAMB)
nouvelle demande de lecture est acceptée.
Problème: risque de famine: le rédacteur peut ne jamais accéder
au fichier.
BDD
File_Att
Pr_Lec_01 Pr_Lec_03 … Pr_Lec_k

Pr_Red
Pr_Lec_02
17

B. priorité aux lecteurs, sans famine des rédacteurs : s’il existe

UAMB)
des lecteurs sur le fichier, toute nouvelle demande de lecture est
acceptée, sauf s’il y ‘a un rédacteur en attente
BDD
File_Att File_Att
Pr_Lec_01 Pr_Lec_03 …
Pr_Red Pr_Lec_k
Pr_Lec_02
18

C. priorité aux rédacteurs : un lecteur ne peut lire que si aucun

UAMB)
rédacteur n’est présent.
Problème: risque de famine des lecteurs.
BDD
File_Att File_Att
Pr_Red_01 Pr_Lec_03 … Pr_Lec_k
Pr_Red_02 Pr_lec_01
19

D. FIFO : demandes d’accès à l’objet sont servies dans l’ordre

UAMB)
d’arrivée.
Problème: regroupement des lecteurs est inefficace, si l’ordre
d’arrivée est: Lecteur/rédacteur/lecteur/rédacteur, etc.
BDD
File_Att File_Att
Pr_Red_01 Pr_Lec_03 … Pr_Lec_k
Pr_Red_01
Pr_lec_02
Pr_Red_02
20

2.1.2.1) Solution du problème de Lecteur/Rédacteur avec sémaphores

UAMB)
Initialisation:
int nbLect = 0; /* compte nombre de processus lecteurs qui veulent lire */
Semaphore:
lecture = 1, /* utilisé pour contrôler l'accès à la variable nblLect */
bd = 1, /*utilisé par le 1ier lecteur ou le rédacteur qui accède à la SC*/
Ecriture = 1 /* utilisé pour garantir qu’il n’y aura qu’un rédacteur dans la SC*/
21


2.1.2.1) Solution du problème de Lecteur/Rédacteur avec sémaphores
void lecteur ()
{ while (TRUE) void Rédacteur()
{ P (lecture);
UAMB)
{ while (TRUE)
nbLect ++; {
if (nbLect = = 1) P (bd); P (Ecriture);
V (lecture); P (bd);
<lire_donnees ()>; <Ecrire_donnees ();>
P (lecture); V (bd);
nblect--; V (Ecriture) ;
if (nbLect = = 0) V (bd); }
V (lecture); }
}
} 22


2.1.2.2) Solution du problème de Lecteur/Rédacteur avec Moniteurs
Soit LecRed un moniteur chargé d’assurer le respect des contraintes de

priorité aux lecteurs.
UAMB)
Processus_lecteur() Processus_redacteur()
{ {
LecRed.debut_lire ; LecRed.debut_ecrire ;
<Accès en lecture> <Accès en écriture>
LecRed.fin_lire ; LecRed.fin_ecrire ;
} }
On définit les variables suivantes :
ecr = une écriture est en cours (booléen)

nl = nombre de lecteurs en attente ou en cours de lecture.
23

2.1.2.2) Solution du problème de Lecteur/Rédacteur avec Moniteurs

Moniteur LecRed procedure debut_ecrire
debut
Debut Var ecr: booleen;
Si ecr ou nl >0 alors
nl : entier; c_ecr.wait ;
c_ecr, c_lect: condition; Finsi
Procedure debut_lire
UAMB)
ecr := vrai ;
debut fin
nl :=nl+1 ; procedure fin_ecrire
Si ecr alors Debut
debut ecr :=faux ;
c_lect.wait ; Si nl >0 alors
c_lect.signal; //réveil des c_lect.signal ;
lecteurs Sinon c_ecr.signal ;
FinSi Fin Si
fin fin
Procedure fin_lire ; debut // initialisation
debut ecr := faux ; nl := 0 ;
nl=nl-1 ; Fin
Si nl= 0 alors c_ecr.signal ; Fin LecRed //findu moniteur. 24
2.2. Communication interprocessus par échange de messages
2.2.1. Pourquoi l’échange de message
L’utilisation des messages permet aux processus de communiquer

entre eux sans avoir recours à des variables partagées. On évite ainsi
le problème de la section critique.
Ainsi, si deux processus A et B désirent communiquer, illes doivent

s’échanger des messages. Pour cela, on aura besoin de liens de
communications. Cette liaison peut être directe, indirecte,
unidirectionnelle ou bidirectionnelle.
A … … B
25
2.2.2 Communication directe
 communications directes doivent identifier le processus, par un n°

et une machine;
 On aura alors : envoie (P, Message1) et reçois (Q, Message2). On

UAMB)
les appelle aussi SEND (P, message) et RECEIVE (Q, message);
 SEND (P, message) : envoyer le « message » au processus P. Le

message est copie dans la “file de message“ du récepteur
 RECEIVE (Q, message) : recevoir le prochain « message » du

processus Q. Les messages sont reçus dans l’ordre où ils sont
envoyés. S’il n’y a aucun message dans la file, le système reste
bloqué jusqu’à ce qu’un message soit envoyé.
26

2.2.2. Communication directe
Dans ce schéma, la communication directe a les propriétés suivantes :
 Un lien est établi automatiquement entre deux processus qui désirent

UAMB)
communiquer.
 Les processus ont besoin de connaitre leur identité respective.
 Le lien est établi exactement entre deux processus (connexion).
 La liaison est en général bidirectionnelle.
 Utilisé beaucoup plus dans les communications téléphoniques
27

2.2.3. Communication indirecte
 Les messages sont envoyés et reçus à travers des “boites aux

lettres“ ou “ports dans la terminologie des réseaux“;
UAMB)
 Chaque boite aux lettres (port) dispose d’un identificateur unique;
 Un processus peut communiquer avec d’autres à travers plusieurs

ports différents;
 Deux processus ne peuvent communiquer que s’ils partagent une

boite (port) aux lettres.
28

Les primitives de communication sont définies comme suit :

Envoyer (A, message): Envoie un message dans la boite-aux-
lettres ou le port A.
 Recevoir (A, message): Retire un message de la boite-aux-
UAMB)
lettres ou le port A.
Remarque : (processus terminé et message)
Si un processus receveur P attend un message d’un processus Q qui

a terminé son exécution (cas d’erreur par exemple), alors il restera
bloqué indéfiniment.
29

Dans ce schéma la communication a les propriétés suivantes :
 Une liaison n’est établie entre deux processus que s’ils partagent
UAMB)
une boite-aux-lettres;
 Il peut exister plusieurs liaisons (boites-aux-lettres) entre deux

processus;
 Une liaison (boite aux lettres) peut être partagée par plus de deux
processus;
 La liaison peut-être soit unidirectionnelle, soit bidirectionnelle.
30

2.2.4. Capacité des liaisons
La liaison dispose d’une capacité en nombre de messages:

A. Capacité nulle : La liaison ne peut pas garder de message en attente.
Dans ce cas, l’expéditeur doit attendre jusqu’à ce que le destinataire
puisse recevoir le message.
UAMB)
B. Capacité limitée : La file dispose d’une longueur finie, au plus N

messages peuvent être en attente dans cette file. Si la file est
pleine, l’expéditeur est mis en attente jusqu’à la libération de place
dans cette file.
C. Capacité illimitée : La file possède une longueur potentiellement

infinie. Donc, l’expéditeur n’est jamais mis en attente lorsqu’il essaie
d’envoyer un message.
31

SUPPORT DE COURS SE2 (CHAPITRE3 COMMUNICATION INTERPROCESSUS) - 2023-2024 - VF - Aff

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

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 :

Formats disponibles

SUPPORT DE COURS SE2 (CHAPITRE3 COMMUNICATION INTERPROCESSUS) - 2023-2024 - VF - Aff

Transféré par

Droits d'auteur :

Formats disponibles

Université de Bejaia

Faculté des sciences exactes

Les processus ne sont pas des entités indépendantes. Ils

coopèrent souvent pour traiter un même problème ou se mettent en

compétition pour utiliser une ressource partagée. Ces processus

peuvent s’exécuter en parallèle sur un même ordinateur

(monoprocesseur ou multiprocesseurs) ou bien sur des ordinateurs

différents. Ils doivent alors s’échanger des informations

La communication interprocessus peut se faire de différentes

l’implémentation de la communication est réalisée comme suit:

A. Tubes Anonyme (ou ordinaire) / nommé (ou FIFO)

2.1. Communication interprocessus par variable partagée

Un modèle de communication entre processus par variable

synchroniser l’accès à cette mémoire partagée.

2.1.1. Problème du Producteur / Consommateur

2.1.1. Problème du Producteur / Consommateur

• les données (messages) sont de taille constante.

 Spécifications des communications

2.1.1. Problème du Producteur / Consommateur

• Les messages ne doivent pas être perdus ; si le tampon contient N

• Un moyen d’assurer la synchronisation consiste à faire attendre ou à

bloquer un processus qui tente d’exécuter une opération « impossible »

• Les conditions de synchronisation peuvent donc s’exprimer ainsi, en

2.1.1. Problème du Producteur / Consommateur

nb > 0 (i.e., tampon non

2.1.1. Problème du Producteur / Consommateur

2.1.1. Problème du Producteur / Consommateur

finsi // fin de bloc ininterruptible

2.1.2. Problème du Producteur / Consommateur

2.1.2.1) Solution avec des Sémaphores

On peut considérer NVIDE (resp. NPLEIN) comme un sémaphore pour

2.1.2. Problème du Producteur / Consommateur

2.1.1.1) Solution avec des Sémaphores

Faire toujours Faire toujours

2.1.1.2) Solution avec les moniteurs

Moniteur ProdCons (* moniteur, condition : types prédéfinis*)

si nb = N alors plein,wait; /* on met le processus producteur en attente dans la file

2.1.1.2) Solution avec les moniteurs

Procedure retirer (var e: element)

// seul un vide.signal réveillera le processus.

nb nb - 1; // décrémenter le nombre d’éléments dans le tampon

si nb = N-1 alors plein.signal ; /*réveille du processus (producteur) endormi,

Remarque : Dans cette solution, le code de la SC est à l’intérieur du moniteur. 14

2.1.1.2) Solution avec les moniteurs

Codes des processus producteur/consommateur

Processus Producteur Processus Consommateur

ProdCons.deposer (element) < Consommer l’élément>

 Exécution des deux processus producteur et consommateur en parallèle,

ParBegin producteur; Consommateur ParEnd.

2.1. Communication interprocessus par variable partagée

2.1.2. Problème des lecteurs et des rédacteurs

 Ce problème modélise bien les accès d'un processus à un objet (base

de données, fichier ou enregistrement);

 On distingue les processus en deux types: Lecteurs et rédacteurs;

 On accepte que plusieurs processus lisent l’objet en même temps;

 Les rédacteurs sont exclusifs entre eux (Un rédacteur à la fois);

 Un rédacteur est exclusif avec les lecteurs.

2.1. Communication interprocessus par variable partagée

2.1.2. Problème des lecteurs et des rédacteurs

Ils existe plusieurs versions classiques du problème:

nouvelle demande de lecture est acceptée.

Problème: risque de famine: le rédacteur peut ne jamais accéder

Pr_Lec_01 Pr_Lec_03 … Pr_Lec_k