Chapitre 1 : NOTIONS DE PARALLELISME, DE COOPERATION ET DE COMPETITION

1) Introduction
 Plusieurs facteurs conduisent à exprimer une application comme un ensemble de
processus relativement indépendants les uns des autres et non plus comme un
programme dont l’exécution est séquentielle.
 Selon l’application traitée, les processus, au sens informatique, peuvent décrire des
processus physiques réels, ou représenter des machines réelles ou virtuelles. Enfin, ils
peuvent contrôler et diriger des processus réels.
 Les processus qui concourent à la réalisation d’une application ont nécessairement des
relations de coopération entre eux. De plus, la mise en œuvre de plusieurs processus
à l’aide d’un nombre limité de ressources (mémoire, périphériques, CPU, …), pose
des problèmes de compétition.
 La mise en œuvre des problèmes typiques de coopération et de compétition se fait par
différents moyens de synchronisation et de communication.
 La concurrence est un aspect de l’informatique et de la programmation, indissociable
des systèmes actuels. Le parallélisme est un domaine issu de la concurrence.
 Lorsque, dans un système informatique, plusieurs processus sont exécutés
simultanément, on dit que ces processus sont exécutés en concurrence, ou aussi que
ces processus sont concurrents.
 On parle de parallélisme, lorsque l’on a affaire à des processus concurrents dont le but
est de résoudre un problème –lorsque l’on recherche la meilleure performance- en
utilisant plusieurs processeurs en parallèle.

2) Rappels sur la notion de processus

 Voir polycopie du cours SE1 (Gestion du processeur).
 Processus :
 Fournit un modèle pour représenter l'activité résultant d'un programme sur une
machine.
 Principal intérêt = Représentation des activités parallèles et de leurs interactions.
 Chaque exécution d’une instruction constitue une action qui a pour effet de faire
passer, en un temps fini, la machine d’un état initial à un état final. Le début et la
fin d’une action a sont des événements dont les dates sont notés deb(a) et fin(a).
 L’exécution d’un programme se traduit alors par une suite d’actions a1, a2, ….., ai,
… avec fin(ai) < deb(ai+1). Une telle suite est appelée processus séquentiel ou
simplement processus.
 Un processus est donc l’entité dynamique qui représente l’exécution d’un
programme sur un processeur.
 Le programme est une description statique ; le processus est une entité dynamique
qui a un début, un déroulement et une fin. Il a un état qui évolue au cours du temps.
Début Etat Temps Fin

 Etat d’un processus : Permet d’exprimer si celui-ci est réellement exécuté, s’il est prêt
à être exécuté (il lui manque le processeur) ou encore s’il est en attente de ressources
autres que le processeur (mémoire, imprimante, …) ou d’un événement extérieur.
 Opération sur les processus :

1
  Créer : un processus peut en créer un autre. On a alors un processus père et un
processus fils (Commande fork d'UNIX) ;
 Détruire : s'auto-détruit (exit pour UNIX) ou est détruit par un autre (kill pour
UNIX) ;
 Mettre en attente et réveiller ;
 Suspendre et reprendre ;
 Changer la priorité.
 Relations entre processus :
 Coopération ;
 Compétition.

3) Concurrence

3.1) Motivations pour la concurrence :

La concurrence entre processus est un sujet de grande actualité pour plusieurs raisons :
a) L’évolution des systèmes personnels (DOS, Windows, MacOs, …) les fait passer
d’une organisation monoprocessus à des systèmes multiprogrammés.
b) Les systèmes classiques (VMS(Digital), Solaris(Sun), Unix, Linux, …) qui sont
multiprogrammés dès leur conception continuent à se développer et sont de plus en
plus souvent multiprocesseurs.
c) Les applications temps réel, embarquées, enfouies, se développent et requièrent des
systèmes temps réel multiprocessus (des exécutifs multi-tâches).
d) La multiplication des applications réparties, des systèmes d’architecture client-serveur
et les architectures réparties à base d’objets.
e) Les besoins des clients nomades et des plates-formes mobiles.
 La connaissance des bons comportements et des bonnes méthodes de programmation
et d’utilisation de ces processus concurrents est indispensable.

