5.3 KiB
title: systèmes d'exploitation, TD3 documentclass: scrartcl author:
- Juliette Lenoir
- Yorick Barbanneau fontsize: 13pt mainfont: DejaVu Serif geometry: [top=1.5cm, bottom=3cm, left=3cm, right=3cm] header-includes:
- \definecolor{liens}{HTML}{de6a66} urlcolor: liens linkstyle: bold ...
Bilan
Le voici, le boss final de Nachos: le dernier TD! Dans la lignée des précédents, a-t-il fait passé un boss de Sekiro pour un promenade de santée? La réponse est non. Profitant de l'expérience des précédents, nous sommes rentrés dedans plus facilement. Mais ne pensez pas pour autant qu'on a fait une partie de Rayman, _comme pour les précédents, nous avons du y passer beaucoup de soirées...
La classe PageProvider
Nous avons implementé et utilisé sans trop de difficulté ReadAtVirtual() comme
demandé (Action I.3). La classe PageProvider implementée dans le
fichier userprog/pageprovier.cc n'as pas montré plus de difficulté non plus (
Action I.5).
Il a éte plus compliqué de choisir l'emplacement de notre variable
pageProvider. Nous avons au départ choisi de le positionner dans
machine/machine.cc. Mais comme on s'interroge souvent sur La grande question
sur la vie, l'univers et le reste, on s'est aussi interrogé sur la pertinence
de cet emplacement. Nous avons fini par le positionner dans threads/system.cc.
Cette classe gère l'allocation de pages mémoire, il n'en faut qu'une seule instance de cette classe, nous devons gérer la mémoire que d'un seul endroit. Plusieurs instances de cette classe entrainerai des collisions : deux objets pourraient allouer la même zone mémoire.
La stratégie de test
Afin de tester notre implementation, nous avons écrit le programme
test/userpages0.c. Celui ci lance deux thread utilisant PutString pour
afficher des caractères. Nous nous sommes aidé d'information de débogage
donnée par la commande DEBUG afin de vérifier l'enchaînement des élements.
Afin de filter plus précisément les message issus de notre classe, nous
utilisons une lettre (p pour PageProviser):
DEBUG ('p', "PageProvider: GetEmpryPage() allocated page: %i\n", newPage);
L'appel système ForkExec
Le principe est donc simple : créer plusieurs espaces d'adressages, car encore une fois, un processus est espace d'adressage. Nous avons maintenant de l'expérience lorqu'il s'agit d'implementer des appels systèmes dans Nachos.
Nous avons choisi de mettre la fonction do_ForkExec dans le fichier
userprog/userthread.cc. Nous avons géré deux problèmes possibles dans cette
fonction:
- Le fichier executable passé en paramètre n'existe pas
- La creation de l'espace dadressage échoue. Cette erreur doit être capturée
avec un
try ... catch ...
Gérer les processus
Afin de gérer les processus, il faut les compter. Il nous faut donc un entier et
un sémaphore afin de protéger son incrémentation / décrémentation. Il sont
positionnés dans le fichier threads/system.cc.
L'incrémentation se fait dans le constructeur de AddrSpace, la décrémentation
dans son destructeur. Dans le destructeur, nous libérons aussi les pages
mémoire en exécutant ReleasePage sur chaque
AddrSpace->pageTable[]->PhysicalPage.
Le test
Le programme /test/forkexec.c nous a servi de test pour notre implementation.
Il lance deux processus (test/userpages0.c). Le fichier mempory.svg exporte
dans la fonction StartUserProc() (userprog/usertthread.cc ligne 101)
laisse bien apparaître nos deux espaces d'adressages.
Le stress test
Nous avons écris le programme test/forkexec_stress.c qui fait appel à
test/userpages0.c et test/userpages1.c. Chacun des deux derniers est lancé
six fois (12 processus au total) et lance à son tours 12 threads.
Lors du lancement de ce stress-test, nous somme tombe à cours d'espace en
memoire. Nous avons donc augmenté le nombre des pages disponibles dans le
fichier machine/machine.h:
#define NumPhysPages 1024 // 256 pages au départ
Vous pouvez noter que la l'export de la cartographie memoire dans
StartUserProc() a été désactivé pour l'implementation de ce test. La
generation du fichier SVG allourdissait considérablement l'exécution. Nous
l'avons testé tout de même une fois: le fichier SVG pèse envison 18Mo...
Ce qui nous manque
Nous n'avons pas eu le temps de traiter les points bonus. Nous avons une
ébauche de l'Action II.4 sur notre dépôt de code mais rien ne fonctionne (à
vrai dire il est dans un git stash au milieu d'autres...).
Les limitations
À partir de l'impementation de l'appel système ForkExec, l'address sanitizer
est désactivé. Chaque exécution d'un programme utilisateur contenant des thread
menait à des erreur de fuite mémoire. Cette erreur particulième nous contraint à
effetcuer un CTRL+C afin de rependre la main sur notre terminal.
[...]
Cleaning up...
AddressSanitizer:DEADLYSIGNAL
=================================================================
==2622712==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 \
(pc 0x7fdcc41a8227 bp 0x63100054cfb8 sp 0x63100054c688 T0)
==2622712==The signal is caused by a READ memory access.
==2622712==Hint: address points to the zero page.
Le temps nous a manquer pour investiguer sur le problème.