*** empty log message ***
This commit is contained in:
glenux
parent
3e4c8e432c
commit
d38314b67e
2 changed files with 86 additions and 65 deletions
|
|
@ -1,12 +1,16 @@
|
|||
\chapter{A venir}
|
||||
\chapter{Conclusion}
|
||||
|
||||
\par Bien que nous ayons fini le projet, il se peut qu'il ne soit pas
|
||||
sans défauts. C'est pourquoi dans l'avenir, il faudrai corriger les
|
||||
bogues éventuels que tous nos tests n'auraient pas fait appara{\^i}tre.
|
||||
Mais il n'y a pas que cela; le ``code'' pourrai {\^e}tre amélioré et
|
||||
allégé. Nous pourrions également faire plus ``subtil'' par endroits.
|
||||
Nous devrions aussi vérifier tous les codes d'erreurs renvoyés par les
|
||||
fonctions après leur appel. Il serai également possible de faire en sorte
|
||||
d'utiliser moins de mémoire en réduisant le nombre de {\em shm}; pour
|
||||
cela il faudrai changer de structure de donnée. Nous aimerions également
|
||||
finir l'outil d'analyse {\em msgSpaceState} des {\em msgSpace}.
|
||||
\par Nous avons fini le projet, mais il n'est certainement pas exempt
|
||||
de bugs et d'autres défauts.
|
||||
C'est pourquoi dans l'avenir, il faudrai corriger les bogues éventuels que
|
||||
tous nos tests n'auraient pas fait appara{\^i}tre. Le ``code'' lui-même pourrait {\^e}tre grandement amélioré et allégé car des choses plus ``subtiles'' auraient pu être écrite à certains endroits (nécessitant malheureusement un peu plus de temps).
|
||||
|
||||
\par De même la gestion des codes d'erreurs renvoyés par les fonctions pourrait être améliorée et la facilité de débuggage augmentée.
|
||||
|
||||
\par Il serait également possible de faire en sorte d'utiliser moins de
|
||||
mémoire en réduisant le nombre de segment de mémoire partagée, mais pour
|
||||
cela il faudrai changer de structures de données.
|
||||
|
||||
\par De plus nous aimerions (d'ici la soutenance) rendre les outils de test et d'analyse des espaces de messages plus complet.
|
||||
|
||||
\par Enfin nous tenons à remercier M. Rifflet pour le cours (et son livre) ainsi que M. Bertier pour leurs nombreuses explications (si précieuses) qu'ils nous tout deux apportés.
|
||||
|
|
|
|||
|
|
@ -5,7 +5,9 @@
|
|||
\subsection{Travail collaboratif}
|
||||
|
||||
\par Nous avons travaillé ensemble gr{\^a}ce à CVS (Concurrent Versions System). Notre projet est hébergé chez Sourceforge\footnote{\url{http://www.sourceforge.net}}.
|
||||
Le CVS permet la modification du code du projet en m{\^e}me temps par plusieurs personnes. Les modifications et les mises à jour de chacun des membres du projet sont diffusées instantanément, avec un risque minimisé de conflits lors des modifications du m{\^e}me code.
|
||||
Le CVS permet la modification du code du projet en m{\^e}me temps par plusieurs
|
||||
personnes. Les modifications et les mises à jour de chacun des membres du projet peuvent
|
||||
ainsi être diffusées instantanément, avec un risque minimisé de conflits lors des modifications du m{\^e}me code.
|
||||
|
||||
|
||||
\subsection{Moyens techniques}
|
||||
|
|
@ -13,10 +15,8 @@ Le CVS permet la modification du code du projet en m{\^e}me temps par plusieurs
|
|||
\par Chacun selon nos préférences, nous avons utilisés des machines sous GNU/Linux ou Microsoft Windows et codé avec Vim.
|
||||
La personne sous Microsoft Windows avait une session graphique sur un serveur GNU/Linux, appartenant a un autre membre du projet,
|
||||
gr{\^a}ce à l'utilisation de VNC\footnote{\url{http://www.realvnc.com}} (Virtual Network Computing).
|
||||
Cela afin de permettre à l'utilisateur de Microsoft Windows de pouvoir
|
||||
tester la bibliothèque dans les meilleures conditions, car sous
|
||||
Microsoft Windows l'utilisateur n'est pas prévenu des
|
||||
{\em segmentation fault} et autres erreurs système.
|
||||
Cela afin de permettre à l'utilisateur de Microsoft Windows de pouvoir compiler et tester
|
||||
la bibliothèque dans de meilleurs conditions que sous son système initial\ldots
|
||||
|
||||
|
||||
\section{Programmation}
|
||||
|
|
@ -28,48 +28,63 @@ utilis
|
|||
des fonctions dans le fichier \\``\verb+/src/proto.h+'', avec en
|
||||
commentaire le fichier d'où il est issu. Par contre pour les fonctions
|
||||
qui génèrent les {\em ids}, leur prototype est dans le fichier ``\verb+/src/ids.h+'', généré par ``\verb+/src/ids.c+''.
|
||||
Le fichier ``\verb+/src/proto.h+'' est connu des logiciels qui utilisent
|
||||
|
||||
\par Le fichier ``\verb+/src/proto.h+'' est connu des logiciels qui utilisent
|
||||
notre bibliothèque, tandis que ``\verb+/src/ids.h+'' non.
|
||||
Nous allons donc vous décrire nos différentes fonctions en les classant
|
||||
par famille.
|
||||
\newline
|
||||
|
||||
\par Nous avons quatre grandes {\em familles} de fonctions.
|
||||
|
||||
\begin{description}
|
||||
\item{\sc msgBuffer*} Ce sont toutes les fonctions qui concernent les
|
||||
buffers : comment on les créés, les ``attachent'' aux processus.
|
||||
\item{\sc msgPool*} Ce sont les fonctions qui permettent de créer ou de
|
||||
\item[msgBuffer*]{Ce sont toutes les fonctions qui concernent les
|
||||
buffers : création, attachement aux processus\ldots}
|
||||
|
||||
\item[msgPool*]{Ce sont les fonctions qui permettent de créer ou de
|
||||
détruire une {\em pool}, de l'ouvrir ou encore de poser un ``verrou''.
|
||||
\begin{description}
|
||||
\item{\sc msgPool*} Fonctions servant à gérer une {\em pool}, qui
|
||||
correspond à un ensemble de {\em buffers}.
|
||||
\item{\sc msgPoolDataTab*} Fonctions utiles pour la gestion des
|
||||
|
||||
\item[msgPool*]{Fonctions servant à gérer une {\em pool}, qui
|
||||
correspond à un ensemble de {\em buffers}.}
|
||||
|
||||
\item[msgPoolDataTab*]{Fonctions utiles pour la gestion des
|
||||
informations d'une {\em pool} telles que la taille des {\em buffers},
|
||||
leur nombre\dots
|
||||
leur nombre\dots}
|
||||
\end{description}
|
||||
\item{\sc msgQueue*} Toutes les fonctions gérant les ``queues'', {\em
|
||||
files de maessages}. On y
|
||||
trouve celle qui en créé une, celles qui vérifient si elle est
|
||||
disponible ou pas, celles qui ajoutent un élément ou au contraire en
|
||||
enlève un.
|
||||
}
|
||||
|
||||
\item[msgQueue*]{Toutes les fonctions gérant les ``queues'', {\em
|
||||
files de messages}. On y trouve celle qui en créé une, celles i
|
||||
qui vérifient si elle est disponible ou pas, celles qui ajoutent
|
||||
un élément ou au contraire en enlève un.
|
||||
\begin{description}
|
||||
\item{\sc msgQueue*} Rassemble toutes les fonctions servant à la gestion
|
||||
des files de messages.
|
||||
\item{\sc msgQueueElem*} Les fonctions utiles pour gérer un élément
|
||||
d'une file de messages.
|
||||
\item{\sc msgQueue(Prot/Read)*} Fonctions servant à protéger une file.
|
||||
\item[msgQueue*]{ Rassemble toutes les fonctions servant à la gestion
|
||||
des files de messages.}
|
||||
|
||||
\item[msgQueueElem*]{ Les fonctions utiles pour gérer un élément
|
||||
d'une file de messages.}
|
||||
|
||||
\item[msgQueue(Prot|Read)*]{Fonctions servant à protéger une file
|
||||
({\em read} indique la disponibilité d'une ressource en lecture,
|
||||
{\em Prot} la protection contre les modification).}
|
||||
\end{description}
|
||||
\item{\sc msgSpace*} Ensemble de fonctions qui gèrent les espaces de
|
||||
}
|
||||
\item[msgSpace*]{Ensemble de fonctions qui gèrent les espaces de
|
||||
messages : création, ouverture, listes\ldots
|
||||
\begin{description}
|
||||
\item{\sc msgSpace*} Fonctions pour la création, ``ouverture'', ``fermeture''\dots d'un espace de messages.
|
||||
\item{\sc msgSpaceList*} Ce sont toutes les fonctions utiles pour la
|
||||
gestion de la liste cha{\^i}née des {\em msgSpace} existants.
|
||||
\item{\sc msgSpaceListElem*} Fonctions correspondant à la gestion d'un
|
||||
élément de la {\em msgSpaceList}.
|
||||
\item[msgSpace*]{Fonctions pour la création, ``ouverture'', ``fermeture''\dots d'un espace de messages.}
|
||||
|
||||
\item[msgSpaceList*]{Ce sont toutes les fonctions utiles pour la
|
||||
gestion de la liste cha{\^i}née des {\em msgSpace} existants.}
|
||||
|
||||
\item[msgSpaceListElem*]{ Fonctions correspondant à la gestion d'un
|
||||
élément de la {\em msgSpaceList}.}
|
||||
\end{description}
|
||||
}
|
||||
\end{description}
|
||||
|
||||
|
||||
\subsection{Détails sur certaines fonctions}
|
||||
|
||||
\par Nous détaillerons ici quelques fonctions qui peuvent ne pas
|
||||
|
|
@ -110,43 +125,45 @@ espace de messages {\em msgSpace *}, un num
|
|||
l'adresse d'un buffer {\em void *}. Elle insère le buffer dans le numéro
|
||||
de file de messages de l'espace de messages. Lorsque l'on appelle cette
|
||||
fonction, à la fin, on ``délocke'' le sémaphore sur la {\em queue}.
|
||||
\item{\sc msgSpaceState(\dots)} Cette fonction prend en argument, un
|
||||
``id'' d'espace de message, {\em msgSpaceId}, et permet de conna{\^i}tre
|
||||
l'état de l'espace de message dont l'``id'' est donnée en argument.
|
||||
\end{itemize}
|
||||
\newpage
|
||||
|
||||
\section{Difficultés rencontrées}
|
||||
|
||||
\par Nous n'avons pas eu de grosses difficultés à proprement parlé.
|
||||
\subsection{Restrictions}
|
||||
\par Nous n'avons pas eu de grosses difficultés à proprement parler.
|
||||
Nous avions juste quelques restrictions, comme le fait de ne pas
|
||||
pouvoir utiliser de pointeurs absolus, car l'espace d'adressage entre
|
||||
les différents processus n'est pas forcément le m{\^e}me. Ils ont
|
||||
seulement un segment de mémoire partagée en commun. Il a donc
|
||||
fallu utiliser les différentes {\em id} des espaces de messages {\em msgSpace}, ou
|
||||
encore des {\em pools} pour pouvoir faire en sorte que les processus peuvent
|
||||
bien accéder aux {\em buffers} situés dans la mémoire partagée.
|
||||
seulement un segment de mémoire partagée en commun.
|
||||
\par Il a donc fallu utiliser les différentes {\em id} (c'est à dire les identifiants POSIX) des espaces de messages {\em msgSpace}, des {\em pools}
|
||||
et autres types de données stockées en mémoire partagée pour pouvoir permettre a tous les processus d'accéder correctement aux données.
|
||||
|
||||
\subsection{Libertés d'implémentations de POSIX\ldots}
|
||||
|
||||
\par Le choix des identifiants ne fut pas simple non plus, car il
|
||||
fallait en changer en fonction des différentes implémentations. Par
|
||||
exemple nous pouvions avoir des identifiants du type ``\verb+/tmp/identifiant+'',
|
||||
qui ne marchaient que sur un type de machines. Sur les autres il
|
||||
fallait en avoir un du type ``\verb+/identifiant+''. Cela nous a amener
|
||||
à faire une distinction de cas et générer un identifiant différent
|
||||
selon que l'on soit sur une machine de type {\em HP-UX}, {\em SunOS}
|
||||
ou {\em Linux}.
|
||||
fallait en changer en fonction des différentes implémentations de POSIX.
|
||||
En effet la norme POSIX précise que l'identifiant doit commencer par un ``\verb+/+'' et si possible ne pas en comporter d'autres.
|
||||
\par Si cela est vrai sur certains systèmes (comme GNU/Linux) d'autres
|
||||
systemes (HP-UX, SunOS) requièrent que cet identifiant corresponde
|
||||
au chemin absolu (dans l'arborescence UNIX) d'un fichier sur lequel
|
||||
on possède des droits\ldots
|
||||
|
||||
\par Nous avons donc choisi les identifiants du type
|
||||
``\verb+/tmp/identifiant+'', qui pour les systèmes avec la restrictions précédente et ``\verb+/identifiant+'' sur les autres. i
|
||||
Cela nous a également conduit à faire une distinction dans le \verb+Makefile+
|
||||
entre les options de compilation pour {\em HP-UX}, {\em SunOS} ou {\em Linux}.
|
||||
\par Malheureusement le fait de travailler sur plusieurs types de
|
||||
machines n'était pas seulement g{\^e}nant pour les identifiants,
|
||||
mais également pour créer la bibliothèque. En effet, il faut ajouter
|
||||
plus ou moins d'options à la compilation: soit il faut ajouter \verb+-lrt+, dans un cas ou \verb+-lrt -lpthread+ dans l'autre. Ceci afin
|
||||
d'inclure les bonnes librairies pour que notre bibliothèque puisse
|
||||
fonctionner convenablement.
|
||||
\par Ces distinctions se font dans les {\em Makefile}, \verb+/src/Makefile+ et \verb+/test/Makefile+.
|
||||
\par Encore une autre difficulté d{\^u}e à Posix, est la
|
||||
projection de fichier ou {\em mapping} avec {\em mmap}. L'offset
|
||||
peut {\^e}tre aligné sur les pages mémoires sur
|
||||
certains systèmes. Or ceci est emb{\^e}tant lorsque l'on veut
|
||||
accéder à un fichier qui commence n'importe où dans le bloc mémoire.
|
||||
Pour remédier à cela, nous {\em mappons} jusqu'à ``juste derrière le
|
||||
buffer''. Nous autorisons le buffer en lecture/écriture et nous déplaçons
|
||||
l'adresse obtenue au début du buffer.
|
||||
compiler et fonctionner convenablement.
|
||||
|
||||
\par La seconde difficulté liée à POSIX, est la projection de fichier
|
||||
ou {\em mapping} avec {\em mmap}. Selon l'implémentation, l'offset (décalage par rapport au début de l'addresse mémoire du fichier) peut éventuellement {\^e}tre aligné sur la taille des pages mémoires\ldots
|
||||
\par Ceci est assez génant lorsque l'on veut accéder à bloc de donnée
|
||||
qui peut commencer n'importe où dans la zone de mémoire partagée.
|
||||
Pour remédier à cela, nous {\em mappons} du début de la zone mémoire partagée jusqu'à ``juste derrière'' le bloc de donnée qui nous intéresse.
|
||||
\par Puis nous changeons les droits d'acces (\verb+mprotect+) pour nous autoriser la modifiction uniquement sur le bloc de données qui nous intéresse.
|
||||
\par Enfin nous opérons le décalage d'addresse ``à la main'' et renvoyons l'addresse qui correspond au début du bloc de données demandé.
|
||||
|
|
|
|||
Loading…
Reference in a new issue