Changes between Version 17 and Version 18 of rpc_implementation


Ignore:
Timestamp:
Jul 21, 2017, 3:43:40 PM (7 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • rpc_implementation

    v17 v18  
    1111== 1) Hypothèses concernant la plate-forme matérielle ==
    1212
    13 L'architecture cible est généralement clusterisée, ce qui signifie que l'espace d'adressage physique est partagé par tous les CPUs, mais qu'il est partitionné entre les différents clusters'. ALMOS-MKH supporte les architectures cibles respectant les contraintes suivantes:
     13L'architecture cible est généralement clusterisée, ce qui signifie que l'espace d'adressage physique est partagé par tous les CPUs, mais qu'il est partitionné entre les différents clusters. ALMOS-MKH supporte les architectures cibles respectant les contraintes suivantes:
    1414 * Les adresses physiques, aussi appelées adresses étendues, sont codées sur 64 bits.
    1515 * La taille maximale de l'espace adressable physique accessible dans un unique cluster est définit par le paramètre global CONFIG_CLUSTER_SPAN qui est une puissance de 2. Elle vaut 4 Goctets pour TSAR, mais peut posséder une valeur plus grande pour d'autres architectures. Une adresse physique est donc divisée en deux parties: le champs '''LPA''' est l'adresse physique locale dans un cluster, et le champs '''CXY''' est le numéro identifiant un cluster particulier.
    … …  
    2424N'importe quel thread client s'exécutant sur n'importe quel CPU de n'importe quel cluster peut envoyer une RPC vers n'importe quel cluster serveur, identifié par son index CXY.
    2525
    26 Il existe dans chaque cluster une FIFO logicielle, appelée RPC_FIFO, et possédant à priori N écrivains et M lecteurs. N est le nombre de thread clients, a priori non borné. M est le nombre de thread serveurs dont le nombre maximal dans un cluster est défini par le paramètre de configuration CONFIG_RPC_THREAD_MAX.
     26Il existe dans chaque cluster une FIFO logicielle, appelée "rpc_fifo", qui est une variable globale, membre de la structure "cluster_manager" définie dans chaque cluster.
     27Cette FIFO possède N écrivains et M lecteurs. N est le nombre de thread clients, a priori non borné. M est le nombre de thread serveurs dont le nombre maximal dans un cluster est défini par le paramètre de configuration CONFIG_RPC_THREAD_MAX.
    2728 * Pour synchroniser les accès concurrents entre écrivains, la RPC_FIFO imlémente un mécanisme de ticket garantissant que les clients pourront stocker leurs requêtes dans l'ordre d'attribution des tickets.
    28  * pour synchroniser les accès concurrents entre lecteurs, ALMOS-MK implémente un ''light-lock'', qui est un verrou non bloquant enregistrant l'identité du premier lecteur qui obtient  le verrou. Ce verrou est non bloquant, puisque tout échec signifie qu'un autre lecteur a gagné, et se charge d'effectuer le traitement. 
     29 * pour synchroniser les accès concurrents entre lecteurs, ALMOS-MK implémente un ''light-lock'', qui est un verrou non bloquant enregistrant l'identité du premier lecteur qui obtient  le verrou. Ce verrou est non bloquant, puisque tout échec signifie qu'un autre lecteur a gagné, et que le gagnant se charge d'effectuer le traitement. 
    2930
    3031== 3) Traitement parallèle des RPCs ==
    3132
    32 Les threads serveurs chargé 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. 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''. 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.
     33Les 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.
    3334
    34 L'activation/désactivation d'un RPC_THREAD est implémentée comme un bit particulier du vecteur de bit représentant les causes de blocages d'un thread.
     35L'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.
    3536
    3637== 4) Format d'une RPC ==
    3738
    3839Il existe différents types de RPC :
    39  * Une RPC ''simple bloquante'' est envoyée à un seul serveur, et attend une seule réponse.
    40  * Une RPC ''multicast bloquante'' est envoyée à N serveurs, et attend N réponses.
     40 * Une RPC ''simple bloquante'' est envoyée à un seul serveur, et et le thread client se bloque en attendant une seule réponse.
     41 * Une RPC ''multicast bloquante'' est envoyée à N serveurs, et le thread client se bloque en attendant N réponses.
    4142 * Une RPC ''simple non bloquante'' est envoyée à un seul serveur et n'attend pas de réponse.
    4243 * Une RPC ''multicast non bloquante'' est envoyée à N serveurs et n'attend pas de réponse.