3.2) Principaux paradigmes de la concurrence :

* On appelle paradigmes de la concurrence des exemples type qui permettent de
modéliser des classes de problèmes qui sont fréquemment rencontrés et qui sont présents
à tous les niveaux dans les systèmes et dans les applications concurrentes.
* Les principaux paradigmes de la concurrence sont :
- L’exclusion mutuelle  Il modélise l’accès cohérent à des ressources partagées ;
- Le schéma producteurs-consommateurs  Il modélise la communication par un
canal fiable ;
- Le schéma lecteurs-rédacteurs  Il modélise la compétition cohérente ;
- Le schéma du repas des philosophes  Il modélise l’allocation de plusieurs
ressources.
a) Par le paradigme de l’exclusion mutuelle, on exprime que les accès des processus
concurrents à une ressource doivent préserver la cohérence des informations conservées
par cette ressource.

2
b) - Par le paradigme producteurs-consommateurs, on exprime une coopération fiable
car on réalise un contrôle de flux et on garantit que tout message émis est bien reçu une
fois et une seule, après avoir été émis.
- La coopération comprend des producteurs et des consommateurs qui se partagent un
tampon, avec un nombre maximal, taille du tampon. Le contrôle de flux freine les
producteurs s’ils vont trop vite pour les consommateurs.

Tampon de N cases

Producteur Déposer Msg Retirer Msg Consommateur

Producteur Consommateur
Produire un msg ; Retirer un msg ;
Déposer le msg ; Consommer le msg ;

c) - Par le paradigme lecteurs-rédacteurs, on exprime que plusieurs processus lecteurs

peuvent utiliser la ressource en parallèle, soit parce que leur utilisation ne change pas l’état
de la ressource, soit parce que chaque processus a accès à une sous-ressource indépendante
des autres. Cependant, les rédacteurs sont exclusifs entre eux ou avec un lecteur.
- La compétition d’accès met en présence des processus lecteurs et des processus
rédacteurs qui se partagent des données composées. La synchronisation garantit la
cohérence des données écrites ou lues par les processus concurrents.
d) - Avec le paradigme du repas des philosophes, on étudie la sûreté de l’allocation de
2 ressources pour garantir l’absence d’interblocage et on étudie la vivacité pour garantir
l’équité de l’allocation et éviter la famine d’un des processus.
- Partage de plusieurs classes de ressources entre processus concurrents asynchrones.
3.3) Problématique :
* Pour une application donnée, les processus qui coopèrent se connaissent mutuellement
et les relations de coopération sont définies explicitement. Par contre, les relations de
compétition sont indirectes car les processus s’ignorent à priori.
* Quels que soient les motifs, les processus sont en relation et se communiquent des
informations  Ici, nous nous intéressons à la synchronisation des processus impliqués
dans l’échange.

3
* - Nous appelons contrôleur une entité abstraite à laquelle sont reliés les processus à
synchroniser. L’ensemble forme le système de processus.
Processus N
Processus 1

Processus i Contrôleur

- Nous considérons les processus comme discrets : à chaque étape se produit un

événement. L’événement peut être local au processus et non perceptible du reste du
système ou, au contraire, être significatif pour l’ensemble. Il concerne alors le problème
de synchronisation posé. Nous considérons ces seuls événements et nous prenons comme
axiome :
La synchronisation consiste à cadencer (contrôler) l’évolution des processus, et par
suite l’occurrence des événements, en fonction de l’histoire passée de l’ensemble des
processus.
- Considérons des systèmes où l’on peut faire abstraction de la durée des intervalles de
temps entre 2 événements. Chaque processus est représenté par une succession
d’événements et la synchronisation dite logique consiste à mettre en concordance
plusieurs processus ayant atteint chacun un événement donné.
- Cette mise en concordance est ponctuelle, les processus reprennent leur liberté
jusqu’au prochain point de synchronisation.
- Parmi les systèmes où la synchronisation logique s’applique, ceux qui nous intéressent
le plus sont ceux pour lesquels il n’est pas nécessaire de se souvenir de toute l’histoire
passée. Seul un résumé de caractéristiques significatives des événements est conservé.
3.4) Exemple :
- 1 piscine peut accueillir un nombre limité de nageurs. Cette limite est représentée par le
nombre P de paniers disponibles pour les habits des nageurs. De plus, à l’entrée comme à
la sortie de la piscine, les nageurs rentrent en compétition pour l’acquisition d’une des C
cabines d’habillage ou de déshabillage  1<C << P.
- Chaque baigneur est un processus, les cabines et les paniers sont objets de compétition.

