Main 5

Synchronisation des processus
Communication interprocessus
Système d’exploitation
Module: M18 - IRISI S3
Pr. Abdessamad EL BOUSHAKI

abdessamad.elboushaki@gmail.com
FST Marrakech
Université Cadi Ayyad
Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 1/72

Synchronisation des
processus

Introduction : ressources d’un processus
Un processus a besoin de ressources pour s’exécuter: procédures et données,

mémoires, processeur (UC et d’autres), périphériques, fichiers, ....
On peut classifier les ressources en plusieurs types possibles selon diverses
caractéristiques:
I Physiques vs logiques
I Locales vs communes
I Mono-accès vs multi-accès
I Banalisées vs non banalisées
I Préemptibles vs non préemptibles

Ressources physiques vs logiques

Une ressource physique désigne une entité concrète représentée par un
organe physique capable de fournir un service indispensable à l‘exécution
d’un processus.
I Ex : processeurs, mémoire, canaux, périphériques.
Une ressource logique désigne une entité abstraite représentée par un
ensemble d’informations ou d’actions à exécuter indispensable à l‘exécution
d’un processus
I Ex : procédure désignée par son nom et ses paramètres, fichier, table,
primitives et outils de synchronisation,...

Ressources locales vs communes

Une ressource locale est utilisée uniquement au niveau du processus.
I Ex : fichier temporaire, variables locales du programme,...
Une ressource commune (ou partageable) peut être utilisée par plusieurs
processus.
I Ex : disque, imprimante, fichier en lecture, ....
I Le degré de partageabilité d’une ressource est définie comme étant le nombre
maximum de processus pouvant accéder simultanément à une ressource.

Ressources mono-accès vs multi-accès

Une ressource mono-accès (ou critique) est une ressource de degré de
partageabilité 1, c.-à-d. qu’un seul processus au plus peut y accéder à un
instant donné.
I Ex : imprimante, fichier accédé en écriture, ....
Une ressource multi-accès (ou N-partageable) est une ressource de degré
de partageabilité N > 1, c.-à-d. que N processus au plus peuvent y accéder
simultanément.
I Ex : fichier accédé en lecture « N théoriquement infini »

Ressources banalisées vs non banalisées

Une ressource banalisée existe en plusieurs exemplaires identiques où le
choix de l’unité à allouer est sans importance pour le demandeur.
I Ex : processeur parmi plusieurs processeurs identiques, pages mémoire,
secteurs de disque.....
Une ressource non banalisée n’existe pas en plusieurs exemplaires
identiques, ainsi, sa désignation devra être explicite.
I Ex : terminal graphique ou spécifique, processeur particulier, fichier nommé...

Ressources préemptibles vs non préemptibles

Une ressource préemptible désigne toute ressource qu’on peut retirer à un
processus alors qu’il n’a pas fini de l’utiliser. Cette qualité ne peut être
obtenue que si l’état de la ressource peut être sauvegardé et restauré.
I Ex : Processeur, Mémoire vive, ...
Une ressource non préemptible désigne toute ressource qu’on ne peut
retirer à un processus tant qu’il ne l’ a pas libérée.
I Ex : Imprimante, fichier accédé en écriture, ....


De même qu’un processus, une ressource est repérée par un descripteur
(contenant un ensemble d’informations qui décrivent l’état et l’utilisation
de la ressource) et passe par une série d’états:
I Libre : la ressource est disponible

I Demandée : présence d’une demande
I Attendue : présence d’une file d’attente de processus demandeurs
I Allouée : ressource attribuée à un processus
I Libérée : ressource récupérée après utilisation (soit après requête de
libération, soit récupéré par le système en cas de fin anormale)
I Requise : si la ressource est préemptible elle sera récupérée avant fin
d’utilisation pour être réattribuée à un autre processus.
Au niveau du processus demandeur, on ne voit que deux états: ressource
Libre et ressource occupée
Le système d’exploitation garde la liste des descripteurs des ressources dans

une table, appelée table des ressources.
Cette table indique si la ressource est disponible ou non, et, à quel processus
elle est allouée (cas non disponible).
A chaque ressource est associée une file d’attente, pointée par la table des
ressources, contenant les blocs de contrôle des processus/threads
(PCB/TCP) qui l’attendent.
Chaque fois qu’un nouveau processus fait une demande de la ressource et
que cette dernière n’est pas disponible, son PCB/TCB est ajouté à la file
d’attente.
I selon une politique d’ordonnancement: FIFO, SJF, priorité ou autre

Processus parallèles
Dans un environnement multitâches, plusieurs processus peuvent se

dérouler simultanément.
On parle des processus parallèles dont leurs exécutions se chevauchent dans
le temps.
I Exécution séquentielle stricte des deux processus.
I Exécution séquentielle sur un seul processeur ⇒ pseudo-parallélisme
I Exécution en parallèle sur deux processeurs distincts ⇒ parallélisme réel

Selon la nature des relations existantes entre les processus parallèles, on peut
distinguer deux types :
Processus disjoints (Indépendants) qui n’ont aucune relation commune.
Leurs exécutions respectives sont indépendantes et leurs contextes respectifs
sont disjoints.
I Deux processus P1 et P2 sont disjoints si les exécutions suivantes sont
équivalentes (donnent les mêmes résultats ): (P1 ||P2 ), (P1 ;P2 ), (P2 ;P1 ) .
I Dans ce cas, P1 et P2 n’ont aucune interaction (sauf le processeur en cas de
monoprocesseur) ; De plus, l’exécution parallèle de P1 et P2 permettra
d’optimiser le temps total d’exécution.
Processus concurrents qui interagissent les uns avec les autres durant leur
évolution.
I On dira que P1 et P2 sont concurrents si les exécutions suivantes ne sont pas
équivalentes : (P1 ||P2 ), (P1 ;P2 ), (P2 ;P1 )
I De plus (P1 ||P2 ) peut donner des résultats aléatoires si certaines précautions
ne sont pas prises. Les dangers d’une telle exécution sont dus au fait que P1
et P2 utilisent des ressources communes.

