Changes between Version 18 and Version 19 of rpc_implementation

Timestamp:

Jul 21, 2017, 3:49:55 PM (7 years ago)

Author:

alain

Comment:

--

rpc_implementation

@@ -31 +31 @@
 == 3) Traitement parallèle des RPCs ==
 
-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. 
+Dans 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. 
 
 L'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.
@@ -48 +48 @@
  * Le champs '''response''' est un entier qui défini le nombre de réponses attendues.
  * Le champs '''args''' est un tableau de 10 uint64_t contenant les arguments d'entrée et de sortie.
-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()''.
+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()'', pour signaler qu'il a terminé le traitement demandé.
 L'utilisation et l'interprétation du tableau '''args''' dépend de chaque type de RPC.