4
- Représentation d’1 processus :
 1 processus représente l’évolution du nageur dans le système considéré, soit :

début
se déshabiller ;
se baigner ;
s’habiller
fin

 En termes informatiques, on dirait que se déshabiller et s’habiller sont des

procédures et qu’elles se partagent (ou sont en concurrence pour) l’accès à des
ressources communes.
 Dans le système regroupant l’ensemble des nageurs, on va observer les événements
suivants pour chaque processus :

autorisation de déshabillage, fin de déshabillage, autorisation d’habillage, fin

d’habillage

qui sont seuls significatifs par rapport au problème posé  C’est lors de ces
événements que l’état des ressources est modifié.

 L’action se déshabiller est située entre les événements autorisation de

déshabillage et fin de déshabillage et suppose disponible un panier et une cabine.
De même pour l’action s’habiller qui est placée entre autorisation d’habillage et
fin habillage.

- Expression de synchronisation :

 Pour exprimer des contraintes de synchronisation, on va chercher à représenter

l’état du système tel qu’il est observable.
 Le nombre de cabines occupées est égal à tout instant à la somme des gens en cours
de déshabillage et des gens en cours d’habillage, soit :

nombre de cabines occupées = nombre de déshabillage + nombre d’habillage

 Le nombre de gens en cours de déshabillage peut s’exprimer en fonction du

nombre d’événements autorisation de déshabillage et fin de déshabillage :

nombre de déshabillage = nombre d’autorisations de déshabillage – nombre de fin de déshabillage

De façon générale, quelle que soit l’action X, le nombre d’actions X en cours, est
donné par la relation :

nombre d’actions X en cours = nombre d’autorisations de X – nombre de fins de X

 Quant au nombre de paniers occupés, il est égal au nombre de gens dans la piscine
(en cabine, dans le bain), soit :

Nombre de paniers occupés = nombre d’autorisations de déshabillage – nombre de fins d’habillage

5
  Le système considéré doit obéir aux contraintes suivantes (l’invariant du
problème) :

Nombre de cabines occupées <= C

L’expression invariante
Nombre de paniers occupés <= P
 En ce qui concerne la 1 inégalité :
ère

 Cet invariant peut être mis en défaut à chaque nouvel événement autorisation. Ce
sont ces événements là que l’observateur (= le synchroniseur = contrôleur) doit
contrôler, se contentant par contre d’enregistrer les autres :

Condition pour autoriser (déshabillage) :

nombre de déshabillage + nombre d’habillage < C
et (expression conditionnelle)
nombre d’autorisation de déshabillage –nombre de fins d’habillage < P

Condition pour autoriser (habillage) :

nombre de déshabillage + nombre d’habillage < C

 Le rôle du contrôleur est ainsi mis en évidence : il enregistre et compte certains

événements. Pour d’autres, il intervient et retarde leur occurrence jusqu’à ce qu’un
événement donné le permette.
 L’expression conditionnelle est équivalente à l’expression invariante.

- Mise en œuvre :
C’est construire un mécanisme opératoire qu’on essaie de prouver conforme à la
spécification.
MEO centralisée =

(Schéma)

Le contrôleur est un observateur unique qui perçoit tous les évènements significatifs.
On peut utiliser soit 4 compteurs correspondants aux comptes d’événements répertoriés
(autorisation de déshabillage, fin de déshabillage, aut. d’hab., fin d’hab.) soit 2
compteurs nbre de cabines occupées et nbre de paniers occupes.
Le contrôleur peut être explicité comme un processus unique, comme un moniteur ou bien
être implicite. Dans ce cas, les compteurs sont des variables partagées que chaque
processus contrôle et MAJ en exclusion mutuelle (en utilisant les sémaphores, …).
Quelle que soit la solution retenue, son utilisation nécessite l’existence d’un
mécanisme d’exclusion mutuelle si l’on doit pouvoir exprimer n’importe quel
problème de synchronisation.