Selon que les processus concurrents se connaissent mutuellement ou pas, on

distingue deux formes d’interactions :
Compétition : Les processus ne se connaissent pas (i.e. ils ignorent leur
existence mutuelle) mais ils rentrent en conflits pour l’utilisation des
ressources communes/partagées (Ex. fichier).
I Pour résoudre les conflits entre les processus, on utilise des règles d’utilisation
de ressources.
I Ces règles visent à sérialiser dans le temps les utilisations d’une ressource
donnée par les processus.
Coopération : Les processus se connaissent mutuellement et échangent des
informations (communiquent) pour traiter un même problème. Ils peuvent
aussi rentrer en compétition pour des ressources partagées.
I Un processus est dit coopératif s’il peut affecter les autres processus en cours
d’exécution dans le système ou être affecté par eux.

Synchronisation
Le rôle et mécanismes de la synchronisation

Résoudre une compétition consiste à définir les règles d’accès simultanés
aux ressources partagées considérées comme objets de compétition et établir
des mécanismes de contrôle permettant d’imposer ces règles aux processus.
La synchronisation des processus permet de définir et de réaliser ces
mécanismes en assurant le respect des contraintes liées à la progression des
processus.
I c.-à.-d, capables de faire attendre un processus qui tenterait des actions ne
respectant pas ces contraintes.
La synchronisation se fait par les mécanismes suivants :
I Exclusion Mutuelle (mutex)
I Sémaphores
I Régions Critiques
I Moniteurs

Synchronisation
Tout comme les processus, les threads POSIX fonctionnent de manière

asynchrone et peuvent donc partager entre eux les variables globales et les
descripteurs de fichiers de processus.
Une gestion de l’accès concurrentiel doit donc être introduite.
La norme POSIX offre de nombreux mécanismes de synchronisation:
I Les verrous (ou mutex)
I Les sémaphores
I Les moniteurs

Exclusion mutuelle
Position du problème
Lorsque plusieurs processus s’exécutent sur un ordinateur, monoprocesseur

ou multiprocesseur, ils sont amenés à partager des ressources communes :
I soit volontairement s’ils coopèrent pour traiter un même problème
I soit involontairement parce qu’ils sont obligés de se partager les ressources de
l’ordinateur.
Malheureusement, le partage des variables sans précaution particulière peut
conduire à des résultats imprévisibles.

Exclusion mutuelle
Position du problème : exemple du compte bancaire
Soient deux transactions (processus) P1 et P2 lancées en parallèle de deux

terminaux différents et pouvant consulter et modifier simultanément un
même compte CCP de valeur initiale C0 centralisé dans un fichier commun F.
P1 effectue un dépôt (crédit) et P2 effectue un retrait (débit).
Transaction 1 (P1 ) Transaction 2 (P2 )

Cpt : variable locale Cpt : variable locale
A1 : Lecture du compte A2 : Lecture du compte
Lire Cpt; Lire Cpt;
B1 : Modification du compte B2 : Modification du compte
Cpt = Cpt+SV ; Cpt = Cpt-SR ;
C1 : Réécriture du compte C2 : Réécriture du compte
Ecrire Cpt ; Ecrire Cpt ;

Exclusion mutuelle
Deux cas possible pour l’exécution de P1 et P2 :

1er cas : Si l’exécution de P1 et P2 est purement séquentielle, (P1 ; P2 ou
P2 ; P1 ) il n’y a aucun problème car il n’y a pas d’accès simultané au même
compte.
I Le résultat final du compte est C0+SV-SR (résultat correct).
eme
2 cas : Si l’exécution de P1 et P2 est parallèle ( P1 ||P2 ), il y a un risque
car il y a accès simultané au même compte.
I Exemple :
Ordre d’exécution P1 P2
1 A1: Lire Cpt ;
2 A2: Lire Cpt ;
3 B1: Cpt = Cpt+SV
4 B2: Cpt = Cpt-SR
5 C1: Ecrire Cpt ;
6 C2: Ecrire Cpt ;
Valeur finale du Compte Cpt-SR
Exclusion mutuelle
Normalement le résultat final correct devrait être C0+SV-SR : l’exécution parallèle

de P1 et P2 prise sans précautions entraine une incohérence dans le résultat final.
Pour éviter cette incohérence, il faut empêcher l’exécution parallèle de P1 et

P2 .
Les séquences de P1 et P2 doivent être exécutées en Exclusion Mutuelle.
Les ressources logicielles ou matérielles qui posent ce type de problèmes sont
dites ressource critiques.
C’est le compte CCP commun (initialement égal à C0) qui constitue la
ressource critique.
Les séquences de lecture, modification et d’écriture du compte s’appellent
sections critiques de P1 et P2 respectivement.

Exclusion mutuelle
Notion de section critique
Une section critique (SC) est un ensemble d’instruction d’un programme

qui peuvent engendrer des résultats imprévisibles lorsqu’elles sont exécutées
simultanément par des processus différents.
D’une manière générale, on peut dire qu’un ensemble d’instructions peut
constituer une SC s’il y a des ressources partagées, mais l’inverse n’est pas
vrai.
Pratiquement, les SC
doivent être détectées par
les concepteurs de
programmes
Exemple du compte
bancaire :

