Module Systèmes dexploitation Chapitre 6 Communication Interprocessus Partie III École Normale Supérieure Tétouan Département Informatique

2 Revue Quest-ce que le problème du producteur/ consommateur? Comment est-ce que lon peut le résoudre? Expliquez la différence entre les sémaphores full et empty Entre les mutex et les sémaphores qui comptent, lesquelles ont besoin de bloquer les interruptions? Pourquoi?

3 Synopsis Trois concepts de plus pour la communication interprocessus: –Moniteurs –Passage de Messages –Barrières

4 Moniteurs Est-ce que les sémaphores ont résolus tout les problèmes pour la CIP? –NON!

5 Moniteurs Un Moniteur est utilisé pour aider les programmeurs à créer des programmes qui sont correctes –Cest une collection de procédures, variables, et structures de données groupés ensemble (pensez: module, package, class, etc) –Les processus peuvent appeler des procédures dans le moniteur, mais le moniteur est compilé de tel façon à ce quun seul processus peut être actif à la fois dans le moniteur Avantage: Moins de potentiel pour lerreur humaine Désavantage: Doit être supporté par le compilateur

6 Moniteurs Cette solution nous permet davoir de lexclusion mutuelle, mais pas pour dormir/éveiller sur certaines conditions. Pour résoudre ce problème: on inclus une/des variable(s) de condition dans le moniteur. –Ceci ne crée pas de condition critique parce que seulement un processus peut être actif à la fois dans un moniteur

7 Moniteur file { Condition plein, vide; Int compteur = 0; … Procédue mettre (objet o) { If (compteur==N) wait(plein); Mettre_objet(o); Compteur ++; If (compteur ==1) siganl(vide); } Procédur retirer (objet o) { If (compteur==0) wait(vide); Retirer_objet(o); Compteur --; If (compteur ==(N-1)) siganl(plien); } } //fin du moniteur

8 Moniteurs Les signaux ne sont pas accumulés dans ce système –wait() doit arriver avant signal() –Pas difficile considérant que seul un processus à la fois doit être actif dans le moniteur Sortir du moniteur après un signal() est vital à lopération du moniteur –Autrement, deux processus pourraient être simultanément actifs dans le moniteur –Autres options: Suspendre le processus qui appelle signal() Permettre le processus signaleur de finir et de sortir du moniteur

9 Passage de messages Jusquà date les solutions à la concurrence critique ont pris pour acquis que linformation est accessible par la mémoire partagée Comment peut-on faire cela avec les applications distribuées? –Passage de Messages

10 Passage de messages Utilise deux primitives de communication, send() et receive() –Appels système (comme sémaphores), pas une structure de langage (comme moniteurs) –receive() peut ou bien bloquer jusquà ce quun message arrive ou retourner un code derreur (choix dimplémentation) utilise t-on la temporisation (timeouts)? Considérations: –Message perdu, –Authentification, –Performance, et –Adressage

11 Passage de messages Considérations: –Message perdu: Une confirmation est normalement requise Retransmit après une intervalle choisit Requiert des identificateurs de messages uniques –Pourquoi? –Authentification Comment est-ce que le client peut savoir quil communique avec le vrai serveur?

12 Passage de messages Considérations: –Performance Envoyer des message coûte plus en temps que la gérance des sémaphores ou moniteurs (sur une seule machine) Comment dinformation est-ce que lon peut passer? –Même machine/réseau –Adressage: Messages peuvent être adressés à un processus ou une structure de boîte à messages, qui peut entreposer les messages Si on a pas de boîte à messages, les messages peuvent être perdu donc le processus qui envoie se bloque jusquà ce que le processus qui reçoit soit prêt. Ceci permet la synchronisation de deux processus ce qui sappelle un rendez-vous

13 Passage de messages On revisite le producteur/consommateur –Assumez que lon a un système de messages contrôlé par le SE –Assumez que tout les messages ont la même grandeur –Assumez que le SE tamponne les messages envoyés et non reçus N messages pour cet exemple –Cette implémentation fait que le processus bloque sur un receive() jusquà ce quun message arrive Notez que le consommateur commence en envoyant N messages vides au producteur

14 #define N 100 Producteur() { Message m; While(1) { Produire_objet(o);//produire un objet Recevoir(consomateur,m);//attente un message vide (Jeton) Faire_message(m,o);//construire message à envoyer Envoyer(consommateur,m);//envoyer message au consommateur } Consommateur() { Int i; Message m; For (i=0; i<N; i++)//envoyer N Envoyer(producteur,m);//(jetons) message vides While(1) { Recevoir(producteur,m);//attendre un message Retirer_objet(m,o);//retirer lobjet du message Utiliser_objet(o);//utiliser lobjet Envoyer(producteur,m);//renvoyer une réponse vide }

15 Barrières Les barrières sont un mécanisme de synchronisation pour aligner plusieurs processus à la fin dune phase de travail avant de commencer une autre phase Les processus qui ont fini leurs travail appèlent une instruction primitive ou procédure de bibliothèque [disons barrier() ] pour bloquer jusquà ce que les autres processus aient finis leurs travail Une fois que tout les processus ont fini la phase, tout les processus sont relâchés pour continuer leurs travail dans la prochaine phase

16 Barrières Quel serait un bon exemple pour ce genre de synchronisation?

17 Quiz Time! Questions?