Département INFormatique 
  CSC4508/M2 : Concepts des systèmes d'exploitation et mise en œuvre sous Unix


    Évaluation



TÉLÉCOM & Management SudParis
TÉLÉCOM SudParis 2ème année

TP Noté CSC4508/M2 du 23/06/09

(2è session)

Corrigés

Modalités

Durée : 1 heure 30

Tous documents autorisés.

La question 1 est indépendante des questions 2 et 3. La question 3 nécessite d'avoir lu la question 2, mais pas d'y avoir répondu. Aussi, n'hésitez pas à lire tout le sujet avant de commencer pour déterminer l'ordre dans lequel vous souhaitez traiter les questions.

Le barème est donné à titre indicatif des poids entre les différentes questions.

La « livraison » de votre travail en fin de TP noté se fera par remise de votre copie à l'enseignant et par remontée sous Moodle (rubrique « TP noté de 1 heure 30 ») du fichier d'extension tgz constitué de la manière suivante :
cd votreRepertoireDeTravailPourCSC4508M2
tar cvfz $USER.tgz TPNote2009Session2

Préparation

cd votreRepertoireDeTravailPourCSC4509M2
cp ~simatic/Cours/CSC4508/tPNote2009Session2.tgz .
tar xvfz tPNote2009Session2.tgz
cd TPNote2009Session2

Question 1 : Ubunthree (10 points)

Pour chacune des questions ci-dessous, répondez sur votre copie ou bien dans le fichier Q1/reponse1.txt (dans ce dernier cas, indiquez sur votre copie « Réponse dans Q1/reponse1.txt » ).

Le nouveau système d'exploitation "Ubunthree" ne dispose que de files de message pour les communications inter-processus (il n'offre donc pas de file de tubes, de sémaphore, de moniteur ou de mémoire partagée).
Parmi les paradigmes de synchronisation de processus suivants :
  1. Exclusion mutuelle
  2. Cohorte
  3. Passage de témoins : Envoi de signaux
  4. Producteurs/consommateurs
  5. Lecteurs/rédacteurs
Choisir 4 paradigmes qui vous semblent implémentables sous "Ubunthree" avec une seule file de message.
Expliquer, sur votre copie ou bien dans le fichier Q1/reponse1.txt (dans ce dernier cas, indiquez sur votre copie « Réponse dans Q1/reponse1.txt » ) feuille, l'implémentation envisagée (5 lignes maximum par paradigme retenu).

Question 2 : Utilisation d'une file de message dans un serveur multi-threadé (10 points)

Dans cet exercice, on considère le processus serveur étudié lors du TP noté du 19/05/2009.

On a donc un processus serveur contenant N+1 threads. L'un de ces threads, nommé distributeur, est chargé de recevoir les requêtes venant des différents clients et de communiquer ces requêtes vers l'un des N autres threads, nommés traiteurs. Ces derniers sont chargés d'effectuer le traitement de la requête et de répondre au client.
Pour simplifier l'exercice, on simule les processus clients de ce processus serveur : le thread distributeur est chargé de générer les requêtes (comme s'il les avait reçues des clients) à l'aide de la procédure simulerReceptionRequeteDeClient ; par ailleurs, dès qu'il reçoit une requête, chaque thread traiteur appelle simulerTraitementEtEnvoiReponseAuClient (qui simule notamment l'envoi du résultat du traitement de la requête au client).

Le médium de communication utilisé entre le thread distributeur et les threads traiteurs doit garantir que :
  1. aucune requête n'est perdue ;
  2. les threads traiteurs sont bloqués, en attente, quand aucune requête n'est disponible dans le médium ;
  3. le thread distributeur est bloqué, en attente, lorsque le médium est plein et ne peut donc pas recevoir une nouvelle requête.
Or, un tube est un médium de communication qui offre toutes ces garanties. C'est pourquoi, dans le code fourni en exemple, le thread distributeur communique les requêtes à traiter aux threads traiteurs via le tube distr_traite.

Avant de rentrer dans le vif du sujet, faites fonctionner ce serveur :
  • dans un terminal, positionnez-vous dans le répertoire Q2, tapez make pour compiler, puis serveur 20 pour lancer l'exécution du serveur ; le paramètre « 20 » indique le nombre de requêtes à traiter ; dans ce premier exemple, on met un nombre faible pour vérifier le bon fonctionnement en analysant visuellement la sortie ;
  • pour faire un test de performances, tapez /usr/bin/time serveur 100000 ; dans ce second exemple, on met un nombre important de requêtes à traiter pour avoir des chiffres de performance significatifs. Noter que le serveur ne fait plus aucun affichage à l'écran dès que le nombre de requêtes à traiter dépasse 100.
Pour fonctionner, ce serveur utilise 2 modules : codeEtudiant.c et simulateur.c. Mais, dans la question suivante, vous serez amené à modifier seulement codeEtudiant.c (c'est pourquoi c'est le seul module sur lequel vous avez les droits en écriture).

Dans cet exercice, on suppose qu'un profilage (profiling) a été effectué sur ce code. Il a révélé que le seul endroit où l'on peut gagner en performance au niveau de ce serveur est dans le médium de communication entre le thread distributeur et les threads traiteur. L'objectif de la question suivante est d'évaluer les performances d'une file de message IPC (et non Posix).

Modifiez Q2/codeEtudiant.c de sorte que :
  • le thread distributeur écrit ses requêtes en tant que messages dans une file de messages IPC (primitive msgsnd et non mq_send) qu'il a créée au moment de l'initialisation du programme ;
  • chaque thread traiteur lit un message sur cette file, puis appelle simulerTraitementEtEnvoiReponseAuClient avec la requête contenue dans ce message.
  • La file de message est supprimée, une fois que le programme a fini son exécution.
Une fois le code écrit et opérationnel, sur votre copie ou dans le fichier Q2/reponse2.txt, indiquez le résultat de votre test de performances. Commentez-le.

Page mise à jour le 23 juin 2009