Exclusion mutuelle
Définition
Pour éviter toute utilisation incorrecte d’une ressource critique, les Sections
Critiques (SC) qui la manipulent dans les différents processus ne doivent
jamais s’exécuter simultanément.
Autrement dit, ces SC doivent s’exécuter en Exclusion Mutuelle (EM ou
mutex).
I c-à-d une SC ne peut être entamée que si aucune autre SC du même
ensemble n’est en exécution.
L’exclusion mutuelle est une méthode qui permet de s’assurer que si un
processus utilise une variable ou une ressource partagée, les autres processus
seront exclus de la même activité.
Pour assurer l’exécution des SC des processus en EM il est nécessaire de
trouver une solution qui permet d’éviter les conditions de concurrence.

Exclusion mutuelle
Principe
Le principe général d’une solution garantissant l’EM:

Avant d’exécuter une SC, un processus doit s’assurer qu’aucun autre
processus n’est en train d’exécuter une SC du même ensemble. Dans le cas
contraire, il ne devra pas progresser tant que l’autre processus n’aura pas
terminé sa SC.
Avant d’entrer en SC, le processus doit exécuter un protocole d’entrée. Le
but de ce protocole est de vérifier justement si la SC n’est occupée par aucun
autre processus.
A la sortie de la SC, le processus doit exécuter un protocole de sortie de la
SC. Le but de ce protocole est d’avertir les autres processus en attente que la
SC est devenue libre.

Exclusion mutuelle
Principe
Le principe général d’une solution garantissant l’EM:

Processus Pi
D é but
...
< Instructions hors de la SC >
...
Protocole d entr é e en SC
SC
Protocole de sortie de SC
...
< Instructions hors de la SC >
...
Fin

Exclusion mutuelle
Principe
L’EM des processus dans leurs SC n’est garantie que si les protocoles
d’entrée et de sortie sont correctement utilisés.
En effet, en cas où ces protocoles sont mal construits, les problèmes suivants
peuvent se produire:
I L’interblocage qui caractérise une situation où les processus ne peuvent plus
progresser par manque de ressources. Chaque processus détient des ressources
dont l’autre a besoin.
I La famine qui est une situation où certains processus n’accèdent jamais à
leurs sections critiques et sont ainsi mis en attente indéfiniment alors que
d’autre accèdent à leurs sections critiques selon leurs besoins.

Exclusion mutuelle
Hypothèses
Pour étudier et comparer les solutions au problème de l’EM, on se donne un

ensemble d’hypothèses de travail (énoncées par DIJKSTRA) :
1 Les vitesses relatives des processus en compétition sont quelconques et
inconnues.
2 On suppose que tout processus qui entre en section critique en sort au bout
d’un temps fini.
3 L’ordre d’accès à la ressource critique est quelconque.

Exclusion mutuelle
Propriétés
La solution au problème de l’EM doit avoir les propriétés suivantes (propriétés de

DIJKSTRA) :
1 A tout instant, un processus au plus peut se trouver en section critique.
2 Si aucun processus n’est en SC et que plusieurs processus sont en attente de
la ressource critique, alors l’un d’eux doit pouvoir y entrer au bout d’un
temps fini.
I La solution doit éviter qu’un blocage mutuel des processus en attente de la
ressource critique dure indéfiniment alors que celle-ci est libre.
3 Si un processus est bloqué hors de sa SC, ce blocage ne doit pas empêcher
l’entrée d’un autre processus en SC.
4 La solution doit être la même pour tous les processus ; aucun processus ne
doit jouer un rôle privilégié.

Réalisation de l’exclusion mutuelle
Contrôler la compétition entre processus, revient à trouver une solution au

problème de l’EM. Différentes approches existent:

Solutions matérielles
Matériellement, une EM peut être réalisée en :

Interdisant (masquant) les interruptions pendant qu’une variable
partagée est modifiée. De cette façon, on pourra être sûr que la séquence
courante d’instructions s’exécute en ordre sans aucune réquisition.
Utilisant des instructions matérielles spéciales qui permettent soit de
tester et modifier le contenu d’un mot-mémoire (Ex: instruction TAS), soit
d’échanger le contenu de deux mots (Ex: instruction SWAP) d’une manière
atomique (indivisible).

Masquage des Interruptions: L’idée principale de cette solution est le
masquage d’interruptions les commutations de processus qui pourraient
violer l’exclusion Mutuelle des SC.
chaque processus entrant dans la section critique désactive toutes les
interruptions et les réactive à sa sortie de la section critique.
Entrée en SC : Masquage des Interruptions;

Accès à la ressource : <SC>
Sortie de la SC : Démasquage des Interruptions;
Inconvénients
Les interruptions restent masquées pendant toute la SC, d’où risque de perte
d’interruptions ou de retard de traitement.
Une SC avec while(1) bloque tout le système
Fonctionnel que sur des machines monoprocesseurs.
N’est accessible qu’aux programmeurs privilégies (super utilisateurs) pour des
raisons de fiabilité.
Instructions Spéciales : permettent de lire et de modifier une ou plusieurs

variables communes d’une manière indivisible (instructions atomiques).
Par conséquent, si deux processus exécutent simultanément ces instructions,
l’un d’eux sera mis en attente.
Fonctionnelle sur des machines multiprocesseurs.
Deux instructions spéciales sont considérées :
I Instruction TAS (Test And Set)
I Instruction SWAP (Compare and Swap)

Instruction TAS (Test And Set) consiste à déclarer une variable « verrou
» donnant l’état de la ressource critique (vrai ou 1 ressource occupée ; faux
ou 0 ressource libre).
L’instruction TAS garantit une EM au niveau machine entre les processus
désirant tester et modifier la variable d’état « verrou ».
int TAS ( int * verrou )

{
Le code source de cette fonction int old ;
peut être assimilée comme suit: old = * verrou ;
* verrou = 1;
return old ;
}
Soit verrou une variable commune aux processus, concernée par la SC. Elle
doit être initialisée à faux (ressource libre).
Initialisation : int verrou = 0;

