Changes between Version 3 and Version 4 of processus_thread


Ignore:
Timestamp:
May 20, 2016, 9:05:53 PM (8 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • processus_thread

    v3 v4  
    2020- ENV : variables d’environnement du processus,
    2121
    22 == __2) création d’un processus dans un cluster distant__ ==
    23 
    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.
    25 La création d’un processus distant utilise le mécanisme fork / exec.
    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.
    27 
    28 === 2.1) fork() ===
    29 
    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
    31 pour rôle de sélectionner un cluster cible X qui deviendra le cluster propriétaire du processus fils F, et de dupliquer
    32 le processus P dans le cluster Z. Le choix du cluster cible devrait en principe s’appuyer sur la DQDT, bien que
    33 celle-ci ne soit pas implémentée actuellement dans ALMOS-MK.
    34 
    35 L’appel system fork() crée dans le cluster Z un nouveau descripteur de processus pour le processus clone P’, ainsi qu’un descripteur de thread  pour le thread principal attaché au processus P’.
    36 Le descripteur du processus P’ contient en particulier la VSL(P’,Z), la PT(P’,Z), la FDT(P’,Z) qui sont des copies des tables correspondantes du processus P. En revanche la TRDL(P’,Z) ne contient que le thread nouvellement créé, ce qui signifie
    37 que le processus P’ clone est mono-thread.
    38 Puis l’appel système fork() demande au cluster cible X l’allocation d’un PID au moyen d’une FORK_RPC (bloquante), en transmettant en argument l’adresse étendue du descripteur de processus P’. Cette adresse est enregistrée dans la
    39 table des processus du cluster, et le PID est enregistré dans le descripteur du processus P’ du cluster Z.
    40 Finalement, le fork() enregistre le nouveau thread  dans l’ordonnanceur du coeur du cluster Z qui exécute le fork(),
    41 et rend la main au processus P.
    42 
    43 === 2.2) exec() ===
    44 
    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.
    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’.
    47 Quand le processus P’ sur le cluster Z reçoit une réponse positive pour  cette EXEC_RPC,  le processus P’ intermédiaire
    48 se suicide.
    49 
    50 Une fois que les structures sont initialisées, le thread principal du processus fils est attaché à l'ordonnanceur du cœur cible.
    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.
    52 
    53 == __3) descripteur de thread__ ==
     22== __2) descripteur de thread__ ==
    5423
    5524Il existe quatre types de threads :
     
    5928 * un thread '''RPC''' est créé et ou activé par le noyau pour exécuter une ou plusieurs RPCs.
    6029
    61 QUESTION pourquoi distingue-t-on les thread KERNEL et les thread RPC ?
     30QUESTION pourquoi distingue-t-on les thread KERNEL et les thread RPC ? [AG]
    6231
    63 Un thread peut être dans 6 états décrits dans la section portant sur l'ordonnancement des thread.
     32Un thread peut être dans 6 états décrits dans la section [wiki:  portant sur l'ordonnancement des thread.
    6433
    6534L’OS attribue à un thread d’un processus P un identifiant unique dans le processus. Ce TRDID est codé sur 32 bits,
     
    6736du coeur assigné au thread (par exemple  X =  TRDID[31:24] / Y = TRDID[25:16] / L = TRDID[15:8] / LTID = TRDID[7:0]).
    6837
    69 ATTENTION : ce TRDID n'est pas actuellement implémentés dans ALMOS-MK.
     38ATTENTION : ce TRDID n'est pas actuellement implémentés dans ALMOS-MK. [AG]
    7039
    7140Les principales informations stockées dans le descripteur de thread sont les suivantes :
     
    7948 * SIGNALS : vecteur de bits permettant d’enregistrer les signaux reçus par le thread
    8049- etc.
     50
     51== __3) création d’un processus dans un cluster distant__ ==
     52
     53Ce 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.
     54La création d’un processus distant utilise le mécanisme fork / exec.
     55On rappelle qu’il existe un ordonnanceur par coeur, qui a pour rôle d’ordonnancer les threads qui ont été placés sur ce coeur.
     56
     57=== 3.1) fork() ===
     58
     59Le processus père P s’exécute sur un coeur du cluster Z. Il fait un appel système fork() qui a principalement
     60pour rôle de sélectionner un cluster cible X qui deviendra le cluster propriétaire du processus fils F, et de dupliquer
     61le processus P dans le cluster Z. Le choix du cluster cible devrait en principe s’appuyer sur la DQDT, bien que
     62celle-ci ne soit pas implémentée actuellement dans ALMOS-MK.
     63
     64L’appel system fork() crée dans le cluster Z un nouveau descripteur de processus pour le processus clone P’, ainsi qu’un descripteur de thread  pour le thread principal attaché au processus P’.
     65Le descripteur du processus P’ contient en particulier la VSL(P’,Z), la PT(P’,Z), la FDT(P’,Z) qui sont des copies des tables correspondantes du processus P. En revanche la TRDL(P’,Z) ne contient que le thread nouvellement créé, ce qui signifie
     66que le processus P’ clone est mono-thread.
     67Puis l’appel système fork() demande au cluster cible X l’allocation d’un PID au moyen d’une TASK_FORK_RPC, en transmettant en argument l’adresse étendue du descripteur de processus P’. Cette adresse est enregistrée dans la table des processus du cluster, et le PID est enregistré dans le descripteur du processus P’ du cluster Z.
     68Finalement, le fork() enregistre le nouveau thread  dans l’ordonnanceur du coeur du cluster Z qui exécute le fork(), et rend la main au processus P.
     69
     70=== 3.2) exec() ===
     71
     72Une 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 TASK_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.
     73Cette 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’.
     74Quand le processus P’ sur le cluster Z reçoit une réponse positive pour  cette EXEC_RPC,  le processus P’ intermédiaire
     75se suicide.
     76
     77Une fois que les structures sont initialisées, le thread principal du processus fils est attaché à l'ordonnanceur du cœur cible.
     78Le code binaire (segments code et data) sera chargé dans la mémoire du cluster cible, lors du traitement des défauts de page.
    8179
    8280== __4) Création d’un thread user dans un cluster distant__ ==