From 1b6fe8b3fe394bf4da6448a2615ae499c372d849 Mon Sep 17 00:00:00 2001 From: Yorick Barbanneau Date: Sun, 5 Dec 2021 22:03:12 +0100 Subject: [PATCH] Rework report --- rapports/td2/rapport.md | 31 +++++++++++++++++++------------ 1 file changed, 19 insertions(+), 12 deletions(-) diff --git a/rapports/td2/rapport.md b/rapports/td2/rapport.md index 255e8e9..4680592 100644 --- a/rapports/td2/rapport.md +++ b/rapports/td2/rapport.md @@ -49,6 +49,7 @@ pouvons passer qu'une seule valeur lors de du démarrage de notre Thread: ```c Thread->Start(void * funtion, void * arguments) ``` +\newpage Nous avons choisi d'encapsuler l'adresse mémoire de la fonction et l'adresse mémoire de ses arguments dans une structre `ThreadArgs_t`: @@ -65,23 +66,24 @@ Celle-ci est effectuée dans le fichier d'entête `userthread.h`, nous parlerons de `int stackAddr` un peu plus loin dans ce chapitre. La fonction `StartUserThread`, servant à initialiser les différents registres, -reçoit cette structure sous la forme d'un `(void*)`. Nos ne pouvons l'utiliser -tel quel, il nous faut donc la caster dans une variable de type `ThreadArgs_t`. +reçoit cette structure sous la forme d'un `(void*)`. Nous ne pouvons utiliser +cette structure avant la caster dans une variable de type `ThreadArgs_t`. Afin de ne pas perdre cette structure lors de la fin de notre fonction `Do_ThreadCreate`, nous la positionnons sur le tas avec un `malloc` (`userspace.cc` ligne 50). Afin de ne pas froisser *LealSanitizer* nous n'avons -pas oublié de libérer cette zone mémoire une fois devenueNouveau dossier inutile dans la -fonction `StartUserThread` (ligne 38-39). +pas oublié de libérer cette zone mémoire une fois devenue inutile +dans la fonction `StartUserThread` (fichier `userthread.cc` ligne 38-39). ### Le comptage des thread. -Comme nous l'avons compris, la classe `AddrSpace` représente un processus -- un -espace d'adressage. Côté noyau, tout n'est que Thread, dont certains partagent -un même espace d'adressage. Il nous a donc **semblé légitime d'implémenter le -comptage des Threads dans `AddrSpace`** via la variable publique `int thread` -(définie dans `addrspace.h` ligne 50). Celle-ci est initialisée à 1 lors de -l'instanciation: le `main` de notre programme compte lui aussi pour un thread. +Telle que nous l'avons comprise, la classe `AddrSpace` représente un processus +-- un espace d'adressage. Côté noyau, tout n'est que thread, dont certains +partagent un même espace d'adressage. Il nous a donc **semblé légitime +d'implémenter le comptage des threads dans `AddrSpace`** via la variable +publique `int thread` (définie dans `addrspace.h` ligne 50). Celle-ci est +initialisée à 1 lors de l'instanciation: le `main` de notre programme compte lui +aussi pour un thread. Une fois que nous savons combien de threads sont encore "en vie", il nous est possible de terminer notre programme quand tous ses threads sont finis dans la @@ -90,7 +92,7 @@ fonction `Do_ThreadExit` (fichier `usersthread.cc` ligne 88). ### Gestion de la pile Comme l'a démontré notre programme de test (`/test/threadtest.c`), la première -version de notre gestion de threads était plus qu'imparfaite: elle les +version de notre gestion de threads était plus qu'imparfaite: elle les conjuguait tous avec la même pile. Nous avons alors utilisé la classe `Bitmap` afin de gérer les espaces de pile de nos différents threads. Sachant que nous réservons 256 octets de pile par thread et que notre pile gérée par `AddrSpace` @@ -141,6 +143,8 @@ convient pas (`Do_ThreadExit`), nous la trouvons bancale, une version plus élégante devrait être possible (sûrement plus simple une fois le TD3 plus avancé). +\newpage + ## Tests Tous nos test se sont fait avec `test/threadtest.c`, nous avon adapté son code @@ -149,4 +153,7 @@ en fonction de ce que nous voulions tester: * tester le fonctionnement d'un seul thread (Action I.7) * tester le fonctionnement de plusieurs threads (Action II.1) * tester la pile (Action II.3) - * l'utilisation de la classe `Bitmap` (Action II.4) + * l'utilisation de la classe `Bitmap` (Action II.4) + +Nous avons aussi inclus en ensemble conséquent de message de debug afin de +tracer les actions de notre implémentation.