Ch2 SE SI 2022-2023

Université de Bouira
Faculté des Sciences et des Sciences appliquées

Département d’Informatique
Licence SI (Systèmes Informatiques)
Semestre 5
Systèmes d’exploitation 2
A. ABBAS
abbasakli@gmail.com
1
Systèmes d‘exploitation 2 :Dr. A. ABBAS
²
Chapitre 2:
Synchronisation
2
CONTENU DU COURS
Synchronisation
· Problème de l’exclusion mutuelle
· Synchronisation
o Evénements, Verrous
o Sémaphores
o Moniteurs
o Régions critiques.
o Expressions de chemins
²
3
Problématique
Lorsque plusieurs processus (ou threads) s'exécutent sur processeur sont amenés a
partager des ressources comme : les périphériques d'entrées-sorties (écrans,
imprimantes,..), les moyens de mémorisation (mémoire centrale,...) ou des moyens
logiciels (fichiers, base de données, ...) soit volontairement s'ils coopèrent pour
traiter un même problème, soit involontairement parce qu'ils sont obliges de se
partager ces ressources vue leurs nombre limite.
²
Dans ce cas, les processus vont se trouver en situation de concurrence d'accès vis-à-
vis de ces ressources offertes par le système d'exploitation.
Malheureusement, le partage des ressources sans précaution particulière peut conduire à

des résultats imprévisibles. L‘état final des données dépend de l'ordonnancement des
processus.
4
Problématique
La mise a jour concurrente des données peut se dérouler sans problème, où la variable
cpt, initialisée à 2000, aura comme valeur finale 1000 (2000 + 1000 - 2000).
5
Problématique
Malheureusement, la mise a jour concurrente peut générer des incohérences, où la

variable cpt, aura comme valeur finale 0 après l'exécution du même code. On voit
que l'exécution de plusieurs threads peut conduire a des résultats incohérents.
La cause de cette incohérences est due a l'utilisation simultanée de la ressource
partagée (la zones mémoire de la variable cpt) par plusieurs programmes.
6
Synchronisation
1- Introduction
Lorsque plusieurs processus s'exécutent dans un système d'exploitation multitâches,

en pseudo-parallèle ou en parallèle et en temps partagé, ils partagent des ressources
(mémoires, imprimantes,…etc.). Cependant, le partage d'objets sans précaution
particulière peut conduire a des résultats incohérents.
²
Solution
La solution a ce problème s'appelle synchronisation des processus.
7
Synchronisation
2- Définitions
1. Ressources critiques:
a. Les ressources partagée, comme des zones mémoire, cartes d'entrées/sorties, etc.,
sont dites critiques si elles ne peuvent être utilisées simultanément que par un seul
processus.
b. On appelle ressource critique tout objet : variable, table, fichier, périphérique, ... qui
²
peut faire l'objet d'un accès concurrent (ou simultané) par plusieurs processus.
2. Section critique
a. Une section critique (SC) est un ensemble d'instruction d'un programme qui peuvent
engendrer des résultats imprévisibles (ou incohérents) lorsqu'elles sont exécutées
simultanément par des processus différents.
b. Une SC est une suite d'instructions qui opèrent sur une ou plusieurs ressources
partagées (critiques) et qui nécessitent une utilisation exclusive de ces ressources.
8
Synchronisation
2- Définitions
3. Exclusion mutuelle
Les problème d'incohérences des résultats, posé par les accès concurrents, montrent que
la solution consiste à exécuter les sections critiques en exclusion mutuelle. C'est à dire
qu'une section critique (SC) ne peut être entamée (ou exécutée) que si aucune autre SC
du même ensemble n'est en exécution.
²
Le principe général d'une solution garantissant que l'exécution simultanée de plusieurs

processus ne conduirait pas à des résultats imprévisibles est : 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 avancer tant que l'autre processus
n'aura pas termine sa SC.
9
Synchronisation
2- Définitions
3. Exclusion mutuelle
Par exemple, avant d'entrer en SC, le processus doit exécuter un protocole d'entrée. Le
but de ce protocole est de vérifier 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.
²
Le pseudo-code suivante résume ce fonctionnement :
10
Synchronisation
2- Conditions nécessaires pour réaliser une exclusion mutuelle
Pour réaliser une exclusion mutuelle utile on admet que certaines conditions doivent
être respectées :
1. Le déroulement : Le fait qu'un processus qui ne demande pas à entrer en section
critique ne doit pas empêcher un autre processus d'y entrer. En plus, aucun processus
suspendu en dehors de sa section critique ne doit bloquer les autres processus.
²
2. L'attente infinie : Si plusieurs processus sont en compétition pour entrer en SC, le

