Brevet FR2731533A1 — publié le 19960913

Synchronisation et communication conjointes et concomitantes performantes par sémaphore entre des processus indépendants et banalisés sur tout système Unix ou équivalent. La présente invention conceme une architecture informatique de processus sur le système UNIX ou sur un système équivalent pour l'implémentation de moniteurs transactionnels performants. Cette architecture s'appuie sur un mécanisme original de synchronisation et de communication conjointe par un sémaphore unique entre des processus indépendants et banalisés. 2 Etat antérieur de la technique. L'intérêt d'un moniteur transactionnel sur le système UNIX provient de l'inadaptation du mécanisme classique de mitose dynamique de processus lorsque le nombre de processus à créer dépasse un certain seuil. En effet, dés que le nombre de transactions à gérer dépasse l'ordre du millier, toute proportion gardée par ailleurs, on observe une saturation du système et une dégradation notable des performances tant au niveau des temps de réponse individuel qu'au niveau du débit global du système. Cette saturation provient de l'architecture classique des applications sur UNIX, architecture qui s'appuie sur la mitose dynamique du processus initial, à savoir le shell de connexion de l'utilisateur. Le coût des opérations de duplication de processus -- dénommée fork en UNIX -- et de chargement puis d'exécution d'un programme -- dénommé exec en UNIX -- ainsi que le coût de commutation de processus sont à l'origine de cet écroulement des performances. Puisqu'on ne peut agir ni sur les performances des primitives fork et exec , ni sur le temps de commutation entre 2 processus, un des palliatifs à ce problème de performance, consiste à définir des processus serveurs , indépendants, banalisés et chargés une fois pour toute en mémoire puis à distribuer les requêtes par des processus clients sur ces dits serveurs avec les moyens idoines de synchronisation et de communication. L'intérêt de cette approche est de remplacer la mitose dynamique et systématique du processus initial par une mitose unique qui transforme un surcoût variable itératif en surcoût fixe indépendant du nombre de requêtes.Par ailleurs, cette approche contribue à la diminution du nombre total de processus du système, ce qui repousse d'autant les limites du système pour une configuration donnée. Un serveur est banalisé lorsque son contexte est indépendant des clients et des requêtes qu'il reçoit et en particulier qu'il ignore l'identification du client. Toute architecture de moniteur transactionnel qui s'appuie sur des serveurs banalisés et indépendants implique une identification des requêtes elle même et de l'émetteur de ces requêtes. Ainsi, un serveur banalisé ne connaît pas à priori le ou les clients qu'il doit servir. Ce type d'architecture doit donc comporter d'une part, un mécanisme d'identification des clients et des serveurs et d'autre part un mécanisme de synchronisation interprocessus -- entre clients et serveurs, et entre les clients entre eux -- afin de réguler les requêtes concurrentes de plusieurs clients sur un même serveur. La synchronisation et la communication entre des processus indépendants sur un système UNIX sont usuellement assurées par les communications interprocessus (dénommés IPC dans la terminologie UNIX), à savoir, soit des tubes qui véhiculent un flot d'information unidirectionnel, soit des files d'attente qui transmettent des messages ou encore des sémaphores. Chacun de ces mécanismes de communication possèdent des avantages et des inconvénients qu'on peut classer selon les critères suivants: Synchronisation, Communication, Performance et Contraintes pour le sujet qui nous intéresse. Un tube assure à la fois la synchronisation entre 2 processus ainsi que la communication d'information par le transfert unidirectionnel d'un flot de donnée entre les 2 extrémités du tube. Les performances d'un tube sont si faibles qu'il est complètement inadapté à l'implémentation d'applications transactionnelles lourdes avec plusieurs milliers de terminaux devant communiquer entre eux. Une file d'attente assure de même la synchronisation ainsi que la communication d'information par des messages de longueur variable qu'elle véhicule entre les 2 processus indépendants et banalisés. Une file d'attente gère des messages de longueur dynamique mais prédéterminée à l'avance, longueur qui varie de 1 à 16384 par incrément de puissance de 2 (4, 8, 16, 64, 128, 256, ...etc.). Les performances d'une file d'attente sont satisfaisantes pour qu'on l'utilise effectivement dans l'implémentation de moniteurs transactionnels. Cependant, les structures de gestion inteme du noyau Unix et le paramétrage inhérent à ce type de communication sur le nombre et la limitation de la taille des messages introduisent un coût fixe obligatoire dans le traitement de chaque message, surcoût inutile la plupart du temps.Par ailleurs, il est impossible de véhiculer des messages de grande taille (de l'ordre du plusieurs Mega octets par exemple) car les structures de gestion de ces files d'attente sont stockées dans le noyau Unix. La conjonction de ces contraintes avec un nombre important de processus concourants rendent ce type de fonction inadaptée à la gestion de système transactionnel important. Un sémaphore n'assure que la fonction de synchronisation entre 2 processus mais avec bien entendu les meilleures performances possibles pour cette fonction. C'est pourquoi,habituellement on associe avec le sémaphore une zone de communication commune entre les 2 processus pour assurer la fonction de communication, zone généralement implémentée sur UNIX par de la mémoire partagée. Cependant, cette solution de synchronisation par sémaphore et communication par mémoire partagée ne convient pas lorsqu'on manipule des processus indépendants et banalisés. En effet, spécifier qu'un processus est indépendant et banalisé implique qu'il ne possède aucune connaissance immédiate du contexte de ses processus congénères et en particulier qu'il ne connaît pas l'identification du processus appelant au moment de la synchronisation. Appliquons cette solution technique au modèle client/serveur pour démontrer ce propos. Soit un processus client dit synchroniseur et un processus serveur dit synchronisé , tous les deux banalisés et indépendants. Au démarrage du système, le processus serveur enregistre son identification ainsi que le numéro de sémaphore sur lequel il est synchronisé dans un gestionnaire global des services. Ce gestionnaire de service permet à tout instant de connaître quel service est rendu par tel serveur et en particulier renseigne le demandeur sur les caractéristiques du serveur , à savoir son identifiant et le numéro de son sémaphore de synchronisation. Le processus client requiert un service qu'il sait être rendu par le processus serveur en question par l'interrogation du gestionnaire de services. Le processus client dépose dans la mémoire partagée l'information qui sera traitée ultérieurement par le processus serveur , puis grâce au gestionnaire des services, retrouve le numéro du sémaphore de synchronisation du serveur , serveur qu'il libère par une opération classique de type V . Le processus synchronisé démarre alors son activité qui consiste à traiter le message du processus synchroniseur . Mais le processus synchronisé ne connaît pas l'identification du processus synchroniseur et n'a aucun moyen direct et efficace de le connaître. II n'est donc pas en mesure de traiter le message du client ce qui rend caduque ce type de synchronisation/communication pour ce modèle d'architecture client/serveur. C'est pourquoi sur Unix, la fonction essentielle d'un moniteur transactionnel -- à savoir la synchronisation et la communication conjointe et concomitante entre deux processus indépendants et banalisés -- utilise d'ordinaire les files d'attente du système Unix, files d'attente qui remplissent correctement cette fonction mais avec les problèmes, limites et restrictions décrites ci dessus. 3 Exposé de l'invention. Contrairement aux approches précédemment citées, I'invention en question s'appuie sur l'utilisation d'un sémaphore unique pour transmettre une information pertinente entre 2 processus banalisés et indépendants en même temps qu'il sert de mécanisme de synchronisation. C'est la conjonction simultanée du principe de synchronisation et de cette communication au sein d'un même sémaphore associée à une organisation inteme spéciale des processus clients et des processus serveurs qui fait l'originalité innovante de cette architecture. 3.1 Architecture globale du système Soit une architecture de moniteur transactionnel sur le système UNIX avec les éléments suivants: Un système de gestion globale des informations qu'on appelle moniteur transactionnel . N terminaux de connexion par lesquels les utilisateurs transmettent des demandes de transaction ou services, terminaux gérés par des processus clients . N processus dénommés clients attachés à N terminaux, indépendants entre eux et possédant chacun un sémaphore identifié par un numéro de sémaphore unique attribué par UNIX à sa création. Chaque processus possède lui aussi un numéro d'identification unique, en abrégé Cid , attribué par le moniteur qui varie de 1 à N. T processus dénommés serveurs banalisés, indépendants entre eux et indépendants des processus clients , offrant chacun un service , indépendant de tout terminal, et possédant chacun un sémaphore identifié par un numéro unique de sémaphore attribué par le système UNIX. Une fonction du moniteur, accessible à la fois aux clients et aux serveurs , qui indique quel serveur répond à une demande de service en retoumant l'identification et le numéro du sémaphore du serveur en question. Les clients traitent les requêtes des utilisateurs en demandant l'exécution de services aux serveurs . Une fois l'association entre un client et un serveur faite par sémaphore, un client échange des informations avec le serveur via un tampon unique qui lui est propre, tampon attribué à chaque client par le moniteur lors de la connexion initiale d'un utilisateur. Au cours d'une session de plusieurs transactions, ce tampon est partagé dynamiquement entre le client et un serveur lors du traitement du service. Une fois le service rendu, ce tampon n'est plus accessible par le serveur mais reste accessible par le client . L'information pertinente transmise via le sémaphore est en fait le numéro d'identification unique "Cid" du client , qui permet au serveur d'identifier simplement, directement et avec les meilleures performances possibles quel est le client demandeur du service. Outre sa fonction habituelle de synchronisation, le sémaphore rempli donc ici, la fonction de communication conjointe essentielle à l'implémentation de système transactionnel à partir de serveur banalisés sans mitose dynamique de processus.La transmission du "Cid" par le sémaphore assure donc l'établissement temporaire d'une association de synchronisation et de communication entre un client et un serveur , ceci pendant la durée d'exécution du service. Dans la littérature anglaise classique des systèmes transactionnels, on appelle cette association le (( mapping/unmapping de processus ou bien encore le mode pseudo-conversationnel . 3.2 Constitution des sémaphores clients et serveurs de chaque processus. Chaque sémaphore serveur est constitué par un tableau à 3 éléments, éléments indissociables. > Le premier élément constitue le sémaphore de synchronisation synchroniseur/synchronisé à proprement parlé, sur lequel les clients effectuent des opérations de synchronisation classiques de type V et les serveurs des opérations de type P . > Le second élément du tableau constitue la zone mémoire dans laquelle le processus client va déposer son identification lors de l'opération V . > Le troisième élément est un sémaphore d'exclusion mutuelle qui sérialise l'accès au serveur lorsque plusieurs clients demandent le même service en même temps. Chaque sémaphore client est constitué par un tableau à 2 éléments. > Le premier constitue le sémaphore de synchronisation serveur/client à proprement parler sur lequel les serveurs effectuent des opérations de synchronisation classiques de type V V et les clients des opérations de type p ". > Le second élément du tableau constitue la zone mémoire dans laquelle le processus serveur va déposer son identification lors de l'opération V . A l'initialisation du système, le moniteur lance avec une commande tous les processus serveurs qui peu de temps après, restent bloqués sur leur sémaphore de synchronisation dans l'attente d'une libération en provenance d'un client . 3.3 Synchronisation et communication entre processus banalisés et indépendants. Pour illustrer le mécanisme de base de cette invention, on décrit ci après le flot de contrôle qui explique la dynamique du système sur les figures jointes pour 2 services particulier. Dans l'exemple, un utilisateur demande l'exécution d'une transaction ou d'un service en donnant le nom de la transaction ou du service suivi par un ou plusieurs paramètres. Ces figures montrent l'exécution des requêtes A et T T pour le client numéro 2 du système transactionnel. Notez qu'afin d'alléger les explications, le troisième élément de chaque sémaphore serveur est omis dans sa représentation picturale ce qui n'enlève rien à la généralité du mécanisme mais simplifie l'exposé et la compréhension du flot de contrôle. > Figure 1: L'architecture du système repose sur la description en mémoire partagée des caractéristiques de chaque client et de chaque serveur ainsi que sur la disponibilité de tampons de communication attribué a chaque client . Chaque client est identifié par un numéro Cid unique et possède son propre sémaphore SSi. De même, chaque serveur est identifié par un Sid et possède son propre sémaphore Ssj . Dans un schéma général, il y a N processus Clients et T processus serveurs . Une dernière table indique quel service est rendu par tel serveur . > Figure 2: Aprés le démarrage du système, les clients attendent l'entrée d'une requête de service depuis leur terminal respectif et chaque serveur attend une synchronisation sur son propre sémaphore. > Figure 3: Après la réception et analyse de la requête A , le client 2 ), assigne le message de la requête dans le tampon numéro 2. Il signale ensuite le serveur A ) > par une opération V sur le sémaphore SSA auquel il transmet aussi son numéro du client Cid en question, c'est à dire 2 en l'occurrence. Ensuite, il s'endort sur son propre sémaphore SC2 dans l'attente de la réponse du serveur . > Figure 4: Un fois l'opération de synchronisation V achevée, le client 2 se met en attente de la réponse du serveur A par une opération P sur son propre sémaphore SC2. > Figure 5: Dès lors, le serveur A libéré par l'opération V précédante, récupère l'identification du client 2 dans son sémaphore, ce qui lui permet d'accéder au tampon de communication numéro 2 pour lire les paramètres de la requête. > Figure 6: Après traitement de la requête, le serveur A notifie dans la réponse le nom du service suivant à exécuter et dépose cette réponse dans le tampon numéro 2 et réveille le client 2 par une opération V sur le sémaphore SC2. Figure 7: Le serveur A boucle alors sur lui même dans l'attente d'un autre message par une opération P sur son propre sémaphore SSA. Figure 8: Libéré par l'opération V de la figure 6, le client 2 reprend le contrôle du tampon 2 et s'enquiert du service suivant à exécuter (C'est le service T dans l'exemple, service calculé par le serveur A ). Figure 9: Le service T est rendu par le serveur T . Le client 2 assigne le nouveau message au tampon 2 et signale le serveur T de la même manière qu'à la figure 3. Figure 10: Comme à la figure 5, le serveur T récupère l'identification du client 2 dans son sémaphore, accède au tampon 2 et traite la requête. Figure 11: Le serveur T dépose la réponse dans le tampon numéro 2, réveille le client 2 puis boucle sur lui même dans l'attente d'un autre message. Figure 12: Le client 2 reprend le contrôle du tampon 2 et renvoie le message sur le terminal correspondant. Les mécanismes démontrés ci dessus s'appliquent simultanément et de manière indépendante à tous les clients et serveurs d'un système transactionnel sans limite structurelle, hormis bien sûr celle de la configuration de la machine. 4 Revendications 1) Structure de processus indépendants, banalisés et communicants, chacun d'entre eux étant synchronisé par un seul sémaphore, sur tout système UNIX ou système équivalent qui offre des fonctionnalités de sémaphores similaires, caractérisée par l'association d'un sémaphore unique par processus, sémaphore qui, outre la fonction de synchronisation qui lui est propre, assure aussi la fonction de communication conjointe et concomitante d'une information pertinente entre le processus dit émetteur ou synchroniseur et celui dit récepteur ou synchronisé , information qui permet au processus récepteur d'identifier immédiatement le processus émetteur de façon simple, rapide et sans autre mécanisme auxiliaire. 2) Architecture de moniteur transactionnel performant organisé autour de processus banalisés, indépendants et communicants décrit selon la revendication 1.