Changes between Version 18 and Version 19 of rpc_implementation


Ignore:
Timestamp:
Jul 21, 2017, 3:49:55 PM (4 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • rpc_implementation

    v18 v19  
    3131== 3) Traitement parallèle des RPCs ==
    3232
    33 Les threads serveurs chargés de traiter les RPCs  appartiennent à un ''pool'' de  threads spécialisés appelés RPC_THREAD. Un RPC_THREAD du cluster serveur est activé chaque fois que l'O.S. s'exécutant sur un coeur quelconque du cluster détecte que la RPC_FIFO est non-vide, et qu'il parvient à acquérir la propriété de la FIFO grâce au mécanisme de ''light-lock''. Si la liste des RPC_THREADs oisifs est vide, un nouveau RPC thread est dynamiquement créé. Le RPC_THREAD s'exécute alors avec la priorité la plus élevée et se charge de traiter toutes les requêtes RPC présentes dans la RPC_FIFO avant de libérer la FIFO. Si un RPC_THREAD doit attendre la disponibilité d'une ressource, il se bloque sur la condition particulière associée à cette ressource, et déclenche une opération d'ordonnancement, après avoir libéré la RPC_FIFO, pour permettre le traitement d'autres RPCs. Il y a donc à tout instant au plus un RPC_THREAD propriétaire  de la RPC_FIFO, et possédant le droit de consommer une nouvelle RPC. Mais il peut donc exister plusieurs RPC_THREAD actifs, traitant chacun une RPC en cours de traitement. Lorsqu'un RPC thread a terminé l'exécution d'un service, il le signale au thread client, et cesse son exécution. Si le nombre courant de RPC_THREADs est inférieur au paramètre CONFIG_RPC_THREAD_MAX, il s'enregistre dans la liste des RPC_THREADs oisifs et se désactive; sinon, il se suicide.
     33Dans chaque cluster, les threads serveurs chargés de traiter les RPCs  appartiennent à un ''pool'' de  threads spécialisés appelés RPC_THREAD. Un RPC_THREAD du cluster serveur est activé chaque fois que l'O.S. s'exécutant sur un coeur quelconque du cluster détecte que la RPC_FIFO est non-vide, et qu'il parvient à acquérir la propriété de la FIFO grâce au mécanisme de ''light-lock''. Si la liste des RPC_THREADs oisifs est vide, un nouveau RPC thread est dynamiquement créé. Le RPC_THREAD s'exécute alors avec la priorité la plus élevée et se charge de traiter toutes les requêtes RPC présentes dans la RPC_FIFO avant de libérer la FIFO. Si un RPC_THREAD doit attendre la disponibilité d'une ressource, il se bloque sur la condition particulière associée à cette ressource, et déclenche une opération d'ordonnancement, après avoir libéré la RPC_FIFO, pour permettre le traitement d'autres RPCs. Il y a donc à tout instant au plus un RPC_THREAD propriétaire  de la RPC_FIFO, et possédant le droit de consommer une nouvelle RPC. Mais il peut exister plusieurs RPC_THREAD actifs, traitant chacun une RPC en cours de traitement. Lorsqu'un RPC thread a terminé l'exécution d'un service, il le signale au thread client, et cesse son exécution: Si le nombre courant de RPC_THREADs est inférieur au paramètre CONFIG_RPC_THREAD_MAX, il s'enregistre dans la liste des RPC_THREADs oisifs et se désactive; sinon, il se suicide.
    3434
    3535L'activation/désactivation d'un RPC_THREAD est implémentée par un bit particulier du vecteur de bit représentant les causes de blocages d'un thread.
     
    4848 * Le champs '''response''' est un entier qui défini le nombre de réponses attendues.
    4949 * Le champs '''args''' est un tableau de 10 uint64_t contenant les arguments d'entrée et de sortie.
    50 Pour une RPC bloquante, le client initialise le champs '''response''' avec le nombre de réponses attendus, et chaque serveur concerné le décrémente au moyen d'un accès ''remote_atomique_add()''.
     50Pour une RPC bloquante, le client initialise le champs '''response''' avec le nombre de réponses attendus, et chaque serveur concerné le décrémente au moyen d'un accès ''remote_atomique_add()'', pour signaler qu'il a terminé le traitement demandé.
    5151L'utilisation et l'interprétation du tableau '''args''' dépend de chaque type de RPC.
    5252