Vous êtes sur la page 1sur 11

Master 1 Informatique

Modles et Concepts du Paralllisme


ralllisme et de la Rpartition

Universit Toulouse III Paul Sabatier


118 route de Narbonne
31062 Toulouse cedex 9

Travaux dirigs n1 Rseaux de Petri


Quelques rappels
Un rseau de Petri
tri (RdP) est un moyen de :

modliser le comportement des systmes dynamiques vnements discrets ;

dcrire des relations existantes entre des conditions et des vnements.

Un RdP est un graphe orient compos de places et de transitions :

Une place est reprsente par un cercle ;

Une transition est reprsente par un trait ;

Un arc relie soit une place une transition, soit une transition une place.

Chaque place contient un nombre entier positif ou nul de jetons.


Une transition est arme (ou franchissable)
franchissable lorsque toutes les places qui sont en entre de cette
transition contiennent au moins le nombre de jetonss spcifi par le poids de larc dentre
correspondant. Le franchissement consiste alors retirer les jetons de chacune des places d'entre
et rajouter un ou plusieurs jetons
jeton chacune des places de sortie de la mme transition,
transition selon le
poids des arcs de sortie.

Remarques :

Ces deux actions se font simultanment ; le franchissement dune transition nest pas divisible.

On peut remarquer quil ny a pas conservation


co
du nombre de jetons.

Lorsquune transition est valide, cela nimplique pas quelle soit franchie immdiatement.
Cette validation nest quune possibilit de progression cet instant l.

Lorsque deux arcs sortent dune place et que les transitions


transitions correspondantes sont valides, le
choix de la transition qui sera franchie est arbitraire (indterminisme).

TD MCPR

Master 1 Informatique

Modles et Concepts du Paralllisme et de la Rpartition

Modlisation dune excution squentielle dactions


Produire la portion de RdP correspondant aux schmas dexcution suivants :

 Excution de trois actions A1, A2 et A3 en squence.


 N rptitions dune squence de deux actions A1 et A2.
Modlisation du paralllisme
Produire le RdP correspondant au schma dexcution suivant :

 Lancement de deux squences dactions (A1, A2, A3) et (B1 et B2) en parallle puis attente de
leurs terminaisons.
Modlisation dune activit
Produire le RdP correspondant une activit ralisant la rception dun message partir du rseau
puis son traitement par deux tches en parallle.

La premire tche est constitue de la squence : A1 et A2 ;

La seconde tche est constitue de la squence : B1 et B2.

Les contraintes suivantes doivent tre respectes :

Laction B2 ne peut pas commencer avant la fin de laction A1.

Un nouveau message ne peut pas tre admis tant quil y a un traitement en cours (session en
cours).

Modlisation dun affichage concurrent


On considre une premire activit ralisant un cycle infini constitu de la squence : T1, A1, A2, T2
et une seconde activit qui ralise un cycle infini constitu de la squence : T3, A3, A4, T4 o
laction Ti consiste effectuer un certain traitement et laction Ai afficher une portion de message
lcran.

 Produire le RdP permettant ces deux activits dafficher respectivement le message produit
par (A1, A2) et le message produit par (A3, A4).

 Produire le RdP permettant ces deux activits dafficher les messages produits par (A1, A2) et
par (A3, A4) de manire alterne lcran.

TD MCPR

Master 1 Informatique

Modles et Concepts du Paralllisme et de la Rpartition

Travaux dirigs n2 Smaphores


Quelques rappels
Un smaphore S encapsule une variable entire non ngative et une file dattente. Un smaphore S
est muni de 3 oprations que peuvent utiliser des processus :
init(S, n)

Initialise la valeur de la variable de S au nombre n donn

P(S)

Si la valeur de la variable de S est nulle alors


bloque le processus dans la file dattente associe S ;
Dcrmente la valeur de la variable de S de 1

V(S)

Incrmente la valeur de la variable de S de 1 ;


Si des processus sont en attente alors
rveille le premier processus de la file dattente associe S

On peut considrer de manire plus intuitive un smaphore comme une corbeille dans laquelle
seraient placs des jetons.
Pour tre autoris poursuivre, un processus utilise lopration P ( - Puis-je ? ) qui tenterait de
retirer un jeton dans la corbeille condition quil y ait des jetons prsents. Un processus peut
dposer un jeton dans la corbeille ou bien le transmettre un processus qui attendrait un tel jeton
par lopration V ( - Vas-y ).
Exercice 1 Alternance daffichage
Un processus Afficheur possde le comportement suivant :
Processus Afficheur {
while (1) {
Effectuer un traitement ;
Afficher un message lcran ;
Effectuer un traitement ;
}
}

 Proposer une solution utilisant des smaphores pour synchroniser laffichage altern lcran
