gef 435 principes des systèmes dexploitation communication interprocessus (cip) iii (tanenbaum 2.3)

18
GEF 435 Principes des systèmes d’exploitation Communication Interprocessus (CIP) III (Tanenbaum 2.3)

Upload: aime-flament

Post on 03-Apr-2015

111 views

Category:

Documents


0 download

TRANSCRIPT

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

GEF 435Principes des systèmes d’exploitation

Communication Interprocessus (CIP) III(Tanenbaum 2.3)

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

Revue

• Qu’est-ce que le problème du producteur/ consommateur?

• Comment est-ce que l’on 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?

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

Synopsis

• Trois concepts de plus pour la communication interprocessus:MoniteursPassage de Messages Barrières

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

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:

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

Moniteurs

• Un Moniteur est utilisé pour aider les programmeurs à créer des programmes qui sont correctesC’est 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 qu’un seul processus peut être actif à la fois dans le moniteur

• Avantage: Moins de potentiel pour l’erreur humaine• Désavantage: Doit être supporté par le compilateur

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

Moniteurs

• Cette solution nous permet d’avoir de l’exclusion 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

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

• Notez comment le processus qui signal sort du moniteur comme sa prochaine action.Parce qu’une seul procédure peut être active

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

Moniteurs

• Les signaux ne sont pas accumulés dans ce systèmewait() 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 à l’opération du moniteurAutrement deux processus pourraient être simultanément actifs

dans le moniteurAutres options:

• Suspendre le processus qui appèle signal()

• Permettre le processus signaleur de finir et de sortir du moniteur: signal() attend

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

Passage de messages

• Jusqu’à date les solutions à la concurrence critique ont pris pour acquis que l’information est accessible par la mémoire partagée

• Comment peut-on faire cela avec les applications distribuées?Passage de Messages

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

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 qu’un message

arrive ou retourner un code d’erreur (choix d’implémentation)• utilise t-on la temporisation (timeouts)?

• Considérations:Message perdu, Authentification, Performance, etAdressage

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

Passage de messages

• Considérations:Message perdu:

• Une confirmation est normalement requise

• Retransmit après une intervalle choisit

• Requiert des identificateurs de messages uniquesPourquoi?

Authentification• Comment est-ce que le client peut savoir qu’il communique

avec le vrai serveur?

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

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 d’information est-ce que l’on 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 s’appèle un rendez-vous

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

Passage de messages

• On revisite le producteur/consommateurAssumez que l’on a un système de messages contrôlé

par le SEAssumez que tout les messages ont la même grandeurAssumez 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 qu’un message arrive

• Notez que le consommateur commence en envoyant N messages vides au producteur

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

Barrières

• Les barrières sont un mécanisme de synchronisation pour aligner plusieurs processus à la fin d’une 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

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

Barrières

•Quel serait un bon exemple pour ce genre de synchronisation?

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

Quiz Time!

Questions?