Not Another Completely Heuristic Operating System Première étape: améliorer le système de threads

Transcription

1 Not Another Completely Heuristic Operating System Première étape: améliorer le système de threads KASTTET Ahmed MIMET Mohamed ROUAK Sidi Mohammed SALIM Eliass

2 Sommaire I. Introduction... 3 II. Locks et variables de conditions Les Locks... 3 a. Implémentation... 3 b. Tests Les variables de condition... 4 a. Implémentation... 4 b. Les tests... 5 III. Le Join et Le Finish : Implémentation... 6 a. Modification du constructeur du thread :... 6 b. Implémentation de la fonction Join() :... 6 c. Modification de la fonction Finish() : Déroulement des tests... 7 a. Cas où le père à un seul fils et finit avant celui-ci... 7 b. Cas où le père à un seul fils et finit après celui-ci... 7 c. Cas où le père a plusieurs fils IV. Le communicateur

3 Introduction Nachos est un système pédagogique conçu pour l'enseignement des concepts de base des systèmes d'exploitation. Le système Nachos est un système simulé, il ne s'exécute pas sur une machine réelle. Il est exécuté en tant que processus Unix à l'intérieur duquel s'exécutent des applications pour l'architecture MIPS (qui est donc l'architecture simulée). Les threads partagent les données globales du programme. Il est donc nécessaire de synchroniser les accès concurrents à ces données. Lors de cette première étape, nous avons codé les locks, les variables de condition, le Join ainsi que le communicateur. Locks et variables de conditions 1. Les Locks Les verrous permettent d'assurer l'accès exclusif d'un thread (ou d'un processus) à une ressource. Il est possible de bloquer le verrou et de le relâcher. Les threads qui demandent à bloquer un verrou alors qu'il est déjà bloqué sont mis en attente jusqu'au moment où le verrou est relâché. Ce mécanisme permet de garantir qu'un seul thread est actif (lorsqu'il a réussi à bloquer le verrou) et qu'il peut modifier des données partagées sans risque de conflits. a. Implémentation Nous avons implémenté trois fonctions nécessaires à la synchronisation des threads par l intermédiaire des locks. Il s agit des fonctions suivantes: isheldbycurrentthread() : Comme son nom l indique, cette fonction nous permet de s assurer que le thread courant possède le lock. Lock::isHeldByCurrentThread (){ return(currentthread==hasthelock); } Acquire() : cette fonction permet à un thread d acquérir le lock si ce dernier est libre, ou de se mettre dans la file d attente du lock. Pour cela nous avons procédé de la manière suivante : 3

4 Enlever les interruptions afin d éviter les changements de contexte. Tester si le lock est pris. Si c est le cas, il faut ajouter le thread courant à la liste des threads en attente et l envoyer dormir. On a utilisé une boucle while et non un if pour le test afin d éviter le fait que deux threads croient avoir le lock à un moment donné. Sinon déclarer le lock occupé par le thread courant et on modifie la valeur de la variable utilisée par la fonction «isheldbycurrentthread()». Remettre les interruptions. Release() : cette fonction permet à un thread de relâcher le lock et réveiller éventuellement un thread présent dans la file d attente du lock. Pour cela nous avons procédé de la manière suivante : Enlever les interruptions afin d éviter les changements de contexte. S assurer que le thread courant détient bien le lock en utilisant une assertion. Sortir éventuellement un thread de la file d attente du lock. Le déclarer «READY» en appelant la fonction «ReadyToRun ()» du Scheduler. Déclarer le lock libre. Remettre les interruptions. b. Tests Pour tester le bon fonctionnement des primitives relatives au lock on a suivi les étapes suivantes : Création de deux threads a l aide de la fonction Fork(). Le premier thread acquière le lock, exécute sa section critique et lâche volontairement la main à l aide de la fonction Yield(). Le deuxième thread demande le lock pour exécuter sa section critique. Sachant que le premier thread possède toujours le lock (il n pas appelé la fonction Release()) le deuxième ne peut s exécuter. Ainsi on assure l exclusion mutuelle entre deux threads à l aide des lock. 1. Les variables de condition a. Implémentation Les variables de condition résolvent le problème de l'inter blocage. Associées à un verrou, elles servent à gérer l attente d un événement par un ou plusieurs threads. L inter blocage se produit, par exemple, lorsqu'un thread T1 ayant déjà acquis la ressource R1 demande l'accès à une ressource R2, pendant que le thread T2, ayant déjà acquis la ressource R2, demande l'accès à la ressource R1. Chacun des deux threads attend alors la libération de la ressource possédée par l'autre. 4

5 Un verrou doit être acquis et libéré par le même thread. Par contre, une variable de condition peut être gérée en commun par plusieurs threads. Voici les opérations sur les variables de condition qu on a implémentée: Wait() : permet à un thread d attendre qu une condition se produise pour pouvoir continuer son exécution. Si la condition n est pas vérifiée le thread s endort dans la file d attente pour permettre à un autre thread de s exécuter. Pour implémenter cette fonction on a procédé comme suit : Enlever les interruptions afin d éviter les changements de contexte. Relâcher le lock avant d aller dormir pour éviter l interblocage. Ajouter le thread dans la file d attente des threads endormis à l aide de la fonction Sleep(). Demander l acquisition du lock à l aide de la fonction Acquire(). Remettre les interruptions. Notons que les deux opérations (relâcher le lock et aller dormir) doivent se faire demanière atomique pour cela on doit acquérir le lock avant de faire appel a Wait(). Signal() : Une fois la condition remplie cette fonction reveille un thread en attente sur la variable de condition pour qu il puisse s exécuter. Voici les étapes de son implémentation : Enlever les interruptions Sortir le thread de liste d attente Le déclarer «READY» en appelant la fonction «ReadyToRun ()» du Scheduler. Relâcher le lock. Remettre les interruptions. Broadcast() : Cette opération est une sorte de Signal() généralisé. Elle permet de réveiller tous les threads qui sont en attente sur la variable de condition. Son implémentation suit les mêmes étapes que Signal() sauf qu on rajoute une boucle while qui sert à vider toute la liste d attente. Ensuite il faut déclarer les threads READY. b. Les tests Pour tester le fonctionnement des ces primitives on utilise un mécanisme de «pingpong» entre deux threads. Le premier acquière le lock, exécute sa section critique et fait un Wait(). Le deuxième thread acquière le lock(car le premier l a relâcher dans le wait() ), exécute sa section critique et fait un Signal() pour réveiller le premier afin qu il reprenne la main. Le test de Broadcast() suit le même principe sauf qu on utilise trois threads. 5

6 Le Join et Le Finish : 1. Implémentation La fonction Join permet à un père d utiliser des résultats de calcul de son (ou ses) fils afin de pouvoir continuer son exécution. Il est nécessaire de distinguer trois cas : Le père finit avant son fils, et attend la fin de l exécution de ce dernier pour récupérer ses résultats. Le père finit avant son fils, et donc ici, c est le fils qui doit attendre son père qui dés lors qu il finira son exécution réveillera son fils. Le père peut aussi avoir plusieurs fils, et la il faudra constituer une liste qui contiendra tous les fils. Pour implémenter cette fonction, nous avons procédé de la manière suivante : a. Modification du constructeur du thread : Tout d abord, nous avons ajouté un argument au constructeur du thread qui indique si un appel à Thread::Join() sera effectué sur ce thread c'est-à-dire si le thread est joignable ou pas. Ensuite, nous avons rajouté une variable «indicateur» pour vérifier si le thread fils a terminé son exécution ou non. La valeur de cette variable sera égale à 1 si le fils a terminé son exécution et à 0 si ce n est pas le cas. Pour éviter les conflits, nous avons protégé cette variable avec un lock. Nous utilisons deux variables de conditions encore une fois protégée par un lock, une pour le père et l autre pour les fils. La première permet de faire attendre le père ou de le réveiller. La deuxième permet d effectuer le même traitement sur les fils. Puis, nous avons instancier une nouvelle liste qui va contenir les fils ayant appelé la fonction Fork() dans laquelle nous rajoutons le thread l ayant appelé dans la liste. Thread::Thread(char* threadname, bool joinable ) {... estjoinable=joinable; threadpere=currentthread; indicateur=0; filsjoinables = new List(); currentfils=null; if(estjoinable) { lockprotege = new Lock("lock"); this->condfils = new Condition("cond fils"); this->condpere = new Condition("cond pere"); }... } b. Implémentation de la fonction Join() : On acquiert le lock. On regarde si le fils a terminé son exécution. 6

7 Si c est le cas, le père réveille le fils en appelant Signal() sur Sinon on indique au fils que le père à fait un Join() en changeant la valeur de «indicateur» et le père fait un Wait(). c. Modification de la fonction Finish() : Comme le fils peut lui aussi avoir d autres fils, il faut faire une boucle While pour effectuer un join() sur ses fils avant que lui exécute le code du Finish(). On vérifie que le fils est joignable et il acquiert le lock pour pouvoir modifier la variable «indicateur». Si le père a déjà fait un join() (la variable «indicateur» du fils égale à 1) le fils réveille le père, on élimine ce fils de la liste des fils et on libère le lock. Sinon on indique au père que le fils à déjà fait un Finish() (la variable «indicateur» du père à 1), on élimine ce fils de la liste des fils qui va ensuite s endormir, et on libère le lock. De plus, dans le cas ou le père a plusieurs fils, il faut vérifier si certains fils n ont pas encore appelé le Finish(), et si c est le cas on doit remettre la valeur «indicateur» du père à zéro. Remarque : La valeur «indicateur» du père ne sera égale à un que dans le cas où tous ses fils ont appelé Finish(). 2. Déroulement des tests Pour effectuer les tests, nous avons traité les trois cas précédent séparément. a. Cas où le père à un seul fils et finit avant celui-ci Pour cela, nous avons créé trois fonctions et deux threads. Un thread exécute la fonction fncjoin1pavant(), l autre exécute la fonction fncjoin2pavant() et la troisième fonction joinpereavant() fait aux deux fonctions précédentes. Le fils exécute la première fonction tandis que le père exécute la deuxième. Nous avons fait en sorte à l aide des boucles While que le père finisse son exécution avant le fils, et dans ces boucles nous effectuons des Yield() afin que les deux processus puissent se passer mutuellement la main. Dés que le père finit son traitement, il fait un appel à Join() et se met en attente jusqu à que son fils le réveille avec un appel à Finish() à la fin de son exécution. Nous avons vérifier le bon fonctionnement de notre code à l aide de printf(). b. Cas où le père à un seul fils et finit après celui-ci. Nous avons de procéder de la même manière que dans le premier cas, sauf que nous avons implémenter trois nouvelles fonctions fcnjoin1papres(), fcnjoin2papres() et joinpereapres() qui fait appel aux deux premières. Cette fois ci, on a fait en sorte que le père finisse après son fils. 7

8 c. Cas où le père a plusieurs fils. Nous avons ici simulé le cas où le père a deux fils. Le raisonnement reste le même que dans les deux cas précédent. Notons cependant que le père ne se réveille que lorsque ses deux fils ont terminé leurs exécutions. Nous avons utilisé les fonctions fncjoinperedeuxfils1(), fncjoinperedeuxfils2() fncjoinperedeuxfils3() et la fonction fncjoinperedeuxfils() qui les appelle. Le communicateur Le communicateur permet de réaliser une communication synchronisé entre threads. Plusieurs threads peuvent être en attente pour parler, et plusieurs en attente pour écouter en utilisant des variables conditions. On a implémenté la classe Communicator (en parallèle on a implémenté le fichier.h correspondant). Cette classe contient deux méthodes suivantes: void Speak(int message) :Attend qu un thread soit en écoute pour pouvoir lui envoyer le message. int Listen() : Attend qu un thread parle pour écouter le message et le retourner. Le constructeur de la classe Communicator contient l instanciation de deux variables de conditions qui permettent d utiliser les fonctions Wait() et Broadcast() à la fois dans Speak() et dans Listen(), il contient aussi un Lock qui évite les conflits (un thread ne peut écouter que si un autre a fini de parler), le mot qui va être envoyé(initialement mis à zéro) et la variable tour qui fait en sorte que l on ne puisse pas parler tant que le premier message n a pas été écouté. Communicator::Communicator(){ lockcomm = new Lock("lock"); tour=false; word=0; tolisten=new Condition("toListen"); tospeak=new Condition("toSpeak"); } La fonction Speak() : Acquiert le lock. Verifier si la variable tour est égale 1 avec un test if. Si oui il fait un broadcast() pour réveiller le thread en attente d écoute et fait un Wait(). Si non il envoie le message entré comme paramètre en changeant la variable message dans le constructeur. Et réveille le thread qui est en attente pour parler. Relâche le lock. La fonction Listen() : 8

9 Acquiert le lock. Verifier si la variable tour est égale 0 avec un test if. Si oui il fait un broadcast() pour réveiller le thread en attente d écoute et fait un Wait(). On écoute le message et le retourne, en accédant à la variable message qui été initialisé dans le constructeur. 9