Demande d’entrée en SC : while (TAS(& verrou));
Fin et Sortie de la SC : verrou = 0 ;
Instruction SWAP : permet d’échanger le contenu de deux mots de manière
atomique.
void SWAP ( int * x , int * y )
{
int z ;
Sa forme générale est la suivante : z = *x;
*x= *y;
*y = z;
}
L’instruction SWAP permet de réaliser EM en utilisant deux variables:

I «verrou» une variable commune aux processus concernée par la SC. Elle doit
être initialisée à faux.
I «cle» une variable locale au processus, initialisée à vrai.
Initialisation globale : int verrou = 0;

Déclaration locale: int cle;
Demande d’entrée en SC : cle = 1;
do SWAP (&verrou, &cle); while (cle == 1);
Fin et Sortie de la SC : verrou = 0;
Solutions logicielles
Quoiqu’il existe des solutions matérielles au problème de l’EM, l’étude de

solutions logicielles permet d’élucider les notions d’exécution atomique et
d’attente illimitée.
Il existe deux familles d’algorithmes :
I L’attente active : un processus boucle sur une condition et l’évaluer de
manière répétitive jusqu’à ce qu’elle change d’état. Les premiers algorithmes
(Dekker, Peterson, Boulanger,...) sont basés sur ce principe.
I L’attente passive : demande une intervention de la part du système (qui doit
par conséquent fournir les appels au noyau nécessaire), et évite une surcharge
inutile du processeur. Les mécanismes (verrous, sémaphores, et moniteurs)
font partie ce principe.

L’attente active
Solution 1
consiste à laisser les deux processus partager une variable entière commune
« tour », initialisée à 0 (ou 1).
Si la valeur de tour=i, alors on permet au processus Pi d’exécuter sa SC.
Initialisation globale: int tour = i; //0 ou 1

Demande d’entrée en SC : while (tour != i);
Fin et Sortie de la SC : tour = 1-i; // permet à l’autre
processus d’entrer en SC
La solution garantit qu’un seul processus à la fois peut se trouver dans sa SC.
Cependant:
I l’hypothèse 3 de Dijkstra n’est pas respectée, car cette solution exige une
alternance stricte ; les processus entrent en SC à tour de rôle dans un ordre
forcé. ⇒ Par exemple, si tour=0 et P1 est prêt à entrer dans sa SC, cela ne
lui est pas possible même si P0 peut se trouver dans sa section restante.
I les propriétés b et c de Dijkstra ne sont pas vérifiées.
L’attente active
Solution 2
Le problème de la solution 1 est qu’elle ne garde pas suffisamment

d’informations sur l’état de chaque processus.
elle se rappelle seulement quel processus est autorisé à entrer en SC.
Pour remédier à ce problème, nous pouvons remplacer la variable « tour »
par un tableau booléen « Etat » à deux éléments qui va sauvegarder l’état
des deux processus.
Solution 2 : consiste à laisser les deux processus partager un tableau «
Etat » initialisé à Faux. Si Etat[i] est Vrai alors le processus Pi est prêt
pour entrer en SC.
Initialisation globale: int etat [2] = {0, 0}
Demande d’entrée en SC : etat [i] = 1;// Pi est prêt pour entrer
en SC
while (etat[1 – i]);
Fin et Sortie de la SC : etat[i] = 0; // permet à Pj d’entrer
en SC
L’attente active
Solution 2
Le problème de la solution 1 est qu’elle ne garde pas suffisamment

d’informations sur l’état de chaque processus.
Dans cette solution, les hypothèses de Dijkstra sont respectées.
Toutefois, un problème se pose si les deux processus mettent leur état à Vrai,
puis vont, chacun, itérer sur la vérification de l’état de l’autre processus.
On assiste ainsi à une boucle sans fin pour les deux processus (aucun des
deux processus ne peut entrer dans sa SC).
La propriété b de Dijkstra n’est donc pas vérifiée.

L’attente active
Solution 3 : Algorithme de Dekker
L’algorithme de Dekker combine les idées des solutions 1 et 2 précédentes.

Les processus partagent deux variables :
I « tour »: une variable entière initialisée à 0 (ou 1). Si la valeur de tour =
i, alors on permet au processus i d’exécuter sa SC.
I « Etat » un tableau de booléen (Tableau[0..1] de Booléen), initialisé à faux
qui indique que le processus i est prêt pour entrer en SC si Etat[i] est vrai.
La solution pour deux Processus Pi et Pj (j = 1˘i et i = 0 ou 1) est le
suivant:
Initialisation globale: int tour = i; //0 ou 1
int etat [2] = {0, 0}
Demande d’entrée en SC : etat [i] = 1;// Pi est prêt pour entrer
en SC
j = 1 – i;
tour = j; // permet à Pj d’entrer en SC
while (etat[j] && tour == j);
Fin et Sortie de la SC : etat[i] = 0;
L’attente active
Solution 3 : Algorithme de Dekker
Pour entrer dans la SC, le processus Pi met son état Etat[i] à Vrai et
permet à l’autre processus d’entrer en SC en mettant la variable tour à j.
Si les deux processus tentent d’entrer en même temps en SC, tour sera fixé
à i et à j presque au même moment.
Evidemment, une seule des ces affectations se produira, l’autre sera perdue
(la seconde affectation écrasera la première valeur).
La valeur de tour décidera quel processus entrera dans sa SC.
Cet algorithme vérifie toutes les hypothèses et les propriétés de
Dijkstra.

L’attente active
Solution 4 : Algorithme de Boulanger
L’algorithme de Dekker précédent apporte une solution au problème de la SC