choix de l'un d'eux ne doit pas être repoussé indéfiniment. Autrement dit, la solution
proposée doit garantir que tout processus n'attend pas indéfiniment.
3. Deux processus ne peuvent être en même temps dans leurs sections critiques.
4. Tous les processus doivent être égaux vis a vis de l'entrée en SC.
11
Synchronisation
3- Solutions pour réaliser une exclusion mutuelle
1- Masquage des interruptions
Avant d'entrer dans une section critique, le processus masque les interruptions.
Il les restaure (non masque) a la fin de la section critique.
Il ne peut être suspendu alors durant l'exécution de la section critique.
Exemple : Masque des interruptions
²
Local_irq_disable(); /* Les interruptions sont masquées .. */
Section critique ();
Local_irq_enable();
Problèmes:
1- Si le processus ne restaure pas les interruptions a la sortie de la section critique, ce serait
le bug du système.
2- Elle assure l'exclusion mutuelle, si le système est monoprocesseur puisque le masquage

des interruptions concerne le processeur qui a demandé ce masquage. Les autres processus
exécutés par un autre processeur pourront donc accéder aux ressources partagées.
12
Synchronisation
2- Attente active
Utiliser une variable de verrouillage partagée verrou, unique, initialisée a 0. Pour
rentrer en section critique, un processus doit tester la valeur de verrou
• Si elle est égale à 0, le processus modifie la valeur du verrou1 et exécute sa
section critique. A la fin de la section critique, il remet le verrou a 0.
²
• Sinon, il attend (par une attente active) que le verrou devienne egal à 0, c.-a-d.
: while(verrou ≠0);
13
Synchronisation
2- Attente active
Problèmes: Cette méthode n'assure pas l'exclusion mutuelle
 Si un processus P1 est suspendu juste après avoir lu la valeur du verrou qui est égal à 0
(par exemple: mov verrou).
 Ensuite, si un autre processus P2 est élu et il teste le verrou qui est toujours égal a 0,
²
met verrou 1 et entre dans sa section critique.
 Si P2 est suspendu avant de quitter la section critique et que P1 est réactivé et entre
dans sa section critique et met le verrou1
Résultats: Les deux processus P1 et P2 sont en même temps en section critique.
Susceptible de consommer du temps en bouclant inutilement.
14
Synchronisation
3 - Solution de Peterson
- Cette solution se base sur deux fonctions entrer_region et quitter_region.
- Chaque processus doit, avant d'entrer dans sa section critique, appeler la fonction
entrer_region en lui fournissant en paramètre son numéro.
- Cet appel le fera attendre si nécessaire² jusqu'a ce

qu'il n'y ait plus de risque.
- A la fin de la section critique, il doit appeler
quitter_region pour indiquer qu'il quitte sa section
critique et pour autoriser l'accès aux autres processus.
15
Synchronisation
3 - Solution de Peterson
Le pseudo code des deux fonction est donné ci-dessous:
Note: Les variables tour et interesse sont globales.

• La généralisation de cette solutions aux cas de plusieurs processus est bien complexe.
• Susceptible de consommer du temps en bouclant inutilement.
16
Synchronisation
4 - Sémaphore
Pour contrôler les accès a un objet partage, Dijkstra (en 1965) a suggéré l'utilisation
d'un nouveau type de variables appelées les sémaphores.
Définition : Un sémaphore S est un ensemble de deux variables :

