--- title: systèmes d'exploitation, TD2 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 Après le premier niveau de TD effectué, alors que nous pensions pouvoir vaincre le boss NachOS facilement (tel ceux des jeux *Ubisoft*), nous nous sommes en fait retrouvé dans un *Dark Souls* like. Vous savez ce genre de jeux qui nous donnent on a envie de casser manettes, clavier, écran, traiter le chat comme dans les pubs des *Nuls* mais sur lequel on revient forcément. L'objectif de ce TD a été de permettre l'exécution de programme dans Nachos avec plusieurs threads. Il s'est déroulé en 2 parties: * La première a été consacrée au multi-threading dans les programmes utilisateurs. Nous avons permis aux programmes utilisateurs de manipuler d es threads NachOS. * La seconde a eu pour but d'implémenter la plusieurs threads par processus. Pour réaliser ces deux parties, nous avons utilisé deux appels système : * un pour créer des threads (`ThreadCreate`) * un autre pour les détruire (`ThreadExit`) Les fonctions de base de la gestions de nos threads sont présente dans le fichier `userthread.cc`, dans leurs définitions se font dans `usertread.h`, comme demandé dans le sujet du TD. ### Passage des paramètres depuis l'appel système L'appel système `ThreadCreate` prends deux paramètres: l'adresse de la fonction à exécuter et l'adresse des paramètres de cette fonction. Cependant nous ne 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`: ```c typedef struct { int f; int arg; int stackAddr; } ThreadArgs_t; ``` 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*)`. 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 devenue inutile dans la fonction `StartUserThread` (fichier `userthread.cc` ligne 38-39). ### Le comptage des 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 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 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` a une taille de `UserStackSize`, nous pouvons en déduire le nombre de *"slots"* disponibles. Il ne faut pas oublier que notre `main` a déjà une pile et done la réserver a l'instanciation de notre `AddrSpace` (fichier `addrspace.cc` ligne 145). L'affectation d'un espace de pile se fait par la fonction `AllocateUserStack` (fichier `addrspace.h` ligne 320). Elle est appelée par `Do_ThreadCreate` **avant la création d'un nouveau thread** car si l'allocation echoue il faut tout arrêter et retourner une erreur: la célèbre *Stack Overflow*. L'adresse de pile de notre nouveau thread est encapsulée dans notre structure `ThreadArgs_t` afin de la passer à `StartUserThread`. Nous avions au départ imaginé un autre mécanisme: faire attendre les threads jusqu'à la libération d'une place. Petit problème cependant: que se passera-t-il lorsqu'un programme fera une barrière? ### Les points bonus Nous n'avons pas eu le temps d'aborder les points complémentaires. ## Points délicats Plusieurs points ont été délicats lors de la réalisation de ce TD2. Tout comme le premier TD, Il nous a fallu tout d'abord comprendre comment les éléments s'articulent entre eux. Cette étape nous a pris beaucoup de temps, nous avons obtenu **un premier thread réellement fonctionnel il y a tout juste deux semaines** -- après avoir tout repris de zéro. Nous avons passé une grosse partie de notre temps à lire, comprendre et expérimenter le code avant de pouvoir le modifier et le compléter. La création de notre premier thread a été pour nous le plus compliqué. En effet, lors de cette implémentation, nous avons rencontré plusieurs erreurs de segmentation car notre thread n'était pas à la bonne place dans la mémoire. Une fois cette étape passée les choses ont été un peu plus simple. ## Limitations Nous avons passé beaucoup de temps à comprendre comment tout les éléments s'articule ente eux; nous avons perdu du temps au début de la partie 1. Par manque de temps, nous n'avons pas pu réaliser la partie 3 Bonus. La terminaison de notre processus une fois tous les threads finis ne nous 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 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) Nous avons aussi inclus en ensemble conséquent de message de debug afin de tracer les actions de notre implémentation.