pour deux processus seulement.
L’algorithme de Boulanger est une généralisation du précédent.
Cet algorithme s’inspire d’une technique d’ordonnancement utilisée dans les
anciennes boulangeries et magasins:
I En entrant dans la boulangerie, chaque client reçoit un numéro. Le client
suivant à servir est celui qui aura le plus petit numéro.
I Si deux clients reçoivent le même numéro alors le client à servir est celui qui
sera le premier dans l’ordre alphabétique.
Soient N processus P0 , P1 , ..., Pn−1 . Ces processus partagent deux tableaux:
I « Num » un tableau d’entier, initialisé à zéro, où Num [i] contient le numéro
attribué au processus i. Si Num [i] 6= 0 cela veut dire que le processus i
demande d’entrer à sa section critique,
I « DNum » un tableau de booléen (Tableau[0..1] de Booléen), initialisé à faux
qui indique que le processus i est entrain de demander un numéro pour entrer
en SC si DNum [i] est vrai.

L’attente active
Solution 4 : Algorithme de Boulanger
Initialisation globale: for (i=0 ; i<n ; i++) {

Num [i] = 0; DNum[i] = 0; }
Demande d’entrée en SC : DNum[i]= 1; //demande un numéro
Num [i]= max(Num, n) + 1;
DNum[i]=0;
*Pi doit vérifier qu’il possède le plus petit numéro parmi les n processus*
for (j=0 ; j<n ; j++) {
while (DNum[j]==1);
while ((Num[j]!=0) && ((Num[j]<Num[i]) ||
((Num[j]==Num[i]) && (j<i))));
}
Fin et Sortie de la SC : Num[i] = 0;
I La fonction max retourne le numéro le plus grand.
I (Num[j]<Num[i]) permet de servir le processus qui a le plus petit numéro.
I ((Num[j]==Num[i]) && (j<i)) permet de servir le processus qui est le premier dans
l’ordre alphabétique si les deux processus reçoivent le même numéro.
L’attente active
Inconvénients:
En considérant l’attente active, tout processus désirant entrer en SC est
susceptible de consommer du temps (éventuellement tout son quantum de
temps, voire même plusieurs) en bouclant inutilement.
I Un processus souhaitant entrer en SC vérifie s’il en a le droit sinon il entre en
boucle d’attende de l’autorisation de l’entrée en SC.
Cette attente équivaut à une forme d’autoconsommation du système. Le
temps d’allocation de la ressource principale, c.à.d., du processeur est
fâcheusement gaspillé.
Une solution à ce problème consiste à mettre provisoirement le processus ne

pouvant entrer en SC dans état d’attente passive.

L’attente passive
L’attente passive consiste à bloquer le processus ne pouvant entrer en SC

et à attribuer pendant ce temps de blocage, la ressource processeur à un
autre processus susceptible de faire avancer ou progresser.
Autrement dit, en le bloquant, le processus ne peut tenter d’accéder à la
ressource processeur tant que la SC reste inaccessible.
Naturellement, cela implique que lors d’une mise en attente passive, le
contexte d’exécution du processus mis en attente soit sauvegardé pour être
ensuite restauré lors de son réveil.
L’attente passive est réalisée à l’aide des structures de données suivantes:
I Files d’attentes pour insérer les processus bloqués (PCB/TCB)
I Signaux pour réveiller les processus bloqués
Plusieurs mécanismes peuvent réaliser l’EM par attente passive, tels que :
I Les verrous,
I Les sémaphores,
I Les moniteurs

L’attente passive
Les verrous
Un verrou est une structure à deux champs :
typedef struct {
bool etat = 0;
CB * file ;
} verrou ;
I etat : une variable booléenne, ou état du verrou qui représente à un moment

donné l’état de la ressource critique (0: libre ou disponible, 1: occupée ou non
disponible).
I file : file d’attente des processus ou threads contenant les blocs de contrôle
Pour manipuler un verrou, deux opérations atomiques sont définies :
Verrouiller(v) et Déverrouiller(v).
Ce sont les deux seules opérations (mis à part la création et sa destruction)
qui peuvent manipuler le verrou.

L’attente passive
Les verrous
Opération Verrouiller(v): équivalente à l’exécution atomique de séquence

d’instructions suivante:
void Verrouiller ( verrou v )

{
if ( v . etat ==0)
v = 1;
else
suspendre et ajouter le processus appelant dans la file associ é e à v
}
Si l’état du verrou v est à faux et qu’un processus appelle Verrouille(v),

alors l’état du verrou est positionné à vrai.
Si un second processus appelle Verrouille(v), alors il passe à l’état bloqué
et joint la file d’attente associée à v.

L’attente passive
Les verrous
Opération Deverrouiller(v): équivalente à l’exécution atomique de

séquence d’instructions suivante:
void Deverrouiller ( verrou v )

{
if ( la file associ é e à v est non vide )
d é bloquer un processus en attente dans la file
else
v . etat = 0;
}
S’il y a un processus en attente sur le verrou v, alors ce processus est

réactivé en le retirant de file d’attente associée à v pour joindre la file des
processus prêts.
S’il n’y a pas de processus en attente pour obtenir le verrou v, le verrou v est
libéré en positionnant son état à faux (état initial).

L’attente passive
Les verrous
Comme son nom le sous-entend, un verrou permet de résoudre le problème

de l’EM à n processus de manière simple.
Initialisation globale: verrou v.etat= 0;

Demande d’entrée en SC : verrouiller (v)
Fin et Sortie de la SC : deverouiller(v)
Il suffit de verrouiller un verrou v avant d’entrer en SC, bloquant ainsi les

autres processus qui accèdent à leur SC protégée par le même verrou v.
La sortie d’une SC se fait en déverrouillant v, ce qui libère le verrou ou
réveille un processus bloqué pour l’accès à sa SC.