1. Une valeur (ou compteur) entier notée value désigne le nombre d'autorisations
²
d'accès à une section critique. Cette valeur est manipulable au moyen des
opérations P (ou wait) et V (ou signal);
2. Une file F des processus en attente.
17
Synchronisation
4 - Sémaphore
L'opération P(S) décrémente la valeur du sémaphore S. Puis, si cette dernière est
inferieure à 0 alors le processus appelant est mis en attente. Sinon le processus appelant
accède a la section critique.
18
Synchronisation
4 - Sémaphore
L'opération V(S) incrémente la valeur du sémaphore S. Puis si cette valeur est supérieure
ou égale à 0 alors l'un des processus bloqués par l'opération P(S) sera choisi et
redeviendra prêt.
19
Synchronisation
4 - Sémaphore
L'existence d'un mécanisme de file d'attente (FIFO ou LIFO), permettant de

mémoriser le nombre et les demandes d'opération P(S) non satisfaites et de réveiller
les processus en attente.
²
Remarque 1 : Le test du sémaphore, le changement de sa valeur et la mise en attente
éventuelle sont effectués en une seule opération atomique indivisible.
Remarque 2 : La valeur initiale du champ value d'un sémaphore doit être un nombre
non négatif. La valeur initiale d'un sémaphore est le nombre d'unités de ressource.
20
Synchronisation
4 - Sémaphore
Ainsi, on peut proposer un schéma de synchronisation de n processus voulant entrer
simultanément en SC, en utilisant les deux opérations P(S) et V(S).
En effet, il suffit de faire partager les n processus un sémaphore S , initialise a 1, appelé

sémaphore d'exclusion mutuelle.
²
Chaque processus Pi a la structure suivante :
21
Synchronisation
4 – Sémaphore - Exemple 1
Considérons deux processus P1 et P2 exécutent respectivement deux instructions

S1 = A+2 B; et S2 = S1+10.
Si nous souhaitons que S2 ne doit s'exécuter qu'après l'exécution de S1, nous pouvons
implémenter ce schéma en faisant partager P1 et P2 un sémaphore commun S, initialise
²
a 0 et en insérant les primitives P(S) et V(S) de la façon suivante:
22
Synchronisation
4 – Sémaphore - Exemple 2: Lecteurs / Rédacteurs
Considérons un objet (une base de donnée par exemple) qui n'est accessible que par deux
catégories d'opérations : les lectures et les écritures. Plusieurs lectures (consultations)
peuvent avoir lieu simultanément ; par contre les écritures (mises a jour) doivent se faire
en exclusion mutuelle.
²
On appellera lecteur un processus faisant des lectures et rédacteur un processus faisant
des écritures.
Il s'agit donc de réaliser la synchronisation entre lecteurs et rédacteurs en respectant

les contraintes suivantes :
23
Synchronisation
Exclusion mutuelle entre lecteurs et rédacteurs : si un lecteur demande a lire et qu'il

y a une écriture en cours , la demande est mise en attente. De même que si un rédacteur
demande à écrire et qu'il y a au moins une lecture en cours , la demande est mise en
attente. ²
Exclusion mutuelle entre rédacteurs : si un rédacteur demande a écrire et qu'il y a

une écriture en cours , la demande est mise en attente.
Pour satisfaire ces contraintes ci-dessus , on peut procéder comme suit :
24
Synchronisation
25
Synchronisation
4 – Sémaphore - Services Posix sur les semaphores
Le système d'exploitation Linux permet de créer et d'utiliser les sémaphores définis
par le standard Posix.
Les services Posix de manipulation des sémaphores se trouvent dans la librairie
<semaphore.h>.
²
Le type sémaphore est désigné par le type sem_t.
Initialisation d'un sémaphore
int sem_init(sem_t *sem, int pshared, unsigned int valeur)

• sem : est un pointeur sur le sémaphore à initialiser;
• value : est la valeur initiale du sémaphore ;
• pshared : indique si le sémaphore est local au processus (pshared=0) ou partage
entre le père et le fils pshared ≠0.
26
Synchronisation
4 – Sémaphore - Services Posix sur les sémaphores
int sem_wait(sem_t *sem) : est équivalente à l'opération P (S) et retourne toujours 0.

