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

Slides:



Advertisements
Présentations similaires
Module Systèmes d’exploitation
Advertisements

Module Systèmes d’exploitation
Module Systèmes d’exploitation
Module Systèmes d’exploitation
GEF 435 Principes des systèmes d’exploitation
GEF 435 Principes des systèmes dexploitation Le matériel des ordinateurs Revue Pt II (Tanenbaum 1.4)
GEF 435 Principes des systèmes dexploitation Structure du logiciel dE/S Partie II (Tanenbaum & 5.3.4)
GEF 435 Principes des systèmes dexploitation Principes et structure du logiciel dE/S (Tanenbaum 5.2 & 5.3)
GEF 435 Principes des systèmes dexploitation Les systèmes dexploitation en général (Tanenbaum 1.1 et 1.3)
Synchronisation de Processus
Synchronisation des processus père - fils
Module Systèmes dexploitation Chapitre 6 Communication Interprocessus Partie III École Normale Supérieure Tétouan Département Informatique
Systèmes en temps réel Modélisation du comportement en temps réel avec UML.
GEF 435 Principes des systèmes d’exploitation
GEF 435 Principes des systèmes dexploitation Ordonnancement partie I (Tanenbaum 2.5)
GEF 435 Principes des systèmes d’exploitation
GEF 435 Principes des systèmes d’exploitations
Systèmes en temps réel Services de Communication.
GEF 435 Principes des systèmes d’exploitation
Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage GEF 243B Programmation informatique appliquée Considération de temps.
GEF 435 Principes des systèmes dexploitation Communication Interprocessus (CIP) II (Tanenbaum 2.3)
GEF 243B Programmation informatique appliquée
GEF 435 Principes des systèmes d’exploitation
GEF 435 Principes des systèmes d’exploitation
GEF 435 Principes des systèmes dexploitation Structure des systèmes dexploitation (Tanenbaum 1.7)
GEF 435 Principes des systèmes d’exploitation
GEF 435 Principes des systèmes d’exploitation
GEF 435 Principes des systèmes d’exploitation
GEF 435 Principes des systèmes dexploitation Concepts des Systèmes dexploitation (Tanenbaum 1.5)
GEF 435 Principes des systèmes d’exploitation
Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage GEF 243B Programmation informatique appliquée Génie logiciel et Vérification et validation.
GEF 435 Principes des systèmes d’exploitation
GEF 435 Principes des systèmes dexploitation Appels de système (Tanenbaum 1.6)
Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage GEF 243B Programmation informatique appliquée Types, variables et constantes.
Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage GEF 243B Programmation informatique appliquée Génie logiciel avec composantes.
GEF 435 Principes des systèmes d’exploitation
GEF 435 Principes des systèmes d’exploitation
GEF 243B Programmation informatique appliquée
GEF 435 Principes des systèmes d’exploitation
GEF 243B Programmation informatique appliquée
Module 10 : Gestion et analyse de l'accès réseau
Module 2 : Allocation de l'adressage IP à l'aide du protocole DHCP
Exécutif Temps réel. Limitation des système classiques Rappels Mise en œuvre lourde des communications entre processus Problème de prédictibilité avec.
Parallel Programming in C with MPI and OpenMP
Rappel sur la synchronisation des processus
Démarche de résolution de problèmes
Concepts de base : la Classe Pour faire une comparaison simple, une classe serait a priori, une structure C avec des variables et des fonctions.
Synchronisation et communication entre processus
Système d’exploitation
EPID-CPI-ISAIP Philippe Bancquart - mise à jour 24/02/ page 1 Cours de CPI Philippe Bancquart CPI 2005.
Test et débogage Tests unitaires. Gestion d’erreurs. Notion d’état, de pré-condition et de post-condition. Assertion. Traces de programme. Débogueur et.
Module 51 Module 5 - Synchronisation de Processus (ou threads, ou fils ou tâches) Module 5 - Synchronisation de Processus (ou threads, ou fils ou tâches)
Programmation concurrente
Chapitre 6 (Silberchatz)
Revisé 2006 Modèle de performance dun serveur simple Nous supposons que le serveur traite une requête après lautre (sans parallisme) Modèle de files dattente.
Module 8 : Maintenance des logiciels à l'aide des services SUS
Chapitre 6 : Synchronisation des processus et des fils
Synchronisation Classique
Importance du réseau dans des architectures MIMD Tout échange entre les processeurs nécessite un transfert de données via le réseau.
1 Architecture orientée service SOA Architecture orientée service SOA (Service Oriented Architecture)
Module 8 : Surveillance des performances de SQL Server
NOTIONS DE BASE DES SYSTÈMES TEMPS-RÉEL Sujets Concepts de processus/thread concurrents –Windows NT et la programmation temps réel Lectures: Chapitres.
Interactions entre Processus
Le contenu est basé aux transparents du 7 ème édition de «Software Engineering» de Ian Sommerville«Software Engineering» de Ian Sommerville B.Shishedjiev.
Programmation Système et Réseau
Exemple de mise en oeuvre
SYSTEMES d’INFORMATION séance 1 : Introduction et définitions
Applications Internet Cours 3 21 janvier 2010 Cours 3 21 janvier 2010.
Architecture Client/Serveur
Systèmes d’exploitation Processus conclusion Modèle conceptuel de processus Pour masquer les effets des interruptions, les SE fournissent un modèle conceptuel.
Transcription de la présentation:

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

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?

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

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:

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

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

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

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

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

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

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?

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

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

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

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

Quiz Time! Questions?