L’attente passive
Les sémaphores
Les sémaphores, inventés Dijkstra en 1965, permettent l’utilisation de m

ressources identiques par n processus.
Ce sont un outil de synchronisation pouvant jouer le rôle de « distributeur
de tickets ».
En fait, un sémaphore est un compteur (éventuellement binaire) qui peut
être incrémenté et décrémenté de manière atomique.
Un sémaphore est une structure à deux champs :
typedef struct {
unsigned int valeur ;
CB * file ;
} semaphore ;
I valeur : une variable entière, ou valeur du sémaphore qui représente à un

moment donné le nombre d’accès possibles à une ressource. Un sémaphore est
dit binaire si sa valeur ne peut être que 0 ou 1, général sinon.
I file : une file d’attente des processus ou threads contenant les blocs de
contrôle
L’attente passive
Les sémaphores
Un sémaphore est une variable globale manipulé par les opérations suivantes :
Init(s, x) : initialiser le sémaphore « s » avec la valeur x qui indique le
nombre de permissions;
P(s) [Proberen « tester »]: décrémenter la valeur de sémaphore et
bloquer le processus si sa valeur est strictement négative ( < 0).
V(s) [Verhogen « incrémenter »]: incrémenter la valeur du sémaphore et
réveiller un processus bloqué si sa valeur est négative (≤ 0).

L’attente passive
Les sémaphores
Les opérations P(s) et V(s) sont équivalentes à l’exécution atomique des

séquences d’instructions suivante:
void P ( semaphore s )
{
s . valeur = s . valeur -1;
if ( s . valeur < 0)
suspendre et ajouter le processus appelant dans la file associ é e à s
}
void V ( semaphore s )
{
s . valeur = s . valeur + 1;
if ( s . valeur <= 0)
d é bloquer un des processus de la file associ é e à s
}

L’attente passive
Les sémaphores
La définition d’un sémaphore et des primitives P et V a les conséquences

suivantes:
I Un sémaphore ne peut pas être initialisé à une valeur négative, mais il peut
devenir négatif après un certain nombre d’opérations P.
I Un processus qui invoque la primitive V sur un sémaphore, réveillera un autre
processus bloqué derrière ce sémaphore, si sa valeur est négative (≤ 0).
Le processus qui invoque l’opération P sur un sémaphore peut soit :
I Se bloquer en le mettant dans la file associée au sémaphore, lorsque la valeur
du sémaphore est inférieure à zéro.
I Continue son exécution normalement lorsque la valeur du sémaphore est
supérieure ou égale à zéro;
La valeur « x » du sémaphore « S » dénote soit:
I le nombre de processus bloqués derrière S (si x < 0),
I le nombre de processus qui peuvent exécuter l’opération P sans être bloqués
(si x>=0).

L’attente passive
Les moniteurs
Un moniteur est un autre outil de synchronisation de haut niveau, introduits

par Brinch-Hansen, Dijkstra et Hoare en 1973.
Il permet de rassembler dans une même structure toutes les SC associées à
une ressource (ou à un ensemble de ressources).
Cette structure contient:
I Des variables internes et des variables partageables (ou ressources critiques),
I Des procédures/fonctions internes assurant l’accès en EM aux ressources
(sections critiques).
I Des conditions qui ne peuvent être manipulées que par deux opérations wait
et signal. Chaque condition est munie d’une file d’attente contenant les
processus bloqués derrière cette condition.
Ainsi, la structure du moniteur assure qu’un seul processus à la fois puisse
être actif dans le moniteur, i.e. qu’un seul processus accède à la fois au
moniteur et les autres attendent dans une file d’entrée.

L’attente passive
Les moniteurs
Désormais, il suffit au programmeur de reporter la section critique dans des

procédures du moniteur.
Une fois les procédures définies, elles pourront être appelées par les processus
sans qu’il n’ait connaissance ni accès à la structure interne des procédures.
Le compilateur vérifie avant d’exécuter le processus si un autre processus est
actif dans le moniteur.
Etant donné que cette vérification est reportée sur le compilateur, on écarte
le risque d’erreur engendré par l’inversion des P et V pour les sémaphores.

L’attente passive
Les moniteurs
Un moniteur peut avoir un nombre varié de conditions qui ne peuvent être

manipulées que par deux opérations :
wait : bloque inconditionnellement le processus appelant et le met en
attente dans la file associée à la condition.
signal : libère l’un des processus en attente si la file de la condition est non
vide et met le processus qui l’exécute en attente jusqu’à ce que le processus
réveillé quitte le moniteur.

L’attente passive
Les moniteurs
Le programme ci-dessous exprime une solution à l’aide des moniteurs à un

problème dans lequel deux processus s’exécutent en parallèle.
I Le premier processus dépose des objets dans une structure de données de
capacité N. Le second retire de cette structure.
Monitor nom_moniteur
condition plein , vide ;
int cpt ;
void mettre ()
{
if ( cpt == N ) wait ( plein ) ; // la limite de depot est de N
mettre_objet () ;
cpt ++ ;
}
Void retirer ()
{
if ( cpt == 0) wait ( vide ) ; /* ne pas retirer s ’ il n ’y pas d ’ objet */
retirer_objet () ;
cpt - -;
if ( cpt == N -1) signal ( plein )
}
cpt = 0;
end monitor ;

L’attente passive
Les moniteurs
void .......()
{
......
nom_moniteur . mettre ;
.....
}
void .......()
{
.....
nom_moniteur . retirer ;
.....
}

Communication
interprocessus

Rappel : types de processus
Processus indépendants
I Ne peuvent pas affecter ou être affecté par d’autres processus
Processus coopératifs
I Peut être affecté ou affecter d’autres processus
Le partage de données définit le type de processus
I Indépendant sans partage et coopératif avec

