GEF 435 Principes des systèmes dexploitation Communication Interprocessus (CIP) III (Tanenbaum 2.3)

Présentation au sujet: "GEF 435 Principes des systèmes dexploitation Communication Interprocessus (CIP) III (Tanenbaum 2.3)"— Transcription de la présentation:

1 GEF 435 Principes des systèmes dexploitation Communication Interprocessus (CIP) III (Tanenbaum 2.3)

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! up() et down() sont prône aux erreurs de programmation pourquoi? Exemple du producteur/consommateur:

5

6 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

7 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 concurrence critique parce que seulement un processus peut être actif à la fois dans un moniteur

8 Notez comment le processus qui signal sort du moniteur comme sa prochaine action. Parce quune seul procédure peut être active

9 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 appèle signal() Permettre le processus signaleur de finir et de sortir du moniteur: signal() attend

10 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

11 Passage de messages Utilise deux primitives de communication, send() et receive() Appèles de 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

12 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?

13 Passage de messages Considérations: Performance Envoyer des messages 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 doit bloquer jusquà ce que le processus qui reçoit soit prêt. Ceci permet la synchronisation de deux processus ce qui sappèle un rendez-vous

14 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

15

16 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

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

18 Quiz Time! Questions?