de deux processus Afficheur. Ce problme a t modlis par un rseau de Petri lors du TD
prcdent.

 Comment faut-il modifier la solution prcdente pour gnraliser le problme N processus


Afficheur ?
Exercice 2 Gestion de ressources : Modle des producteurs/consommateurs
On se propose dtudier plusieurs variantes du modle des producteurs/consommateurs prsent
en cours. Dans ces variantes, on suppose que plusieurs processus producteurs et plusieurs
processus consommateurs coexistent et veulent accder un tampon, partag, de N cases, gres
de manire circulaire, pour y dposer ou retirer un message.
Le rseau de Petri ci-aprs modlise la variante de base tudie en cours :

TD MCPR

Master 1 Informatique

Modles et Concepts du Paralllisme


ralllisme et de la Rpartition

Dans un but de rutilisation, commencer par crire les oprations permettant linsertion et
lextraction proprement dites dun message dans le tampon.
Variante 1
Dans la premire variante tudie, les messages peuvent tre de deux types
types diffrents (exemples :
blanc/noir ou recto/verso).
Les producteurs sont diffrencis par le type du message quils dposent dans le tampon. Les
demandes des producteurs sont traites dans lordre de leur arrive mais on dsire que les dpts
dans le tampon
ampon se fassent de manire alterne selon le type des messages dposs.
Les consommateurs retirent les messages dans lordre des messages dposs.

 Proposer une solution utilisant des smaphores pour que ces processus dposent et retirent
leurs messages dee manire cohrente.
Variante 2
Dans cette variante, deux types de messages existent toujours.
Les producteurs sont diffrencis par le type des messages quils dposent dans le tampon.
Contrairement la variante prcdente, les dpts dans le tampon se font dans lordre des
arrives, quel que soit le type du message dpos.
En revanche, les consommateurs prcisent quel type de message ils dsirent retirer. Les messages
sont toujours retirs dans lordre des dpts et les demandes des consommateurs sont traites
dans lordre de leur arrive.

TD MCPR

Master 1 Informatique

Modles et Concepts du Paralllisme et de la Rpartition

Travaux dirigs n3 Smaphores


Gestion dune voie unique
On considre des vhicules circulant sur des voies parallles, mais avec parfois des tronons voie
unique. Bien entendu, il ne peut y avoir deux vhicules circulant en sens inverse sur une telle voie
unique.
Le comportement dun vhicule, circulant sur ces voies et caractris par son sens de dplacement
(vers lest ou louest), est le suivant :
Processus Vehicule (monSens) {
. . . . .
Circuler sur la voie double sens ;
/* Demander sengager sur la voie unique (dans un certain sens) */
DemanderAccesVU(monSens) ;
Rouler sur la voie unique ;
/* Quitter la voie unique */
LibererAccesVU() ;
Continuer circuler sur le voie double sens ;
}

Plusieurs variantes sont envisageables pour synchroniser laccs la voie unique.


Variante 1
Il ne peut y avoir quun seul vhicule sur la voie unique.
Variante 2
Le nombre de vhicules un instant donn sur la voie unique est illimit.
Variante 3
Le nombre de vhicules un instant donn sur la voie unique est limit MAX.

 Pour chacune de ces variantes, proposer une solution utilisant des smaphores pour
synchroniser laccs cette voie unique (cela revient crire DemanderAccesVU(monSens) et
LibererAccesVU()).

TD MCPR

Master 1 Informatique

Modles et Concepts du Paralllisme et de la Rpartition

Travaux dirigs n4 Moniteurs de Hoare


Le modle des producteurs-consommateurs
On considre nouveau le modle des producteurs-consommateurs mais on souhaite raliser la
synchronisation ncessaire grce un moniteur de Hoare.
Dans ce modle de synchronisation, deux familles de processus accdent un buffer partag pour y
dposer (processus Producteurs) ou retirer des messages (processus Consommateurs). Le buffer est
gr de manire circulaire. Les retraits seffectuent dans lordre des dpts.
Le comportement de ces processus est donc le suivant :
Un producteur :
Dbut
...
Dposer un message dans le buffer
( la suite de ceux qui sy trouvent dj);
...
Fin;

Un consommateur :
Dbut
...
Retirer le message du buffer (le plus ancien);
...
Fin;

On se propose d'crire un moniteur de Hoare grant l'accs la ressource commune selon la