6
 4) Systèmes de tâches, outils d’expressions
4.1) Modèles de représentation des processus
a) Processus séquentiels
Tâche : unité élémentaire de traitement ayant une cohérence logique.
Processus P : on écrit P=T1....Tn.

di

Ti

Fi
(d : début, f : fin)

Suite de tâches T1, T2, ..., Tn est associé à une suite d1f1d2f2....dnfn d1f1d2f2....dnfn est
appelé mot de l'alphabet A={d1,f1,...,dn,fn}.

b) Systèmes de tâches & graphe de précédence

On définit une relation de précédence sur l’ensemble E des tâches notée < :
i) ∀ T ∈ E, on n'a pas T<T
ii) ∀ T, T’ ∈ ExE, on n'a pas simultanément T<T' et T'<T

iii) < est transitive.

7
 Soit un système de tâches S=(E, <), on interprète la relation < comme suit : T<T'
<=> terminaison de T nécessairement avant début de T'. Ainsi, si on a ni T<T' ni
T'<T on dira que les tâches sont exécutables en parallèle.
Le graphe de précédence est une représentation graphique de la relation ->.
Le langage d'un système de tâche est défini comme l'ensemble des mots qui satisfont
les contraintes du graphe de précédence.

Soient deux systèmes de tâche G1 et G2. On définit le produit de G1 et de G2 en ajoutant

au graphe des arêtes joignant chaque sommet terminal de G1 à chaque sommet initial de
G2.

4.2) Constructeurs de bases pour la synchronisation

* Graphe des processus (= graphe de précédence)  Voir TD : Ces graphes

restent non utilisables en programmation  Des langages de programmation ont
été mis en œuvre, munis d’outils de spécification du parallélisme.

a) Les instructions ParBegin / ParEnd

Fonctionnement du constructeur = Les blocs compris entre ParBegin et ParEnd sont
exécutés en parallèle et l’exécution est reprise en séquence quand le dernier des
blocs a fini.
Syntaxe :
PARBEGIN
I1 ;
I2 ;
.
.
In
PAREND
// Les instructions Ij (j=1,n) peuvent s’exécuter en parallèle.

8
Exemple :

début début
lire(a) ; PARBEGIN
lire(b) ; lire(a) ;
ca+b; lire(b) ;
écrire(c) ; PAREND
fin ca+b;
écrire(c) ;
fin

b) Les instructions Fork & Join

 Ces 2 opérateurs ont été introduits pour la spécification des activités

parallèles.
 L’instruction Fork Etiq est 1 instruction de contrôle du parallélisme qui
fonctionne comme 1 branchement où on prend les 2 branches à la fois.
 Lorsqu’on rencontre cette instruction, on lance le morceau de code qui
commence à l’@ spécifiée par l’étiquette Etiq de l’instruction Fork et on
continue en séquence  On obtient ainsi 2 processus qui travaillent en
parallèle.
 Exemple :
Graphe de précédence
I1 ;
Fork Etiq ; I1
I2 ;
.
. Fork
.
Etiq : I3 ;
I2 I3

 L’instruction Join N permet de joindre (càd combiner) N activités parallèles

en 1 seule. Les (N-1) 1ères activités qui exécutent l’instruction Join N se
terminent, tandis que la Nième continuera en séquence.

9
  Exemple : (du 6.1)

début début
lire(a) ; n=2;
lire(b) ; Fork I1 ;
ca+b; lire(a) ;
écrire(c) ; Goto I2 ;
fin I1 : lire(b) ;
I2 : Join n ;
Ca+b;
Ecrire(c) ;
fin

 Remarque : - Le constructeur ParBegin / ParEnd est plus structuré que le

constructeur Fork & Join. – Cependant, le Fork & Join présente 1 outil de
spécification plus puissant  Il permet de réaliser des graphes parallèles
plus puissants que le ParBegin / ParEnd.

10