Changes between Version 2 and Version 3 of processus_thread


Ignore:
Timestamp:
May 20, 2016, 8:48:17 PM (8 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • processus_thread

    v2 v3  
    33[[PageOutline]]
    44
    5 == 1) création d’un processus dans un cluster distant ==
     5== __1) descripteur de processus__ ==
    66
    7 === 1.1) descripteur de processus ===
     7Le PID (Process Identifier) est codé sur 32 bits, et il est unique dans le système : les 16 bits de poids fort contiennent
     8les 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.
     9Le 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).
    810
    9 Le descripteur de processus est défini par la structure task_t, et il contient les informations suivantes
     11Le 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__ ==
    1023
    1124Ce 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.
     
    1326On 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.
    1427
    15 1.1) fork()
     28=== 2.1) fork() ===
     29
    1630Le processus père P s’exécute sur un coeur du cluster Z. Il fait un appel système fork() qui a principalement
    1731pour rôle de sélectionner un cluster cible X qui deviendra le cluster propriétaire du processus fils F, et de dupliquer
     
    2741et rend la main au processus P.
    2842
    29 1.2) exec()
     43=== 2.2) exec() ===
     44
    3045Une 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’.
     46Cette 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’.
    3347Quand le processus P’ sur le cluster Z reçoit une réponse positive pour  cette EXEC_RPC,  le processus P’ intermédiaire
    3448se suicide.
     
    3751Le code binaire (segments code et data) sera chargé dans la mémoire du cluster cible, lors du traitement des défauts de page.
    3852
    39 2) Création d’un thread dans un cluster distant
     53== __3) descripteur de thread__ ==
    4054
    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”.
     55Il 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.
    4360
    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
     61QUESTION pourquoi distingue-t-on les thread KERNEL et les thread RPC ?
     62
     63Un thread peut être dans 6 états décrits dans la section portant sur l'ordonnancement des thread.
    5164
    5265L’OS attribue à un thread d’un processus P un identifiant unique dans le processus. Ce TRDID est codé sur 32 bits,
     
    5467du coeur assigné au thread (par exemple  X =  TRDID[31:24] / Y = TRDID[25:16] / L = TRDID[15:8] / LTID = TRDID[7:0]).
    5568
     69ATTENTION : ce TRDID n'est pas actuellement implémentés dans ALMOS-MK.
     70
    5671Les 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 thread
    60 - STATE : CREATED / RUNNABLE / RUNNING / BLOCKED / COMPLETED
    61 - 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 thread
     72 * 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
    6580- etc.
     81
     82== __4) Création d’un thread user dans un cluster distant__ ==
    6683
    6784N’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’
     
    6986est effectué par l’instance du noyau du cluster M. Le cluster propriétaire du processus P peut être un troisième cluster Z.
    7087
    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,
     88Seul 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)
     89Ceci 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. 
     90La 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,
    7691alors que la TRDL(P,Z) du cluster Z propriétaire de P doit contenir tous les threads de P.
    7792
    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 ===
    8094
    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 …
     95Le 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.
     96Le 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.
    8397
    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
     100Le noyau du cluster M vérifie s’il possède une copie du descripteur du processus P.
     101Si 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).
     102Il initialise les structures VSL et FDT en utilisant des remote_memcpy() depuis le cluster Z vers le cluster M.
     103La structure PT(P,M) reste vide, et se remplira à la demande lors du traitement des défauts de page.
     104Quand 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).
    90105Finalement, il enregistre T’ dans l’ordonnanceur du coeur sélectionné, et renvoie le TRDID dans la réponse RPC au cluster Z.
    91106
    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 ===
    95108
    96 3) Destruction d’un thread
     109Le noyau du cluster Z propriétaire de P alloue un descripteur de thread et l’enregistre dans sa TRDL(P,Z).
     110Cette TRDL(P,Z)  doit en effet contenir la totalité des descripteurs de threads du processus P.
     111Puis le noyau de Z renvoie une réponse RPC au cluster K.
    97112
    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
     115La destruction d’un thread TRDID s’exécutant sur un cluster K est déclenchée :
    99116- soit par le thread lui-même (appel système pthread_exit() ),
    100117- soit par le noyau du cluster hôte K où s’exécute le thread,
     
    102119Dans tous les cas, c’est le noyau du cluster hôte K, qui pilote cette destruction.
    103120
    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 ===
    106122
    107 3.2) Le noyau du cluster Z propriétaire de P met à jour sa TRDL(P,Z), en supprimant le thread TRDID,
    108 puis envoie la réponse RPC au cluster K.
     123Le noyau du cluster K envoie une THREAD_EXIT_RPC au cluster Z propriétaire du processus P,
     124pour qu’il mette à jour la TRDL(P,Z) qui contient tous les thread de P. Les arguments sont le PID et le TRDID.
    109125
    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
     128Le 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.
    111133Lors 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
    112134allouée pour le descripteur de thread dans le cluster K est libérée.
    113135
    114 4) Destruction d’un processus
     136== __5) Destruction d’un processus__
    115137
    116 Cette section n’est qu’une ébauche… [AG]
    117 
    118 On suppose que la destruction d’un processus P est déclenchée
     138La destruction d’un processus P est déclenchée :
    119139- soit par un thread du processus P s’exécutant sur un cluster X quelconque (appel système exit() ),
    120140- soit par le noyau du cluster Z propriétaire P,
     
    122142Dans tous les cas, c’est le noyau du cluster Z propriétaire de P, qui pilote cette destruction.
    123143
    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 ===
    126145
    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.
     146Si 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.
     147L’argument est le PID du processus P.
    129148
    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 ===
    133150
    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
     151Pour 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.
     152Dans chaque cluster M, le noyau recevant une TASK_EXIT_RPC enregistre le signal KILL dans les descripteurs detous les threadsde P.
     153Quand 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
     157Lorsque toutes les réponses au TASK_EXIT_RCP ont été reçues par le cluster Z, celui-ci libère toutes les structures
    135158de données allouées au processus P dans le cluster Z.