Processus coopératif
Les processus nécessitent de communiquent entre eux afin d’échanger des

données ou des résultats.
Par Example :
I Un programmeur peut décomposer son programme en traitements plus ou
moins indépendants et créer un processus afin d’exécuter chaque traitement.
I Au fur et à mesure de l’exécution, les processus auront besoin de
communiquer afin de s’échanger leurs résultats.
Plusieurs raisons pour la coopération de processus
I Partage d’information : accès concurrent au même fichier
I Accélération du calcul : découpe en sous-tâches
I Modularité : séparer les fonctions en processus/thread
I Commodité : plusieurs tâches utilisateurs en même temps
Cette coopération a besoin d’un moyen de communication interprocessus :
InterProcessus Communication (IPC)

Modèles de communication
On recense essentiellement deux principaux moyens de communication entre
processus :
Création d’une zone de mémoire partagée : échange coordonné
d’information par cette zone de mémoire
Utilisation d’un passage de messages : échange de messages entre les
processus

Modèles de communication
Mémoire partagée
I Très rapide à exécuter une fois la zone partagée établie
Aucune sollicitation de l’OS une fois la zone établie
I Protection à faire contre les modifications concurrentes
Utilisation, par exemple, de sémaphores
I Éventuel problèmes de cohérence de cache
En particulier sur les systèmes multiprocesseurs
Passage de messages
I Passage de messages utilisé pour des petits messages
Car il n’y a pas de conflits à éviter
I Plus facile à implémenter dans un système distribué
Primitives simples à utiliser
I Plus lent à exécuter et consommateur de temps
De nombreux appels systèmes à utiliser en permanence

Mécanisme d’IPC : Mémoire partagée
Dans un programme donné, lorsque l’on souhaite modifier une variable V par
plusieurs procédures, celle-ci est passée en paramètres par adresse à chaque
procédure.
On peut alors dire que les procédures communiquent entre elles au moyen de
la variable V.
Transposons cet exemple pour deux processus :
I la même variable V ne peut être modifiée par les deux processus pour une
raison de visibilité car généralement chaque processus s’exécute dans un
espace d’adressage séparé.
I Les données d’un processus P1 sont modifiées à l’intérieur de son segment de
données et donc inaccessibles à un autre processus P2 .
Le programmeur doit recourir à une technique explicite de communication
entre les processus afin d’échanger entre eux les valeurs de la variable V.

La communication par mémoire partagée permet aux processus de partager

une zone mémoire dans laquelle ils placent les variables en commun.
Le système d’exploitation leur fournit de la sorte une zone mémoire à laquelle
ils vont se rattacher pour partager ces variables.
Le système d’exploitation autorise les processus à accéder à la même zone
mémoire.
I Retraite de la protection mémoire pour les deux processus
La gestion du format et de la concurrence fait par les processus
I Le système d’exploitation n’intervient qu’à la création et à la libération de
mémoire partagée
Plusieurs étapes pour établir une communication par mémoire partagée :
I Création/recherche d’une zone de mémoire partagée
I Attachement à la zone de mémoire partagée
I Lecture/écriture dans la zone de mémoire partagée
I Libération de la ressource


Problème du producteur-consommateur
Deux processus partagent un buffer commun de taille fixe :

I Un processus (producteur) produit des éléments dans un buffer
I Un processus (consommateur) consomme les éléments dans le buffer
Les problèmes se produisent lorsque le producteur souhaite placer un nouvel
élément dans le buffer alors que ce dernier est déjà plein.
I La solution pour le producteur est d’entrer en sommeil, pour être réveillé
lorsque le consommateur aura supprimé un ou plusieurs éléments du buffer.
De la même façon, si le consommateur souhaite récupérer un élément dans le
tampon, alors que celui ci est vide.
I La solution pour le consommateur est d’entrer en sommeil, jusqu’a ce que le
producteur ait placé quelque chose dans le buffer, opération qui va le réveiller.
On peut représenter un tel buffer par de la mémoire partagée.


Problème du producteur-consommateur : Implémentation
Implémentation du buffer de taille fixe comme un tableau circulaire :

I On pourra stocker BUFFER_SIZE - 1 items dans le buffer
# define BUFFER_SIZE 10
typedef struct {
// ...
} item ;
item buffer [ BUFFER_SIZE ];

int in = 0; // prochaine case à remplir
int out = 0; // prochaine case à vider


Producteur :
1 Attendre que le buffer ne soit pas plein
2 Ajouter un élément dans le buffer
3 Avancer le pointeur in d’une position
while ( true )
{
// tant que le buffer est plein
while ((( in + 1) % BUFFER_SIZE ) == out )
{
// on ne fait rien
}
buffer [ in ] = next_produced ;
in = ( in + 1) % BUFFER_SIZE ;
}


Consommateur :
1 Attendre que le buffer ne soit pas vide
2 Prendre un élément dans le buffer
3 Avancer le pointeur out d’une position
while ( true )
{
// tant que le buffer est vide
while ( in == out )
{
// on ne fait rien
}
next_consumed = buffer [ out ];

out = ( out + 1) % BUFFER_SIZE ;
}

Mécanisme d’IPC : Passage de messages
Dans le deuxième mécanisme d’IPC, Les processus échangent

explicitement des messages entre eux qu’ils transmettent à travers un
système de communication.
Communication par messages se fait avec deux opérations principales :
I send (msg) : envoie un message
I receive (msg) : reçoit un message
Les messages peuvent être de tailles fixes ou variables
I Le premier choix facilite l’implémentation du système
Il existe différentes caractéristiques du lien de communication
I Communication directe ou indirecte
I Communication synchrone ou asynchrone
I Buffer automatique ou implicite


