Skip to topic | Skip to bottom
Home
Minfo05
Minfo05.TpAsySeance7r1.3 - 29 Mar 2009 - 22:03 - OlivierDalletopic end

Start of topic | Skip to actions

Approfondissement Système - TP7

FIFO Synchrone

L'objectif de l'exercice est d'écrire un pilote pour un pseudo-périphérique caractère qui implémente un FIFO synchrone, autrement dit fonctionnant selon le principe du producteur/consommateur, sans bufferisation.

Voici de façon pus précise les spécifications de cette nouvelle FIFO :

  • Il faut que 2 processus soient en même temps en train de faire une lecture et une écriture pour que le transfert des données puisse fonctionner.
  • Comme il n'est pas possible de faire en sorte que deux processus lancent ces deux opérations exactement au même moment, il faut les synchroniser: le processus qui déclenche son opération de lecture ou écriture le premier doit être endormi en attendant qu'un second processus réalise l'opération inverse.
    • Lorsque le second processus réalise l'opération inverse, il doit réveiller le premier, qui était endormi en l'attendant.
    • Pour endormir un processus, vous utiliserez le mécanisme des wait_queue qui vous été présenté en cours.
  • Vous choisirez un mode d'endormissement interruptible :
    • Attention, cela signifie que lorsque le processus se réveille deux situations sont possibles :
      • Soit le processus est réveillé normalement par le second processus qui vient d'arriver
      • Soit le processus est réveillé à cause d'une interruption. Dans ce cas, son appel doit se terminer avec une erreur -EINTR.
  • Transfert des données :
    • Il y a quand même besoin de bufferiser temporairement les données:
      1. Les données doivent être recopiées depuis l'espace mémoire du processus écrivain vers une zone mémoire tampon du noyau
      2. Les données doivent être recopiées depuis la zone mémoire tampon vers l'espace mémoire du processus lecteur.
    • Pour simplifier le protocole de synchronisation, vous ferez en sorte que si le processus écrivain est le premier à réaliser son opération, alors il n'attend pas l'arrivée du lecteur pour copier les données dans la zone tampon. en revanche, il doit forcément attendre l'arrivée du lecteur (autrement dit s'endormir) une fois qu'il a terminé le transfert vers la zone tampon.
    • Le transfert ne retournera au lecteur que le minimum entre la quantité de données lues et la quantité de données écrites
  • Attention à ne pas vous tromper de processus : si ce sont deux lecteurs qui arrivent au rendez-vous, alors le second ne doit pas réveiller le premier. Seul un redacteur doit réveiller un lecteur (et vice-versa). Pour simplifier les choses au début, vous pouvez interdire une deuxième opération du même type quand une première est déjà en cours (retourner directement une erreur au second).
  • Tests. Pensez à vérifier les différents cas de figure:
    • Un lecteur arrive le premier
    • Un rédacteur arrive le premier
    • Le lecteur et le rédacteur ne lisent pas la même quantité de données
    • Deux lecteurs au lieu d'un lecteur puis un rédacteur

Améliorations pour ceux qui ont déjà fini

Faites en sorte que votre pilote supporte plusieurs opérations du même type sans erreur. Par exemple, votre pilote doit être capable de supporter l'arrivée de 3 lecteurs, puis un rédacteur, puis un lecteur, puis puis deux rédacteurs, etc.

FIFO synchrone multiplexée

Le pilote que vous devez écrire est une évolution du précédent, qui corrige la chose suivante: quand un processus ouvre le pilote puis lit plusieurs fois des données dans le pilote, ce n'est pas forcément toujours le même processus qui lui fournira les données. En effet, dans la version précédente, ce sont les opérations qui sont couplées deux à deux , pas les processus.

Vous devez corriger cela en faisant en sorte qu'un processus lise toujours les données écrites par le même processus. Pour cela les processus devront être mis en binôme lorsqu'ils réaliseront leurs premières opérations de lecture ou d'écriture respectives. Vous devrez donc considérer plusieurs cas de figure :

  • Une opération (lecture ou écriture) est déclenchée par un processsus qui fait déjà partie d'un binôme constitué
    • Si le binôme est endormi, il faut le réveiller et réaliser le transfert puique le deux sont prêts
    • Si le binôme n'est pas encore endormi, il faut l'attendre (s'endormir)
  • Une opération (lecture ou écriture) est déclenchée par un processus qui ne fait pas déjà partie d'un binôme constitué. Il faut lui trouver un binôme:
    • Si un processus de l'autre type est déjà en attente d'un binôme, former le binôme et leur permettre de continuer leur première lecteure/écriture
    • Si aucun processus de l'autre type n'est déjà présent, il faut s'endormir en attendant qu'un binôme potentiel veuille bien arriver
  • Pour simplifier les choses, vous interdirez qu'un processus puisse ouvrir deux fois le fichier pilote. Vous devrez donc surcharger l'opération d'ouverture pour refuser l'ouverture par un processus qui fait soit déjà partie la liste des binômes constitués (ceux qui sont attente d'un binôme ne peuvent pas ouvrir le fichier une deuxième fois, puisqu'ils sont endormis !)
    • Ne faites pas plus de choses lors de l'ouverture, et en particulier ne partez surtout pas du principe qu'un processus doit forcément ouvrir le fichier: à la suite d'un fork() deux processus peuvent se trouver partager le même fichier ouvert, alors que le fichier n'a été ouvert qu'une fois. En revanche, vous pouvez supposer à raison que tous les processus devront forcément fermer le fichier.

Enfin, vous devrez faire en sorte que le binôme soit dissocié proprement quand l'un des deux processus ferme le fichier pilote. Ce qui implique que vous devrez surcharger l'opération de fermeture (close) pour savoir quand un binôme doit être rompu. Dans ce cas, deux cas de figures sont possibles :

  • Le premier à fermer le pilote est le processus écrivain. Tout va bien, il suffit de signaler une fin de fichier au processus lecteur.
  • Le premier à fermer le pilote est le processus lecteur. On se trouve dans ce cas avec problème puisque l'écrivain n'a plus de binôme pour lire ses données. Il faudra donc faire en sorte que la prochaine écriture (qui est peut-être déjà en attente) se termine par erreur (-EPIPE est approprié dans ce cas de figure).

-- OlivierDalle - 07 Nov 2005
to top


You are here: Minfo05 > ApprofondissementSysteme > TpAsySeance7

to top

Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding WIKIDeptinfo? Send feedback