politique dfinie prcdemment et selon les diffrentes variantes suivantes.
La spcification du moniteur se prsente de la manire suivante:
Moniteur Prod_Conso {
void Deposer(. . . );
void Retirer(. . . );
end Prod_Conso ;

TD MCPR

Master 1 Informatique

Modles et Concepts du Paralllisme et de la Rpartition

Variante 1 Buffer de N cases, messages dun type unique


Cest la variante de base, dans laquelle la capacit du buffer est de N messages et la politique
applique est celle dcrite plus haut.
Variante 2 Message de deux types, dpts alterns
Dans cette variante, les messages considrs peuvent tre de deux types (par exemple, noir/blanc
ou recto/verso). Un producteur dpose des messages dun certain type. Les dpts des messages
se font de manire alterne. Les retraits se font selon la mme politique que prcdemment.
Variante 3 Messages de deux types, choix du type de message retir
Dans cette variante, on a toujours des producteurs de deux types mais les dpts ne sont plus
forcment alterns. On a aussi des consommateurs de deux types et un consommateur spcifie le
type du message quil dsire retirer. Les retraits se font toujours dans lordre des dpts.
Questions
Pour chacune des variantes :

 Donner la spcification du moniteur.


 Prciser les conditions de blocage et de rveil d'un processus producteur et d'un processus
consommateur.

 En dduire les variables d'tat et les variables condition gres dans le moniteur.
 Donner le code du moniteur.

TD MCPR

Master 1 Informatique

Modles et Concepts du Paralllisme et de la Rpartition

Travaux dirigs n5 Moniteurs de Hoare


Le modle des lecteurs-rdacteurs
Le modle des lecteurs-rdacteurs schmatise une situation rencontre dans la gestion de fichiers
partageables ou dans l'accs des bases de donnes.
Deux familles de processus accdent ces informations. Les lecteurs dsirent seulement consulter
l'information. Les rdacteurs dsirent modifier cette information. Les lecteurs peuvent donc
accder l'information en parallle alors que les rdacteurs doivent y accder en exclusion
mutuelle.
Les comportements de ces processus sont donc les suivants :
Un lecteur:
Dbut
...
Demander lire;
Faire la lecture;
Signaler la fin de lecture;
...
Fin;

Un rdacteur:
Dbut
...
Demander crire;
Faire la modification;
Signaler la fin d'criture;
...
Fin;

On se propose d'crire un moniteur de Hoare grant l'accs la ressource commune selon la


politique dfinie prcdemment et selon les diffrentes variantes suivantes.
La spcification du moniteur se prsente de la manire suivante:
Moniteur Lecteur_Redacteur {
void Debut_Lire();
void Fin_Lire();
void Debut_Ecrire();
void Fin_Ecrire();
end Lecteur_Redacteur ;

Master 1 Informatique

Modles et Concepts du Paralllisme et de la Rpartition

Variante 1
Quand aucun lecteur ne lit, les lecteurs et les rdacteurs ont la mme priorit. En revanche, ds
qu'un lecteur est en train de lire, tous les autres lecteurs qui le demandent peuvent galement lire
puisque les lectures peuvent tre faites en parallle, quel que soit le nombre de rdacteurs en
attente.
Lorsqu'un rdacteur crit, aucun autre client ne peut accder la ressource (ni lecteur, ni
rdacteur).
Lorsque le rdacteur a termin d'crire, il essaye d'activer un rdacteur en priorit sur les lecteurs.
Variante 2 - Priorit des rdacteurs sur les lecteurs
On souhaite donner la priorit aux rdacteurs afin que linformation disponible ne soit pas obsolte
pour le lecteur. Lorsqu'un rdacteur demande accder la ressource, il doit donc l'obtenir le plus
tt possible. Bien sr, il ne lui est pas possible dinterrompre des lectures ou une criture en cours.
De mme, il na pas de passe-droit vis--vis dautres rdacteurs en attente (arrivs avant lui et non
encore accepts). En revanche, il est prioritaire par rapport aux lecteurs en attente.
Variante 3 - Gestion plus quitable des accs
quelles situations errones peuvent conduire les variantes 1 et 2 ?
Quelle solution proposer pour corriger de telles situations ?
Dans cette variante, un rdacteur qui termine dcrire doit laisser l'accs en priorit tous les
lecteurs en attente cet instant, et non au rdacteur suivant comme il est spcifi dans la variante
1. En revanche, les lecteurs qui arriveront ultrieurement (aprs cette demande dcriture) devront
respecter la rgle de priorit des rdacteurs sur les lecteurs telle quelle est exprime dans la
variante 2.
Variante 4 - Gestion FIFO des accs
On suppose maintenant que l'accs aux donnes est effectu suivant une politique FIFO ; les
requtes sont traites dans l'ordre de leurs arrives.
Pour ordonner globalement les lecteurs et les rdacteurs en attente, tous les processus seront
bloqus sur une mme condition. En effet, il nest pas possible de savoir si le 3e rdacteur est arriv
avant ou aprs le 4e lecteur lorsque lecteurs et rdacteurs sont rangs dans des files distinctes. On
notera que, lors du rveil, il n'est pas possible (pour le signaleur ) de distinguer un lecteur d'un
rdacteur. Aussi, on peut tre amen rveiller un processus (lecteur ou rdacteur), puis le
rebloquer par la suite si le dblocage s'avre impossible dans la situation actuelle.
Questions
Pour chacune des variantes :

 Donner la spcification du moniteur.


 Prciser les conditions de blocage et de rveil d'un processus lecteur et d'un processus
rdacteur.

 En dduire les variables d'tat et les variables condition gres dans le moniteur.
 Donner le code du moniteur.
9

Master 1 Informatique

Modles et Concepts du Paralllisme et de la Rpartition

Travaux dirigs n6 Moniteurs de Hoare


Traitement de commandes
A loccasion des ftes de Nol, votre magasin prfr a dcid de mettre la disposition de ses
fidles clients, un certain nombre (NB_GUICHETS) de guichets spciaux pour prendre en charge
leurs commandes. Le principe de fonctionnement de ces guichets est le suivant :

Un client attend un guichet libre, y dpose sa commande, puis attend que celle-ci soit prte.

Le traitement dune commande comporte un certain nombre (NB_ETAPES) dtapes successives


et des employs spcialiss sont affects chacune de ces tapes. Ltape i du traitement
dune commande ne peut dbuter que lorsque lemploy charg de ltape prcdente (i-1) a
termin sa tche.

Lorsque sa commande a t traite, le client quitte le guichet, pleinement satisfait de ce


nouveau service.

Par exemple, en pratique, le magasin met trois guichets disposition de ses clients et le traitement
dune commande consiste en quatre tapes : (1) tablir la liste des articles commands, (2) aller
chercher les articles commands, (3) les emballer avec du papier cadeau et (4) faire payer le client.
Problme
On considre deux types de processus : Client et Employe.

Un processus Client dpose une commande un guichet libre et attend que cette commande
soit traite avant de quitter ce guichet. Au plus NB_GUICHETS commandes peuvent tre traites
en parallle.

Un processus Employ, spcialis dans ltape i, prend en charge la premire commande en


attente de cette tape, accomplit sa part de travail avant de rapporter la commande traite
son guichet dorigine. Il peut alors prendre en charge une nouvelle commande. Lorsque la
dernire tape a t excute sur une commande, le processus Client ayant formul cette
commande peut reprendre son excution.

On suppose dfinis les types :

NumeroEtape : qui dsigne un entier compris entre 0 et NB_ETAPES

NumeroGuichet : qui dsigne un entier compris entre 1 et NB_GUICHETS

Commande : qui dsigne la commande tablie par un client

On suppose aussi donn, le sous-programme :

void appliquerEtape (NumeroEtape numEtape, Commande *uneCommande) ;

qui peut tre utilis par un processus Employe afin daccomplir sa part de travail (i.e. ltape
numEtape) sur une commande donne et ainsi lui apporter une modification.
On se propose de synchroniser, en utilisant un moniteur de Hoare nomm GestionRequetes, des
processus Client et des processus Employ pour que les commandes soient traites le plus
efficacement possible.

10

Master 1 Informatique

Modles et Concepts du Paralllisme et de la Rpartition

La spcification de ce moniteur est la suivante :


Moniteur GestionRequetes {
void commander (void) ;

// Utilis par un Client


// Utiliss par un Employe

void commencerEtape (NumeroEtape etape, Commande *cmde, NumeroGuichet *guichet) ;


void terminerEtape (Commande cmde, NumeroGuichet guichet) ;
}
Le comportement des processus Client et Employe est donc le suivant :
Processus Client {

Processus Employe (NumeroEtape etapeAppliquee) {

// Se rendre au magasin

while (1) {

GestionRequetes.commander() ;

GestionRequetes.commencerEtape(etapeAppliquee,
&cmdeATraiter, &guichetOrigine) ;

// Rentrer chez soi, satisfait

appliquerEtape(etapeAppliquee, cmdeATraiter) ;

GestionRequetes.terminerEtape(cmdeATraiter,
guichetOrigine) ;
}
}
Questions

 Prciser les conditions de blocage et de rveil d'un processus Client et d'un processus Employe.
 En dduire les variables d'tat et les variables condition gres dans le moniteur.
 Donner le code du moniteur.

11