int sem_post(sem t *sem): est équivalente a l'opération V(S) : retourne 0 en cas de
succès ou -1 autrement.
int sem trywait(sem_t *sem) : décrémente la valeur du sémaphore sem si sa valeur
²
est supérieure à 0 ; sinon elle retourne une erreur. C'est une opération atomique.
int sem_getvalue (sem_t * sem, int * sval): récupérer la valeur d'un sémaphore : il
retourne toujours 0.
int sem destroy (sem t* sem): détruire un sémaphore. Retourne -1 s'il y a encore des
waits.
27
Synchronisation
4 – Sémaphore - Exemple 3: le problème du producteur-consommateur
Le problème de Producteur-Consommateur est un problème de synchronisation

classique qui permet de représenter une classe de situations où un processus, appelé
Producteur, délivre des messages (informations) à un processus Consommateur
dans un tampon (par exemple, un programme qui envoie des données sur le spool de
l'imprimante).
Le Producteur produit un message dans la ² ZoneP, puis le dépose dans le buffer. Le
Consommateur prélève un message du Buffer et le place dans la ZoneC où il peut le
consommer.
On considérera que le buffer est de N cases, de 0 à N-1, et organisé de façon

circulaire. Le Producteur dépose les messages par un bout du buffer alors que le
consommateur les consomme au fur et à mesure par l’autre bout.
28
Synchronisation
n producteurs produisent des messages et les déposent dans un tampon de taille

illimitée. n consommateurs peuvent récupérer les messages déposés dans le tampon.
Semaphore Mutex = 1 ;
Message tampon[ ]; Consommateur( ){
Producteur ( ){ ² Message m ;
Message m ; Tantque Vrai faire
Tantque Vrai faire Mutex.P() ;
m = creermessage() ; m = LectureTampon();
Mutex.P() ; Mutex.V() ;
EcritureTampon(m); Fin Tantque
Mutex.V() ; }
FinTantque
}
Adaptez cette solution pour que l'échange des message soit synchronisé
(consommateurs bloqués si le tampon est vide).
29
Synchronisation
Semaphore Mutex = 1, Plein = 0 ;

Message tampon[];
Producteur ( ){ Consommateur( )
Message m ; {
Tantque Vrai faire Message m ;
² Tantque Vrai faire
m = creermessage() ;
Mutex.P() ; Plein.P();
EcritureTampon(m); Mutex.P() ;
Mutex.V() ; m = LectureTampon();
Plein.V(); Mutex.V() ;
FinTantque Fin Tantque
} }
30
Synchronisation
4 – Sémaphore -Critiques
Les programmes utilisant les sémaphores sont généralement difficile à réaliser et à

"débuguer" car les erreurs, (oublie de V ou utiliser P à la place de V), sont dues à des
conditions de concurrence, des inter-blocages ou d'autres formes de comportement
imprévisibles et/ou difficiles à reproduire.
²
D'autre part, les sémaphores sont des objets globaux et doivent être connus de tous les
participants. De plus, la synchronisation par les sémaphores nécessite l'étude de tout un
programme concurrent pour comprendre l'aspect synchronisation qu'il renferme.
Pour palier à ces points faibles, le concept de moniteur a vu le jour

Ce concept a été implémenté dans des langages de programmation concurrente : C#
ainsi que Java.
31
Synchronisation
5 – Les Moniteurs -Définition
L'idée des moniteurs est de regrouper dans un module spécial, appelé moniteur, toutes
les sections critiques d'un même problème.
Un moniteur est un ensemble de procédures,

² de variables et de structures de données.
Les processus peuvent appeler (ou utiliser) les procédures du moniteur mais ils ne
peuvent pas accéder aux variables et aux structures de données interne du moniteur à
partir des procédures externes.
32
Synchronisation
5 – Les Moniteurs -Exclusion mutuelle par des moniteurs
Pour assurer l'accès aux ressources critiques en exclusion mutuelle, il suffit qu'il y ait à
tout instant pas plus d'un processus actif dans le moniteur, c'est-a-dire que les procédures
du moniteur ne peuvent être exécutées que par un seul processus a la fois. C'est le
compilateur qui effectue de cette tâche (assurer l'accès aux ressources critiques).
Pour cela, le compilateur rajoute, au début de² chaque procédure du moniteur un code qui
réalise ce qui suit:
 S'il y a un processus P1 actif dans le moniteur, alors le processus P2 appelant est

suspendu jusqu'a ce que le processus actif dans le moniteur se bloque en exécutant un
wait sur une variable conditionnelle (wait(c)) ou quitte le moniteur.
 Le processus bloqué est réveillé par un autre processus en lui envoyant un signal sur
la variable conditionnelle (signal(c)).
33
Synchronisation
5 – Les Moniteurs
Une variable de condition (des moniteurs) est une condition manipulée au moyen de
deux opérations wait et signal :
wait(x) :
²
suspend l'exécution du processus (thread) appelant (le met en attente de x);
 autorise un autre processus en attente du moniteur a y entrer.
signal(x) : débloqué un processus en attente de la condition x.
34
Synchronisation
5 – Les Moniteurs -Implémentation des moniteurs
L'utilisation de moniteurs est plus simple que les sémaphores puisque le programmeur
n'a pas a se préoccuper de contrôler les accès aux sections critiques.
Mais, malheureusement, a l'exception de ²JAVA (avec le mot clé synchronized) et C#,

la majorité des compilateurs utilisés actuellement ne supportent pas les moniteurs. Par
contre, on peut simuler les moniteur avec d'autres langages à partir des mutex
comme suit:
• Le moniteur contient un sémaphore binaire (par exemple: mutex)

• Toutes les procédures commencent par l'acquisition du mutex et finissent par sa
libération.
35
Synchronisation
5 – Les Moniteurs –Exemple 1 : Producteur/consommateur
 Les sections critiques du problème du producteur et du consommateur sont les

opérations de dépôt et de retrait dans le tampon partagé.
 Le consommateur est actif dans le moniteur et le tampon est vide => il devrait se
mettre en attente et laisser place au producteur.
²
 Le producteur est actif dans le moniteur et le tampon est plein => il devrait se
mettre en attente et laisser place au consommateur.
36
Synchronisation
5 – Les Moniteurs –Exemple 1 : Producteur/consommateur
Moniteur ProducteurConsommateur (){
bool nplein, nvide ; //variable de condition pour non
plein et non vide void retirer (int* objet) //section critique
int compteur =0, ic=0, ip=0, N ; pour le retrait
{ if (compteur ==0) wait(nvide) ;
void mettre (int objet) // section critique pour le dépôt objet = tampon[ic] ;
{ ² ic = (ic+1)%N ;
if (compteur==N) wait(nplein) ; //attendre compteur - ;
jusqu'a ce que le tampon soit non plein
// si le tampon était plein, envoyer un
tampon[ip] = objet ; signal pour réveiller le producteur.
ip = (ip+1)%N ;
compteur++ ; if(compteur==N-1) signal(nplein) ;
}
// si le tampon était vide, envoyer un }
signal pour réveiller le consommateur.
if (compteur==1) signal(nvide) ;
}
37
Synchronisation
5 – Les Moniteurs - Règles d'utilisation des moniteurs
An d‘éviter que tous les processus réveillés se retrouvent au même temps dans le
moniteur, différentes règles ont été établies pour définir ce qui se passe a l'issue d'un
signal.
1. Règle de Hoare : ne laisser entrer dans le moniteur que le processus qui a été
suspendu le moins longtemps;
²
2. Regle de Brinch Hansen : exiger du processus qui fait Signal de sortir
immédiatement du moniteur. Il laisse ainsi la place a tous ceux qui étaient en attente.
L'ordonnanceur choisira un parmi ceux ci.
3. 2ème règle de Brinch Hansen : si un Signal est réalise sur une variable
conditionnelle et qu'aucun processus ne l'attend, alors ce signal est perdu.
38
Synchronisation
5 – Les Moniteurs - Réalisation sous C/POSIX
Pour garantir qu'une seule procédure du moniteur soit activée à instant donne, il suffit
de protéger l'exécution de toutes les procédures par le même sémaphore d'exclusion
mutuelle.
Exemple Moniteur: probleme Producteur/consommateur
pthread_mutex_t mutex ; ²
pthread_cond_t est_vide, est_plein;
char *buffer;
void *mettre (char msg) {// section critique pour le dépôt
pthread_mutex_lock ( & mutex);
while (buffer ! = NULL)
pthread_cond _wait ( & est_vide, & mutex);
// buer = NULL
buffer = strdup(msg);
Pthread_cond_signal ( & est_plein);
pthread_mutex _unlock ( & mutex);
} 39
Synchronisation
5 – Les Moniteurs - Réalisation sous C/POSIX
char *retirer () {//section critique pour le retrait
char *result;
pthread_mutex_lock ( & mutex);
while (buffer == NULL)
pthread_cond _wait ( & est_plein, & mutex);
result = buer;
buffer = NULL; ²
pthread_cond_signal ( & est_vide);
pthread_mutex_unlock ( & mutex);
return result;
} void main (void){
pthread_t ta; pthread_t tb;
pthread_mutex_init (&mutex, NULL);
pthread_cond_init (& est_vide, NULL);
Pthread_cond_init (& est_plein, NULL);
buffer = NULL;
}
40
Synchronisation
5 – Les Moniteurs - Résumé des types et des fonctions utilisés
41
Synchronisation
5 – Les Moniteurs - Réalisation avec JAVA
Le concept de moniteur est implémente dans la MVJ de la manière suivante :
 Les données du moniteur doivent être déclarées avec le mot clé privates pour
que seules les méthodes du moniteur accèdent à ces données,
 Les méthodes (ou procédures d'entrée)² du moniteur doivent être déclarées avec
le mot clé synchronized pour qu'elles puissent s'exécuter en exclusion mutuelle,
 La classe Object fournit les méthodes wait() et notify() pour la synchronisation

des threads.
42

Ch2 SE SI 2022-2023

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

Ch2 SE SI 2022-2023

Transféré par

Droits d'auteur :

Formats disponibles

Université de Bouira

Faculté des Sciences et des Sciences appliquées

Malheureusement, le partage des ressources sans précaution particulière peut conduire à

Malheureusement, la mise a jour concurrente peut générer des incohérences, où la

Lorsque plusieurs processus s'exécutent dans un système d'exploitation multitâches,

Le principe général d'une solution garantissant que l'exécution simultanée de plusieurs

2. L'attente infinie : Si plusieurs processus sont en compétition pour entrer en SC, le

2- Elle assure l'exclusion mutuelle, si le système est monoprocesseur puisque le masquage

Susceptible de consommer du temps en bouclant inutilement.

- Cet appel le fera attendre si nécessaire² jusqu'a ce

Note: Les variables tour et interesse sont globales.

Définition : Un sémaphore S est un ensemble de deux variables :

L'existence d'un mécanisme de file d'attente (FIFO ou LIFO), permettant de

En effet, il suffit de faire partager les n processus un sémaphore S , initialise a 1, appelé

Considérons deux processus P1 et P2 exécutent respectivement deux instructions

Il s'agit donc de réaliser la synchronisation entre lecteurs et rédacteurs en respectant

Exclusion mutuelle entre lecteurs et rédacteurs : si un lecteur demande a lire et qu'il

Exclusion mutuelle entre rédacteurs : si un rédacteur demande a écrire et qu'il y a

Pour satisfaire ces contraintes ci-dessus , on peut procéder comme suit :

Initialisation d'un sémaphore

int sem_init(sem_t *sem, int pshared, unsigned int valeur)

int sem_wait(sem_t *sem) : est équivalente à l'opération P (S) et retourne toujours 0.

Le problème de Producteur-Consommateur est un problème de synchronisation

On considérera que le buffer est de N cases, de 0 à N-1, et organisé de façon

n producteurs produisent des messages et les déposent dans un tampon de taille

Semaphore Mutex = 1, Plein = 0 ;

Les programmes utilisant les sémaphores sont généralement difficile à réaliser et à

Pour palier à ces points faibles, le concept de moniteur a vu le jour

Un moniteur est un ensemble de procédures,

 S'il y a un processus P1 actif dans le moniteur, alors le processus P2 appelant est

signal(x) : débloqué un processus en attente de la condition x.

Mais, malheureusement, a l'exception de ²JAVA (avec le mot clé synchronized) et C#,

• Le moniteur contient un sémaphore binaire (par exemple: mutex)

 Les sections critiques du problème du producteur et du consommateur sont les

Le concept de moniteur est implémente dans la MVJ de la manière suivante :

 La classe Object fournit les méthodes wait() et notify() pour la synchronisation

Vous aimerez peut-être aussi