Changes between Version 2 and Version 3 of processus_thread
- Timestamp:
- May 20, 2016, 8:48:17 PM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
processus_thread
v2 v3 3 3 [[PageOutline]] 4 4 5 == 1) création d’un processus dans un cluster distant==5 == __1) descripteur de processus__ == 6 6 7 === 1.1) descripteur de processus === 7 Le PID (Process Identifier) est codé sur 32 bits, et il est unique dans le système : les 16 bits de poids fort contiennent 8 les coordonnées (X,Y) du cluster propriétaire Z, les 16 bits de poids faibles (LPID) contiennent le numéro local dans le cluster Z. 9 Le descripteur d’un processus P et les tables qui lui sont associées ne sont répliqués - partiellement- que dans les clusters qui contiennent au moins un thread de P (appelés clusters actifs de P). 8 10 9 Le descripteur de processus est défini par la structure task_t, et il contient les informations suivantes 11 Le descripteur de processus est défini par la structure task_t, et il contient les informations suivantes: 12 13 - PID : processus identifier (contient les coordonnées du cluster propriétaire) 14 - PPID : parent processus identifier, 15 - XMIN, XMAX, YMIN, YMAX : recrangle recouvrant tous les clusters actifs 16 - PT : table des pages du processus, 17 - VSL : liste des vsegs du processus, 18 - FDT : table des fichiers ouverts du processus, 19 - TRDL : liste des threads du processus, 20 - ENV : variables d’environnement du processus, 21 22 == __2) création d’un processus dans un cluster distant__ == 10 23 11 24 Ce mécanisme a été implémenté dans ALMOS-MK par Pierre-Yves Péneau, il est décrit dans la thèse de Mohamed Karaoui. … … 13 26 On suppose qu’il existe un ordonnanceur par coeur, qui a pour rôle d’ordonnancer les threads qui ont été placés sur ce coeur. 14 27 15 1.1) fork() 28 === 2.1) fork() === 29 16 30 Le processus père P s’exécute sur un coeur du cluster Z. Il fait un appel système fork() qui a principalement 17 31 pour rôle de sélectionner un cluster cible X qui deviendra le cluster propriétaire du processus fils F, et de dupliquer … … 27 41 et rend la main au processus P. 28 42 29 1.2) exec() 43 === 2.2) exec() === 44 30 45 Une fois l'opération fork() terminée, le processus fils P’ peut exécuter l'appel système exec(). Cet appel système exec() effectue une EXEC_RPC vers le cluster X, avec les arguments suivants: le PID du processus fils, le nom de la fonction à exécuter, les arguments de la fonction s'il y en a, les variables d'environnement. 31 Cette RPC alloue un descripteur de processus pour le processus F, ainsi qu’un descripteur de thread. Il initialise ces descripteurs et les tables PT(F,X) , VSL(F,X), TRDL(F,X) en utilisant les arguments de la RPC. Il recopie le contenu de la FDT(P’,Z) 32 dans la FDT(F,X), en utilisant un remote_memcpy(), puisqu’il dispose de l’adresse étendue de P’. 46 Cette RPC alloue un descripteur de processus pour le processus F, ainsi qu’un descripteur de thread. Il initialise ces descripteurs et les tables PT(F,X) , VSL(F,X), TRDL(F,X) en utilisant les arguments de la RPC. Il recopie le contenu de la FDT(P’,Z) dans la FDT(F,X), en utilisant un remote_memcpy(), puisqu’il dispose de l’adresse étendue de P’. 33 47 Quand le processus P’ sur le cluster Z reçoit une réponse positive pour cette EXEC_RPC, le processus P’ intermédiaire 34 48 se suicide. … … 37 51 Le code binaire (segments code et data) sera chargé dans la mémoire du cluster cible, lors du traitement des défauts de page. 38 52 39 2) Création d’un thread dans un cluster distant 53 == __3) descripteur de thread__ == 40 54 41 Il y a deux types de threads : un thread “user” est créé suite à un appel système pthread_create(). 42 Un thread “kernel” est créé pour exécuter un service système. On s’intéresse uniquement ici aux threads “user”. 55 Il existe quatre types de threads : 56 * un thread '''USER''' est créé suite à un appel système pthread_create(). 57 * un thread '''KERNEL''' est créé pour exécuter un service système. 58 * un thread '''IDLE''' est exécuté par un CPU qui ne possède aucun autre thread exécutable. 59 * un thread '''RPC''' est créé et ou activé par le noyau pour exécuter une ou plusieurs RPCs. 43 60 44 Un thread “user” peut être dans 6 états: 45 - CREATED : créée mais pas encore éligible 46 - RUNABLE : éligible par l’ordonnanceur 47 - RUNNING : en cours d’exécution 48 - BLOCKED : non éligible, en attente d’une ressource 49 - COMPLETED : non éligible, en attente de destruction effective suite à un pthread_join() 50 - UNUSED : le descripteur de thread peut être réutilisé pour un nouveau thread 61 QUESTION pourquoi distingue-t-on les thread KERNEL et les thread RPC ? 62 63 Un thread peut être dans 6 états décrits dans la section portant sur l'ordonnancement des thread. 51 64 52 65 L’OS attribue à un thread d’un processus P un identifiant unique dans le processus. Ce TRDID est codé sur 32 bits, … … 54 67 du coeur assigné au thread (par exemple X = TRDID[31:24] / Y = TRDID[25:16] / L = TRDID[15:8] / LTID = TRDID[7:0]). 55 68 69 ATTENTION : ce TRDID n'est pas actuellement implémentés dans ALMOS-MK. 70 56 71 Les principales informations stockées dans le descripteur de thread sont les suivantes : 57 - TYPE : KERNEL / USER / IDLE 58 -TRDID : thread identifier (contient les coordonnées [X,Y,L] du coeur)59 -PID : processus identifier du processus contenant le thread60 - STATE : CREATED / RUNNABLE / RUNNING / BLOCKED / COMPLETED61 -SAVE : zone de sauvegarde des registres du coeur.62 -PARENT : TRDID du thread parent qui doit être informé de la terminaison.63 -IO : canaux alloués au thread dans le cas des périphériques multi-canaux.64 -SIGNALS : vecteur de bits permettant d’enregistrer les signaux reçus par le thread72 * TYPE : KERNEL / USER / IDLE / RPC 73 * TRDID : thread identifier (contient les coordonnées [X,Y,L] du coeur) 74 * PID : processus identifier du processus contenant le thread 75 * STATE : CREATE / READY / USER / KERNEL / WAIT / DEAD 76 * SAVE : zone de sauvegarde des registres du coeur. 77 * PARENT : TRDID du thread parent qui doit être informé de la terminaison. 78 * IO : canaux alloués au thread dans le cas des périphériques multi-canaux. 79 * SIGNALS : vecteur de bits permettant d’enregistrer les signaux reçus par le thread 65 80 - etc. 81 82 == __4) Création d’un thread user dans un cluster distant__ == 66 83 67 84 N’importe quel thread T de n’importe quel processus P s’exécutant sur n’importe quel cluster K peut créer un nouveau thread T’ … … 69 86 est effectué par l’instance du noyau du cluster M. Le cluster propriétaire du processus P peut être un troisième cluster Z. 70 87 71 Seul le noyau du cluster propriétaire du processus P peut créer ou détruire un thread appartenant au processus P. 72 (i.e. modifier la Liste des threads TRDL appartenant au processus P) 73 Ceci simplifie les problèmes de concurrence, et permet de simplifier les copies des descripteurs de processus dans 74 les clusters autres que le propriétaire de P. La copie de la liste des threads TRDL(P,M) dans un cluster M autre 75 que le cluster propriétaire de P ne contient que les descripteurs de thread qui s’exécutent localement sur un coeur de M, 88 Seul le noyau du cluster propriétaire du processus P peut créer ou détruire un thread appartenant au processus P (i.e. modifier la Liste des threads TRDL appartenant au processus P) 89 Ceci simplifie les problèmes de concurrence, et permet de simplifier les copies des descripteurs de processus dans les clusters autres que le propriétaire de P. 90 La copie de la liste des threads TRDL(P,M) dans un cluster M autre que le cluster propriétaire de P ne contient que les descripteurs de thread qui s’exécutent localement sur un coeur de M, 76 91 alors que la TRDL(P,Z) du cluster Z propriétaire de P doit contenir tous les threads de P. 77 92 78 2.1) Le noyau du cluster K envoie une THREAD_REQ_RPC au cluster Z propriétaire. Les arguments sont le PID du processus, 79 le cluster cible M, la fonction à exécuter et ses arguments, … To Be Completed … 93 === 4.1) phase 1 === 80 94 81 2.2) Le noyau du cluster Z propriétaire, envoie au cluster cible M une THREAD_CREATE_RPC dont les arguments sont le PID 82 du processus P, la fonction à exécuter et ses arguments, … To Be Completed … 95 Le noyau du cluster K envoie une THREAD_CREATE_RPC au cluster Z propriétaire. Les arguments sont le PID du processus, le cluster cible M, la fonction à exécuter et ses arguments. 96 Le noyau du cluster Z propriétaire de P, ne répond pas immédiatement au cluster demandeur K, mais envoie au cluster cible M une THREAD_CREATE_RPC, avec les mêmes arguments. 83 97 84 2.3) Le noyau du cluster Y vérifie s’il possède une copie du descripteur du processus P. 85 Si ce n’est pas le cas il crée et enregistre un nouveau descripteur du processus P dans Y, et alloue les structures PT(P,X), 86 VSL(P,X), FDT(P,X), TRDL(P,X). Il initialise les structures VSL et FDT en utilisant des remote_memcpy() depuis le cluster Z. 87 La PT reste vide, et se remplira à la demande lors du traitement des défauts de page. 88 Quand il est sûr de posséder une copie du descripteur de processus P, il sélectionne un coeur charger d’ordonnancer 89 le nouveau thread T’. Il attribue un TDID au thread à T’, crée un descripteur de thread et l’enregistre dans la TRDL. 98 === 4.2) phase 2 === 99 100 Le noyau du cluster M vérifie s’il possède une copie du descripteur du processus P. 101 Si ce n’est pas le cas il crée et un nouveau descripteur du processus P dans M, et alloue les structures PT(P,M), VSL(P,M), FDT(P,M), TRDL(P,M). 102 Il initialise les structures VSL et FDT en utilisant des remote_memcpy() depuis le cluster Z vers le cluster M. 103 La structure PT(P,M) reste vide, et se remplira à la demande lors du traitement des défauts de page. 104 Quand il est sûr de posséder une copie du descripteur de processus P, il sélectionne un coeur charger d’exécuter le nouveau thread T’, Il attribue un TRDID au thread à T’, crée un descripteur de thread et l’enregistre dans la TRDL(P,M). 90 105 Finalement, il enregistre T’ dans l’ordonnanceur du coeur sélectionné, et renvoie le TRDID dans la réponse RPC au cluster Z. 91 106 92 2.4) Le noyau du cluster Z propriétaire de P alloue un descripteur de thread et l’enregistre dans sa TRDL(P,Z). 93 Cette TRDL(P,Z) est la seule à contenir la totalité des descripteurs de threads du processus P. 94 Puis il renvoie une réponse RPC au cluster X. 107 === 4.3) Phase 3 === 95 108 96 3) Destruction d’un thread 109 Le noyau du cluster Z propriétaire de P alloue un descripteur de thread et l’enregistre dans sa TRDL(P,Z). 110 Cette TRDL(P,Z) doit en effet contenir la totalité des descripteurs de threads du processus P. 111 Puis le noyau de Z renvoie une réponse RPC au cluster K. 97 112 98 On suppose que la destruction d’un thread TRDID s’exécutant sur un cluster K est déclenchée 113 == __5) Destruction d’un thread__ == 114 115 La destruction d’un thread TRDID s’exécutant sur un cluster K est déclenchée : 99 116 - soit par le thread lui-même (appel système pthread_exit() ), 100 117 - soit par le noyau du cluster hôte K où s’exécute le thread, … … 102 119 Dans tous les cas, c’est le noyau du cluster hôte K, qui pilote cette destruction. 103 120 104 3.1) Le noyau du cluster K envoie une THREAD_EXIT_RPC au cluster Z propriétaire du processus P, 105 pour qu’il mette à jour la TRDL(P,Z) qui contient tous les thread de Private. Les arguments sont le PID et le TRDID. 121 === 5.1) phase 1 === 106 122 107 3.2) Le noyau du cluster Z propriétaire de P met à jour sa TRDL(P,Z), en supprimant le thread TRDID, 108 p uis envoie la réponse RPC au cluster K.123 Le noyau du cluster K envoie une THREAD_EXIT_RPC au cluster Z propriétaire du processus P, 124 pour qu’il mette à jour la TRDL(P,Z) qui contient tous les thread de P. Les arguments sont le PID et le TRDID. 109 125 110 3.3) Le noyau du cluster K enregistre le signal KILL dans le descripteur de thread TRDID au moyen d’une opération atomique. 126 === 5.2) phase 2 === 127 128 Le noyau du cluster Z propriétaire de P met à jour sa TRDL(P,Z), en supprimant le thread TRDID, puis envoie la réponse RPC au cluster K. 129 130 === 5.3) phase 3 === 131 132 Le noyau du cluster K enregistre le signal KILL dans le descripteur de thread TRDID au moyen d’une opération atomique. 111 133 Lors du traitement de ce signal, le thread TRDID est éliminé de l’ordonnanceur, il est éliminé de la TRDL(P,X), et la mémoire 112 134 allouée pour le descripteur de thread dans le cluster K est libérée. 113 135 114 4) Destruction d’un processus 136 == __5) Destruction d’un processus__ 115 137 116 Cette section n’est qu’une ébauche… [AG] 117 118 On suppose que la destruction d’un processus P est déclenchée 138 La destruction d’un processus P est déclenchée : 119 139 - soit par un thread du processus P s’exécutant sur un cluster X quelconque (appel système exit() ), 120 140 - soit par le noyau du cluster Z propriétaire P, … … 122 142 Dans tous les cas, c’est le noyau du cluster Z propriétaire de P, qui pilote cette destruction. 123 143 124 4.1) Si l’appel système exit() est exécuté sur un cluster K différent du cluster Z propriétaire, le noyau du cluster K 125 envoie une EXIT_REQ_RPC vers le cluster Z propriétaire. 144 === 5.1) phase 1 === 126 145 127 4.2) Pour exécuter la EXIT_REQ_RPC, le noyau du cluster Z propriétaire de P broadcaste une ALL_DELETE_BCRPC 128 vers tous les clusters M qui contiennent au moins un thread du processus P.L’argument est le PID du processus P.146 Si l’appel système exit() est exécuté sur un cluster K différent du cluster Z propriétaire, le noyau du cluster K envoie une TASK_EXIT_RPC vers le cluster Z propriétaire. 147 L’argument est le PID du processus P. 129 148 130 4.3) Dans chaque cluster M, le noyau recevant une ALL_DELETE_RPC enregistre le signal KILL dans les descripteurs 131 des threadsde P. Quand il détecte que la TRDL(P,M) est vide, il libère toutes les structures de données allouées au processus P 132 dans le cluster M. Finalement, il retourne la réponse au cluster Z. 149 === 5.2) phase 2 === 133 150 134 4.4) Lorsque toutes les réponses au ALL_DELETE_BCRCP ont été reçues par le cluster Z, celui-ci libère toutes les structures 151 Pour exécuter la TASK_EXIT_RPC, le noyau du cluster Z propriétaire de P broadcaste une TASK_EXIT_RPC vers tous les clusters M qui contiennent au moins un thread du processus P. 152 Dans chaque cluster M, le noyau recevant une TASK_EXIT_RPC enregistre le signal KILL dans les descripteurs detous les threadsde P. 153 Quand il détecte que la TRDL(P,M) est vide, il libère toutes les structures de données allouées au processus P dans le cluster M, et retourne la réponse au cluster Z. 154 155 === 5.3) phase 3 === 156 157 Lorsque toutes les réponses au TASK_EXIT_RCP ont été reçues par le cluster Z, celui-ci libère toutes les structures 135 158 de données allouées au processus P dans le cluster Z.