Communication directe entre les processus
Dans la communication directe, les processus communiquants sont

nommés dans les primitives.
Ex. le numéro d’identification PID
I send (P, msg) : envoie un message au processus P
Le message est copié dans la file de message du récepteur.
Les messages sont des chaînes de n’importe quelle longueur.
Cette primitive échoue si le processus de destination n’existe pas.
I receive (Q, msg) : reçoit un message de processus Q
Les messages sont reçus dans l’ordre où ils sont envoyés.
Cette primitive échoue si un processus émetteur est spécifié n’existe pas.
Il y a exactement un lien entre toute paire de processus, Ceux qui ont
manifesté l’envie de communiquer entre eux.
Tout processus, quel qu’il soit, peut envoyer (ou recevoir) un message à
tout autre processus.


Communication indirecte entre les processus
D’après le second schème, le passage du message est réalisé indirectement

par le biais d’une boîte aux lettres.
Les processus envoient/reçoivent des messages vers des ports, dont on
ignore l’identifiant.
I Les ports représentent des boîtes aux lettres, à partager
Deux processus communiquant doivent partager une boite
I send (A, msg) : envoie un message à la boîte A
I receive (A, msg) : reçoit un message de la boîte A
Le lien de la boîte est partagée peut être associé à plus de deux processus.
La communication peut se faire entre plusieurs processus
I Chaque message ne sera lu que par un processus au plus.
Plusieurs liens possibles entre la même paire de processus
I Il suffit d’avoir plusieurs boîtes partagées


Communication indirecte entre les processus
Le system d’exploitation propose des opérations pour gérer les boîtes :

I create (mailBox) : Créer une nouvelle boîte appelée mailBox
Cette primitive échoue si la boîte aux lettres existe déjà.
I delete (mailBox) : supprime une boîte appelée mailBox
Cette primitive échoue si le processus qui émet la primitive n’est pas
propriétaire de la boîte ou si la boîte aux lettres n’existe pas.
I send (mailBox, msg) : envoie un message à la boîte mailBox
le message est copié dans la boîte.
Tout processus peut envoyer un message à n’importe quelle boîte.
Cette primitive échoue si la boîte aux lettres n’existe pas.
I receive (mailBox, msg) : reçoit un message en provenance de la boîte
mailBox
Les messages sont reçus dans l’ordre de leur envoi.
Cette primitive échoue si le processus qui émet la primitive n’est pas le
propriétaire de la boîte ou si cette dernière n’existe pas.


Synchronisation
Deux modes de communication : synchrone et asynchrone

I Les appels send et receive peuvent être bloquants ou non
On distingue Quatre situations différentes :
On peut aussi bloquer pendant un certain temps spécifié

I L’appel peut donc débloquer en renvoyant une valeur d’erreur.


Buffer de messages
File de messages implémentée avec des buffers, que ce soit une

communication directe ou indirecte.
Trois choix d’implémentation possibles :
I Capacité nulle : L’émetteur doit attendre que le récepteur ait lu le message.
I Buffer limité : n messages maximum, l’émetteur doit attendre si la file est
pleine.
I Buffer illimité : Longueur infinie, l’émetteur n’attend jamais

Main 5

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

Main 5

Transféré par

Droits d'auteur :

Formats disponibles

Synchronisation des processus

Pr. Abdessamad EL BOUSHAKI

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 1/72

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 2/72

Introduction : ressources d’un processus

Un processus a besoin de ressources pour s’exécuter: procédures et données,

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 3/72

Introduction : ressources d’un processus

Ressources physiques vs logiques

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 4/72

Introduction : ressources d’un processus

Ressources locales vs communes

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 5/72

Introduction : ressources d’un processus

Ressources mono-accès vs multi-accès

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 6/72

Introduction : ressources d’un processus

Ressources banalisées vs non banalisées

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 7/72

Introduction : ressources d’un processus

Ressources préemptibles vs non préemptibles

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 8/72

Introduction : ressources d’un processus

I Libre : la ressource est disponible

Introduction : ressources d’un processus

Le système d’exploitation garde la liste des descripteurs des ressources dans

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 10/72

Dans un environnement multitâches, plusieurs processus peuvent se

I Exécution séquentielle sur un seul processeur ⇒ pseudo-parallélisme

I Exécution en parallèle sur deux processeurs distincts ⇒ parallélisme réel

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 11/72

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 12/72

Selon que les processus concurrents se connaissent mutuellement ou pas, on

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 13/72

Le rôle et mécanismes de la synchronisation

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 14/72

Tout comme les processus, les threads POSIX fonctionnent de manière

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 15/72

Lorsque plusieurs processus s’exécutent sur un ordinateur, monoprocesseur

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 16/72

Soient deux transactions (processus) P1 et P2 lancées en parallèle de deux

Transaction 1 (P1 ) Transaction 2 (P2 )

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 17/72

Deux cas possible pour l’exécution de P1 et P2 :

Normalement le résultat final correct devrait être C0+SV-SR : l’exécution parallèle

Pour éviter cette incohérence, il faut empêcher l’exécution parallèle de P1 et

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 19/72

Une section critique (SC) est un ensemble d’instruction d’un programme

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 20/72

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 21/72

Le principe général d’une solution garantissant l’EM:

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 22/72

Le principe général d’une solution garantissant l’EM:

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 23/72

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 24/72

Pour étudier et comparer les solutions au problème de l’EM, on se donne un

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 25/72

La solution au problème de l’EM doit avoir les propriétés suivantes (propriétés de

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 26/72

Réalisation de l’exclusion mutuelle

Contrôler la compétition entre processus, revient à trouver une solution au

Pr. Abdessamad EL BOUSHAKI (FST Marrakech) Système d’exploitation 27/72

Matériellement, une EM peut être réalisée en :