FR3025907B1

FR3025907B1 - Mecanisme et procede pour permettre une communication entre un client et un serveur en accedant a des donnees de messages en memoire partagee.

Info

Publication number: FR3025907B1
Application number: FR1558362A
Authority: FR
Inventors: Christian Reynolds Decker; Troy Stephen Brown; Kevin Brett Chapman
Original assignee: GE Aviation Systems LLC
Current assignee: GE Aviation Systems LLC
Priority date: 2014-09-15
Filing date: 2015-09-09
Publication date: 2019-07-26
Anticipated expiration: 2035-09-09
Also published as: US20160080517A1; US10560542B2; BR102015020596A2; GB201516102D0; GB2532843B; GB2532843A; CA2902933A1; FR3025907A1; JP2016062606A; CN105426258B; CN105426258A

Abstract

Un mécanisme et un procédé pour permettre à au moins un client (40) d'accéder à des données dans une mémoire partagée (22) comportent une attribution de données présentes dans la mémoire partagée (22), la mémoire (22) étant configurée dans une pluralité de mémoires tampons (36), et l'accès aux données par un client (40) ou un serveur (50) sans verrouillage des données ni limitation d'accès aux données.

Description

Mécanisme et procédé pour permettre une communication entre un client et un serveur en accédant à des données de messages en mémoire partagée

Un équipement remplaçable en escale (LRU) est un élément modulaire d’un ensemble plus grand tel qu’un véhicule ou un aéronef et est conçu conformément à des spécifications pour assurer qu’il puisse être échangé et/ou remplacé en cas de panne. Par exemple, les LRU d’un aéronef peuvent comprendre des systèmes, capteurs, radios et autres équipements auxiliaires entièrement autonomes pour gérer et/ou exécuter des fonctions de l’aéronef. Dans l’environnement d’un aéronef, les LRU peuvent être conçus pour fonctionner suivant des critères particuliers de fonctionnement, d’interopérabilité et/ou de facteur d’échelle tels que ceux définis par les normes de la série ARINC.

Une pluralité de LRU peuvent être connectés par un réseau de données afin d’accéder à des données ou d’échanger des données dans une mémoire commune, ou partagée, d’un ordinateur de commande de vol ou autre système informatique. L’ordinateur de commande de vol ou un autre système informatique peut en outre gérer et/ou exécuter des fonctions de l’aéronef.

Dans une première forme de réalisation, un mécanisme pour permettre la communication entre au moins un client et au moins un serveur en accédant à des données de messages en mémoire partagée comporte une attribution de données présentes dans la mémoire partagée à au moins un mailslot, l’attribution étant accessible par une adresse constante prédéterminée, et une série de mémoires tampons pour le client/chacun des clients, chacune des mémoires tampons pouvant être commandée par l’un ou l’autre des client(s) et serveur(s) respectifs, le/les mailslot(s) ayant des références identifiant le/les client(s) et le/les serveur(s), le/les client(s) ayant un pointeur d’accès actif qui permet au(x) client(s) de manipuler directement des données de messages par l’intermédiaire d’une mémoire tampon commandée par le/les client(s), le/les serveur(s) ayant un pointeur d’accès actif qui permet au(x) serveur(s) de manipuler directement les données de messages par l’intermédiaire d’une mémoire tampon commandée par le/les serveur(s). Les pointeurs d’accès actif sont attribués parmi des mémoires tampons à l’aide d’opérations atomiques sans copier les données au niveau d’un système d’exploitation.

Dans une autre forme de réalisation, un procédé pour permettre la communication entre au moins un client et un serveur en accédant à des données de messages en mémoire partagée, le procédé comporte une attribution de données présentes dans la mémoire partagée à au moins un mailslot, l’attribution d’une seule adresse prédéterminée pour accéder au mailslot/à chaque mailslot, l’attribution d’un certain nombre de mémoires tampons pour le client/chacun des clients, chaque mémoire tampon pouvant être commandée par un client ou par un serveur, le nombre de mémoires tampons étant égal au nombre de transactions demandées par le client respectif, et l’attribution d’un pointeur d’accès actif de client depuis une mémoire tampon commandée par un client afin de passer de la commande de mémoire tampon par le client à une commande de mémoire tampon par le serveur, ce qui permet au serveur de manipuler directement les données de messages par l’intermédiaire d’un point d’accès actif de serveur. L’accès aux données de messages se fait à l’aide de pointeurs d’accès actif dirigés vers les mémoires tampons sans copier les données de messages au niveau d’un système d’exploitation. L'invention sera mieux comprise à l'étude détaillée de quelques modes de réalisation pris à titre d'exemples non limitatifs et illustrés par les dessins annexés sur lesquels : -la Figure 1 est une vue schématique de l’aéronef et du réseau de communication selon une forme de réalisation de l’invention ; -la Figure 2 est une illustration schématique d’une communication entre une pluralité de clients et/ou de serveurs accédant à la mémoire partagée, selon une forme de réalisation de l’invention ; -la Figure 3 est une illustration schématique de clients accédant aux mémoires tampons d’un mailslot, selon une forme de réalisation de l’invention ; -la Figure 4 est une illustration schématique d’espaces unidirectionnel et bidirectionnel de mémoire, selon une forme de réalisation de l’invention ; -la Figure 5 est une vue schématique d’un mécanisme permettant à des clients d’accéder aux données de messages en mémoire tampon, selon une forme de réalisation de l’invention ; -la Figure 6 est une vue schématique d’un mécanisme permettant à des clients d’effectuer une transaction de lecture/écriture dans une mémoire tampon, selon une forme de réalisation de l’invention ; et -la Figure 7 est une vue schématique d’un mécanisme pour diriger un client vers la mémoire tampon sûre, selon une forme de réalisation de l’invention.

Les formes de réalisation de la présente invention décrites sont illustrées dans le contexte d’un aéronef ayant un réseau de données interconnectant une mémoire commune ou partagée accessible à une pluralité de capteurs, systèmes, composants logiciels et/ou composants physiques de l’aéronef. Cependant, des formes de réalisation de l’invention peuvent être mises en œuvre dans tout contexte utilisant des clients et des serveurs accédant à une mémoire partagée commune ou unique. Par ailleurs, bien que l’on évoque ci-après des "clients" et des "serveurs", les formes de réalisation particulières décrites sont des exemples nullement limitatifs des clients et des serveurs. Des exemples supplémentaires de clients et de serveurs peuvent comprendre des unités discrètes distantes (via un réseau de données ou l’Internet) ou localisées, des applications, des processus informatiques, des threads de traitement, etc., ou toute combinaison de ceux-ci, qui accèdent à une mémoire partagée. Par exemple, une pluralité de "clients" peuvent être tous installés dans un même ordinateur ou une même unité de traitement, accédant à une mémoire vive commune (RAM).

Sur la Figure 1 est représenté un aéronef 8 ayant un fuselage 10 et au moins un moteur à turbine, représenté sous la forme d’un système de moteur gauche 12 et d’un système de moteur droit 14. Les systèmes de moteurs gauche et droit 12, 14 peuvent être sensiblement identiques. Bien que des moteurs 12, 14 à turbine soient représentés, l’aéronef peut comporter un plus petit nombre ou davantage de systèmes de moteurs, ou d’autres systèmes possibles de moteurs à propulsion, tels que des moteurs à hélices. En outre, l’aéronef 8 représenté comporte une pluralité de capteurs, systèmes et composants appelés collectivement équipements remplaçables en escale (LRU) 18, et au moins un serveur 20 ou unité de calcul, représentés sous la forme de deux systèmes de gestion de vol, ou ordinateurs de commande de vol, situés tout près l’un de l’autre, près du nez de l’aéronef 8. Au moins un des serveurs 20 peut en coutre comporter une mémoire 22. Les LRU 18 et les serveurs 20 peuvent communiquer entre eux par des lignes de transmission et/ou de communication définissant un réseau de communication de données 24, parcourant au moins une partie de l’aéronef 8. On peut citer comme exemples de LRU 18 les systèmes de gestion de vol et/ou les systèmes de maintenance embarqués. Des LRU supplémentaires 18 peuvent être inclus. Bien qu’un serveur 20 soit décrit, des formes de réalisation de l’invention peuvent comporter tout système informatique, ordinateur de vol ou système d’affichage affichant des données provenant de multiples systèmes.

La mémoire 22 peut comprendre une mémoire vive (RAM), une mémoire flash ou un ou plusieurs types différents de mémoire électronique portative, etc., ou n'importe quelle combinaison appropriée de ces types de mémoire. Les LRU 18 et/ou les serveurs 20 peuvent coopérer avec la mémoire 22 de façon que les LRU 18 et/ou les serveurs 20, ou n'importe quels programmes informatiques ou processus dans ceux-ci, puissent accéder à au moins une partie de la mémoire 22 (par exemple la "mémoire partagée" 22).

Au sens de la présente description, des "programmes" et/ou des "processus" peuvent comprendre tout ou partie d'un programme informatique ayant un jeu d'instructions exécutables pour commander la gestion et/ou l'exploitation du client respectif 18 et/ou du serveur respectif 20 et/ou des fonctions respectives de l’aéronef 8. Le programme et/ou les processus peut/peuvent comprendre un programme informatique qui peut comprendre des supports exploitables par ordinateur pour exécuter ou faire exécuter par ordinateur des instructions ou des structures de données stockées sur ceux-ci. Ces supports exploitables par ordinateur peuvent être n’importe quels supports existants, accessibles à un ordinateur polyvalent ou spécifique ou à une autre machine munie d'un processeur. Globalement, un tel programme informatique peut comprendre des routines, des programmes, des objets, des composants, des structures de données, des algorithmes, etc., qui ont pour effet technique d'exécuter des tâches particulières ou de mettre en œuvre des types de données abstraits particuliers. Les instructions exécutables par ordinateur, les structures de données correspondantes et les programmes constituent des exemples de code de programme pour exécuter l'échange d'information tel qu'il est présenté ici. Les instructions exécutables par ordinateur peuvent comprendre, par exemple, des instructions et des données, qui amènent un ordinateur polyvalent, un ordinateur spécifique, un automate ou une machine de traitement spécifique à exécuter une certaine fonction ou un certain groupe de fonctions. L’aéronef 8 représenté sur la figure 1 n’est qu’une représentation schématique d’une forme de réalisation de l’invention et sert à illustrer le fait qu’une pluralité de LRU 18 et de serveurs 20 peuvent se trouver partout dans l’aéronef 8. L’emplacement exact des LRU 18 et des serveurs 20 n’a aucun rapport avec les formes de réalisation de l’invention. En outre, un nombre plus grand ou plus petit de LRU 18 et/ou de serveurs 20 peut être inclus dans des formes de réalisation de l’invention.

Le réseau de communication 24 est représenté sous la forme d’un bus mais peut comprendre un certain nombre de connecteurs et d’interface de communication de données, par exemple un Ethernet ou des câbles à fibres optiques, et des composants d’acheminement et/ou de commutation, pour faciliter les liaisons de communication entre les LRU 18 et les serveurs 20. Par ailleurs, la configuration et le fonctionnement du réseau de communication 24 peuvent être définis par un ensemble commun de normes ou de réglementations applicables à des environnements aéronautiques particuliers. Par exemple, le réseau de communication 24 à bord d’un aéronef 8 peut être défini par, et/ou configuré selon, la norme ARINC 664 (A664), ou la norme ARINC 653 (A653).

La Figure 2 est une illustration schématique d’un système de communication 24 de données selon une forme de réalisation de l’invention. Une pluralité de LRU 18, comprenant chacun un ou plusieurs threads ou processus informatiques 26, ont accès à la mémoire partagée 22, représentée sous la forme d’une mémoire vive partagée. De plus, un ou plusieurs serveurs 20, comprenant chacun un ou plusieurs threads ou processus informatiques 28, ont également accès à la mémoire partagée 22. De la sorte, chaque processus 26, 28 peut avoir accès à la mémoire partagée 22.

La mémoire 22 est représentée comme comprenant en outre une attribution de données 30 à au moins un groupement, ou "mailslot" 32, placé à un emplacement adressable constant prédéterminé de la mémoire, ou "adresse constante" 34 de la mémoire 22. Au sens de la présente description, un "mailslot" peut comprendre un sous-ensemble prédéterminé de mémoire 22 affecté à une utilisation particulière de stockage de données pour l'aéronef 8. Par exemple, un mailslot unique 32 peut comprendre une attribution unique de données, notamment la vitesse propre de l'aéronef, tandis qu’un autre mailslot 32 peut comprendre une pluralité d'éléments de données avec ou sans relation entre elles, notamment des points de passage ou le plan de vol en cours. Des formes de réalisation de l’invention peuvent comporter des configurations dans lesquelles chaque mailslot individuel 32 utilise les mêmes définitions de données de messages, ou dans lesquelles différentes définitions de données de messages sont utilisées dans différents mailslots 32. Les mailslots 32 peuvent être organisés d'une façon séquentielle en partant de l'adresse constante 34, notamment sous la forme d'une liste à lien unique ; cependant, des structures supplémentaires d'organisation des mailslots 32 peuvent être conçues pour comprendre des matrices, des attributions variables pour chaque mailslot 32, etc., toutes ayant pour point de départ l'emplacement de l'adresse constante 34.

Chacun des processus 26, 28, et/ou respectivement des LRU 18 et des serveurs 20 est préalablement configuré pour comprendre l'adresse constante prédéterminée 34 de la mémoire partagée 22. En ce sens, chaque processus 26, 28, LRU 18 et/ou serveur 20 est préconfiguré pour identifier l'emplacement de l'adresse constante 34 et, par conséquent, du ou des mailslots 32 dont les données doivent être accessibles. Au sens de la présente description, chaque LRU 18 et/ou chaque processus LRU 26 peut être considéré comme un "client" pour accéder à des données dans la mémoire partagée 22, et chaque serveur 20 et/ou chaque processus serveur 28 peut être considéré comme un "serveur" pour accéder à des données dans la mémoire partagée 22. Des formes de réalisation supplémentaires peuvent être incluses, dans lesquelles des serveurs 20 exécutent des actions ou des fonctions similaires à celles de clients, et des clients exécutent des actions ou des fonctions similaires à celles de serveurs 20. De la sorte, sauf mention contraire, “clients” et “serveurs” peuvent exécuter des fonctions interchangeables. En outre, bien que les serveurs 20 et les LRU 18 soient représentés sous la forme de composants séparés, des formes de réalisation de l’invention peut comporter des serveurs 20 ou des clients installés dans les mêmes systèmes les uns que les autres et/ou être installés dans le même système que la mémoire partagée 22.

Dans une forme de réalisation de l'invention, le nombre de mailslots 32 dans la mémoire partagée 22 est prédéfini pendant l'initialisation de la mémoire 22, d'après un nombre connu de mailslots 32 accessibles aux clients et/ou serveurs. Dans une autre forme de réalisation de l'invention, le nombre de mailslots 32 est défini au moment de ou pendant l'exécution par le nombre collectif de mailslots 32 accessibles aux clients et/ou serveurs. En ce sens, le nombre de mailslots 32 peut être dynamique, augmentant et diminuant en fonction des besoins, ou seulement additionnel lorsqu'il faut accéder à des mailslots supplémentaires 32.

Considérant maintenant la Figure 3, la mémoire partagée 22 peut communiquer avec un certain nombre de clients 40 et de serveurs 50. Chaque mailslot 32 de la mémoire partagée 22 peut en outre comprendre une liste de références 33 comprenant au moins une liste de références pour le client/chacun des clients 40 et le serveur/chaque serveur 50 susceptible d’être associé à ce mailslot particulier 32. La liste de références 33 peut contenir, par exemple, des informations d’acheminement, de source et/ou de destination associées à chacun des clients 40 et/ou serveurs 50 respectifs, de façon que, par exemple, un client 40 ou un serveur 50 puisse consulter la liste de références 33 de la mémoire partagée 22 afin d’obtenir au moins un trajet de communication jusqu’à l’autre des serveurs 50 ou client 40 respectif. De la sorte, l’utilisation de l’adresse constante 34 et du mailslot connu 32 ayant la liste de références 33 facilite la communication entre un ou plusieurs client(s) 40 et/ou serveur(s) 50 sans qu’il soit nécessaire de définir des mécanismes de communication directe entre les clients 40 et/ou les serveurs 50 eux-mêmes.

Comme représenté schématiquement, le client/chaque client 40 comprend un pointeur 42 d'accès actif apte à identifier un espace mémoire adressable spécifique, ou une pluralité de groupes d’espaces mémoires, de façon que le client puisse accéder à une ou plusieurs mémoire(s) tampon(s). Un premier client 54 peut accéder à un premier espace mémoire adressable 55 associé au premier client 54 et comprenant un certain nombre de mémoires tampons 36. En outre, un deuxième client 56 peut accéder à un deuxième espace mémoire adressable 57 associé au deuxième client 56 et comprenant un deuxième nombre de mémoires tampons 36. Chacun des espaces mémoires adressables respectifs 55, 57 est identifié et géré par ses clients respectifs 54, 56 et/ou par les pointeurs d’accès actif respectifs 42 de ses clients. Chacune des différentes mémoires tampons 36 peut être configurée pour stocker une quantité prédéterminée de données nécessaires pour un élément de données particulier. Des formes de réalisation de l’invention peuvent comporter des configurations dans lesquelles, par exemple, le premier client 54 ne peut accéder qu’à son propre espace mémoire 55 et/ou aux mémoires tampons 36 associées à un mailslot particulier et ne peut donc pas accéder, par exemple, à l’espace mémoire 57 du deuxième client 56. De la sorte, chaque client 54, 56 est “propriétaire” de ses espaces mémoires respectifs 55, 57 même si la commande individuelle des mémoires tampons 36 peut être attribuée à d’autres composants. Alors que les clients 40 peuvent avoir un accès limité à leurs espaces mémoires respectifs 55, 57, les serveurs 50 peuvent accéder aux mémoires tampons 35 de n’importe quels espaces mémoires 55, 57 d’un client 40.

Le nombre de mémoires tampons 36 pour chaque espace mémoire adressable 55, 57 peut être défini par le nombre de transactions demandées par chaque client respectif 54, 56. Eventuellement, le nombre de mémoires tampons 36 pour chaque espace mémoire adressable 55, 57 peut être défini par le nombre de transactions demandées par chaque client respectif 54, 56, plus une mémoire tampon supplémentaire 36. Ainsi, dans l’exemple illustré, le premier client 54 a demandé d’effectuer deux transactions dans la mémoire partagée 22 et il lui a été accordé trois mémoires tampons (36) (deux plus une mémoire tampon en sus), tandis que le deuxième client 56 a demandé d’effectuer trois transactions dans la mémoire partagée 22 et il lui a été accordé quatre mémoires tampons (36) (trois plus une mémoire tampon en sus).

Dans une forme de réalisation de l'invention, le nombre de mémoires tampons 36 dans chaque espace mémoire adressable 55, 57 et la taille de chaque mémoire tampon 36 sont prédéfinis pendant l'initialisation de la mémoire partagée 22, d'après un nombre connu de clients 40 aptes à accéder au mailslot 32 et d’après un nombre de transactions connu. Dans une autre forme de réalisation de l'invention, le nombre de mémoires tampons 36 dans chaque espace mémoire adressable 55, 57 est défini au moment de l'exécution ou pendant l'exécution par le nombre collectif de clients 40 accédant alors au mailslot 32, et par le nombre de transactions demandées. De la sorte, le nombre de mémoires tampons 36 peut être dynamique, augmentant ou diminuant selon les besoins, ou seulement additionnel lorsque des clients supplémentaires 40 accèdent au mailslot 32 ou que des transactions sont demandées. Dans encore d’autres formes de réalisation de l'invention, le mailslot 32 et l’espace mémoire adressable 55, 57 peuvent être configurés indépendamment. Par exemple, le mailslot 32 peut être défini comme expliqué, mais l’espace mémoire adressable 55, 57 est configuré d’une manière dynamique pendant l’exécution, ou inversement. Dans les deux exemples, à prédéfinition ou a configuration dynamique, le nombre de mailslots 32 et/ou la configuration des mémoires tampons 36 peut/peuvent être défini(s) suivant un algorithme ou un programme exécutable stocké dans la mémoire partagée 22.

De plus, le serveur/chaque serveur 50 comprend un pointeur d’accès actif 52 et peut accéder à une mémoire tampon spécifique 36 indiquée par le pointeur d’accès actif 52. Par exemple, un serveur 50 peut accéder à la liste de références 33 du mailslot 32 qui peut identifier un client 40 et/ou un espace mémoire adressable 55, 57 associé à ce client 40, et les mémoires tampons 36 présentes dans celui-ci. Dans l’exemple illustré, le premier client 54 est associé à une première mémoire tampon 58. Des formes de réalisation de l’invention peuvent comporter un seul serveur communiquant avec chaque mailslot 32.

La Figure 4 est une vue schématique illustrant une autre configuration et un autre fonctionnement possibles de l’espace mémoire adressable 55, 57 d’un client. Il est représenté un espace mémoire unidirectionnel 80 comprenant au moins une file d’attente de mémoires tampons disponibles 82 gérée par un client 40 (non représenté) et une file d’attente de mémoires tampon de demandes 84 gérée par un serveur 50 (non représenté). La file d’attente de mémoires tampons disponibles 82 peut être configurée pour contenir le nombre maximal de mémoires tampons 36 disponibles dans l’espace mémoire 80, tandis que la file d’attente de mémoires tampons de demandes 84 peut être configurée pour contenir le nombre maximal de mémoires tampons 36 demandées par le client 40 (c’est-à-dire le nombre maximal de mémoires tampons 36 dans l’espace mémoire 80, moins une). Dans des formes de réalisation dans lesquelles il n’y a pas de mémoires tampons “en sus”, la file d’attente de mémoires tampons disponibles 82 et la file d’attente de mémoires tampons de demandes 84 peuvent être configurées pour contenir le même nombre de mémoires tampons, égal au nombre maximal de mémoires tampons 36 demandées par le client 40.

Dans l’exemple illustré, les mémoires tampons 36 peuvent contenir les données utiles ou le message faisant l’objet d’une transaction par le client 40 et/ou le serveur 50 respectifs). Lorsque le client 40 effectue des demandes de transactions unidirectionnelles (le fait qu’une transaction soit dans l’attente d’une interaction du serveur 50 ; p.ex. "en attente de demande", une mémoire tampon 36 pour chaque demande de transaction peut être transférée dans la file d’attente de mémoires tampons de demandes 84 pour attendre la transaction ou le traitement par un serveur 50. Une fois que le serveur 50 effectue et/ou traite la transaction demandée, la mémoire tampon 36 est replacée dans la file d’attente de mémoires tampons disponibles 82 pour que le client 40 effectue d’autres demandes de transactions. Le client 40 peut également effectuer des transactions supplémentaires et/ou traiter les données de messages de la mémoire tampon 36 au retour de la file d’attente de mémoires tampons de demandes 84 avant de replacer la mémoire tampon 36 dans la file d’attente de mémoires tampons disponibles 82. Au sens de la présente description, des mémoires tampons 36 attribuées dans la file d’attente de mémoires tampons disponibles 82 peuvent être considérées comme “disponibles” ou “non occupées” pour entamer de nouvelles transactions, tandis que des mémoires tampons 36 attribuées dans la file d’attente de mémoires tampons de demandes 84 peuvent être considérées comme “indisponibles” ou “occupées”.

Par ailleurs, comme la file d’attente de mémoires tampons de demandes 84 peut être configurée avec un espace en file d’attente contenant une mémoire tampon disponible de moins que la file d’attente de mémoires tampons disponibles 82, des formes de réalisation de l’invention peuvent comporter des configurations dans lesquelles le client 40 ne peut pas effectuer de demandes de transactions terminées conjointement en attente (p.ex. toutes les mémoires tampons 36 ne peuvent pas être en même temps dans la file d’attente de mémoires tampons de demandes 84) sur toutes les mémoires tampons disponibles 36 de son espace mémoire respectif 80. Bien que l’illustration représente les mémoires tampons 36 passant d’une file d’attente 82, 84 à une autre file d’attente 82, 84, la mémoire tampon 36 elle-même ne peut pas changer d’emplacement dans l’espace mémoire 80. De la sorte, les files d’attente 82, 84 peuvent être des “files d’attente virtuelles”. Les files d’attente 82, 84 ne peuvent illustrer qu’une seule forme de réalisation de l’invention démontrant la propriété des mémoires tampons respectives 36 pendant le traitement de transactions dans l’espace mémoire unidirectionnel 80.

Un espace mémoire bidirectionnel 86 est aussi illustré et peut comprendre la file d’attente de mémoires tampons disponibles 82 et la file d’attente de mémoires tampons de demandes 84, comme expliqué plus haut, en plus d’une file d’attente de mémoires tampons de réponses 88, gérée par un client 40 (non représenté). Sauf mention contraire, la file d’attente de mémoires tampons disponibles 82 et la file d’attente de mémoires tampons de demandes 84 de l’espace mémoire bidirectionnel 86 fonctionnent d’une manière similaire aux fonctionnements décrits plus haut. Comme représenté, la file d’attente de mémoires tampons de réponses 88 peut également être configurée pour contenir le nombre maximal de mémoires tampons 36 demandées par le client 40 (c’est-à-dire le nombre maximal de mémoires tampons 36 dans l’espace mémoire 80, moins une). Dans des formes de réalisation dans lesquelles il n’y a pas de mémoires tampons “en sus”, la file d’attente de mémoires tampons demandées 88 peut être configurée pour contenir un nombre de mémoires tampons égal au nombre maximal de mémoires tampons 36 demandées par le client 40.

Une différence entre l’espace mémoire unidirectionnel 80 et l’espace mémoire bidirectionnel 86 consiste en ce qu’une fois que le serveur 50 effectue et/ou traite la transaction demandée dans la file d’attente de mémoires tampons de demandes 84, la mémoire tampon 36 est transférée dans la file d’attente de mémoires tampons de réponses 88 pour être soumise à un certain traitement supplémentaire par le client 40 (transaction en attente d’une interaction du client 40 ; p.ex. “en attente de réponse”). Au terme du traitement supplémentaire par le client 40 dans la file d’attente de mémoires tampons de réponses 88, la mémoire tampon 36 est replacée dans la file d’attente de mémoires tampons disponibles 82 pour que le client 40 effectue d’autres demandes de transactions. Au sens de la présente description, les mémoires tampons 36 affectées dans la file d’attente de mémoires tampons de réponses 88 peuvent être considérées comme “non disponibles” ou “occupées”. La file d’attente de mémoires tampons de réponses 88 peut aussi être une “file d’attente virtuelle”, comme expliqué plus haut. Par ailleurs, des formes de réalisation de l’invention peuvent comporter des configurations dans lesquelles le client 40 ne peut pas effectuer de demandes de transactions terminées conjointement en attente sur toutes les mémoires tampons disponibles 36 de son espace mémoire respectif 86, et donc le nombre collectif de mémoires tampons attribuées entre la file d’attente de mémoires tampons de demandes 84 et la file d’attente de mémoires tampons de réponses 88 ne peut pas dépasser le nombre de mémoires tampons 36 demandées par le client 40.

Dans ces configurations, l’espace mémoire unidirectionnel 80 peut permettre une communication unidirectionnelle, par exemple pendant une transaction de lecture seule, tandis que l’espace mémoire bidirectionnel 86 peut permettre une communication bidirectionnelle, par exemple, pendant des opérations de lecture et d’écriture. Des formes de réalisation de l’invention peuvent comporter des configurations dans lesquelles le client 40 peut entamer la transaction et le serveur 50 peut répondre par une transaction correspondante. Des espaces mémoires unidirectionnels et bidirectionnels 80, 86 peuvent être présents en n’importe quel nombre dans des formes de réalisation de l’invention et peuvent être définis par les transactions demandées, comme expliqué plus haut.

Les mécanismes pour permettre la communication entre au moins un client 40 et au moins un serveur 50 en accédant à des données de messages dans la mémoire tampon 36 de la mémoire partagée 22 sont décrits en référence à la Figure 5. Sur la Figure 5, un seul client 40 et un espace mémoire adressable correspondant 57 sont représentés pour faciliter la compréhension et dans un souci de concision. Des formes de réalisation de l’invention peuvent comporter une pluralité de 40 et d’espaces mémoires respectifs 57 exécutant chacun des mécanismes similaires. De plus, à titre d’illustration, la pluralité de mémoires tampons 36 représentées ont des états de classification différents, dont des états occupée 44 et des états non occupée 46. Dans ces exemples, une mémoire tampon “occupée” 44 peut être soit “commandée” par un client 40 soit “commandée” par un serveur 50, la “commande” désignant l’aptitude respective de celui qui la commande à manipuler directement les données de messages dans la mémoire tampon 36. La propriété peut être commandée et/ou gérée par, par exemple, le client 40 ou peut être attribuée et/ou gérée par le pointeur d’accès actif 42 du client. Le client 40 et/ou le pointeur d’accès actif 42 dirige(nt) l’accès à la pluralité de mémoires tampons 36 d’après une demande de transaction de données.

Ainsi, une première mémoire tampon 58 a été identifiée comme mémoire tampon occupée 44 et est commandée par le client 40, par l’intermédiaire d’une première communication. Quand le client 40 a terminé la transaction, ou une partie de la transaction, avec la première mémoire tampon, le client 40 peut mettre la mémoire tampon, par exemple, “en attente de demande” pour signifier qu’une transaction est requise par le serveur 50, et terminer la première communication 64. Indépendamment de la transaction avec le serveur 50, si le client 40 demande une nouvelle transaction, le pointeur d’accès actif 42 gérera la communication du client 40 en identifiant une deuxième mémoire tampon 60 disponible pour des transactions, et pointera la mémoire tampon disponible suivante (p.ex. non occupée) 36, présentée sous la forme d’une deuxième mémoire tampon 60. Le client 40 pourra alors communiquer avec la deuxième mémoire tampon 60 par l’intermédiaire d’une deuxième communication 66 et la deuxième mémoire tampon 60 aura un état occupée 44 (non représenté). Le client effectuera alors la deuxième transaction voulue sur des données stockées dans la deuxième mémoire tampon 60. Au moment d’une autre demande de transaction par ce même client 40, le mécanisme se répète de façon que la demande de transaction du client 40 qui arrive puisse accéder à une mémoire tampon inoccupée 44, identifiée par le client 40 et/ou le pointeur d’accès actif 42.

Le mécanisme illustré sur la figure 6 se construit sur le mécanisme représenté sur la Figure 5. Dans le présent exemple, le client 40 a exécuté, par exemple, une transaction de lecture/écriture sur la première mémoire tampon 58, terminé la transaction et mis la mémoire tapon 58, par exemple, “en attente de demande” pour signifier qu’une transaction est requise par le serveur 50, et effectue désormais une transaction sur la deuxième mémoire tampon 60.

Le serveur 50 peut être en train d’effectuer des transactions pour un certain nombre de clients 40 suivant un ordonnancement. Par exemple, le serveur 50 peut être en train d’effectuer des transactions pour .des clients suivant un ordonnancement de type tourniquet, un ordonnancement premier entré/premier sorti, un ordonnancement dernier entré /premier sorti, un ordonnancement séquentiel, un ordonnancement par qualité de desserte, un plan minuté où chaque client 40 dispose d’un créneau horaire défini pour interagir, ou une combinaison de ceux-ci. Des algorithmes et/ou procédés d’ordonnancement supplémentaires peuvent être inclus pour mener à bien un certain nombre de transactions d’un client 40.

Dans l’exemple illustré, quand le serveur 50 a déterminé que le client 40 doit être desservi, le serveur peut commencer par consulter le mailslot 32 et/ou la liste de références 33 afin d’identifier le client 40 (ce qui est illustré par la communication 68). Le serveur 50 peut ensuite consulter le client 40 et/ou le point d’accès actif 42 du client afin de déterminer si d’éventuelles transactions sont requises par le serveur 50 (ce qui est illustré par la communication 70). Si aucune transaction n’est requise par le serveur 50, le serveur 50 peut continuer à fonctionner suivant le plan ou l’algorithme et, peut, par exemple, passer au client suivant à desservir. Cependant, comme décrit plus haut, la première mémoire tampon 58 contient une transaction à terminer par le serveur 50. Le client 40 et/ou le pointeur d’accès actif 42 identifie le fait que la première mémoire tampon 58 est prête pour être commandée par le serveur 50 et peut contenir, par exemple, l’emplacement de la première mémoire tampon 58 dans la mémoire partagée 22.

Ensuite, le pointeur d’accès actif 52 du serveur pointe la première mémoire tampon identifiée 58 et poursuit pour réaliser la transaction demandée (comme illustré par la communication 72). Lorsque la transaction demandée par le serveur 50 est terminée, le serveur 50 peut mettre la mémoire tampon 58, par exemple, “en attente de réponse” pour une autre transaction, ou la rendre disponible (non occupée) pour une nouvelle transaction. Le serveur peut alors découpler la communication 72 d’avec la première mémoire tampon 58 et peut, si nécessaire ou selon le plan, répéter les communications décrites ci-dessus pour desservir des mémoires tampons 36 de clients supplémentaires 40. En outre, des formes de réalisation de l’invention peuvent comporter un indicateur de priorité pour hiérarchiser la desserte de mémoires tampons particulières 36 par le serveur 50.

De plus, bien qu’on explique une demande de transaction pour le serveur 50, un client 40 peut créer des transactions qui aboutissent à la mise en file d’attente d’une pluralité de demandes du serveur 50. Quelle que soit la manière dont le serveur 50 répond à une pluralité de demandes de transactions du serveur, des formes de réalisation de l’invention peuvent comporter des cas où toutes les mémoires tampons 36 sont occupées alors qu’un client 40 ou un serveur 50 cherche à demander une transaction supplémentaire. Un tel scénario est illustré sur la Figure 7, sur laquelle il n’y a pas de mémoires tampons 36 disponibles ou non occupées 46. Dans ce cas, le client effectue une transaction sur des données stockées dans une mémoire tampon 36, et toutes les autres mémoires tampons 36 sont occupées 48, par exemple dans l’attente d’une transaction du serveur 50. Dans le présent exemple, le mécanisme pour communiquer prévoit que le client 40 et/ou le pointeur d’accès actif 42 et/ou la mémoire tampon 36 en cours répondra toujours à la demande respective de transaction par une indication d’échec de transaction jusqu’à ce qu’une mémoire tampon non occupée 46 supplémentaire 36 soit disponible. De la sorte, lors d’un échec de la demande de transaction, le client peut à nouveau tenter d’effectuer la transaction demandée, laquelle peut être menée à bien ultérieurement, par exemple, si une ou plusieurs mémoires tampons 36 est/sont devenue(s) non occupée(s) 46. Ainsi, le mécanisme assure le nombre de transactions demandées par le client 40 plus une (à savoir une “mémoire tampon en sus” facultative 36), de façon que le client 40 puisse toujours disposer de la mémoire tampon en sus 36 pour des transactions, même s’il s’agit de transactions non terminées, jusqu’à ce que des mémoires tampons supplémentaires 36 soient disponibles. Dans des formes de réalisation où aucune mémoire tampon “en sus” n’est prévue, les clients 40 ne peuvent pas disposer d’une mémoire tampon 36 pour tenter d’effectuer la transaction demandée et aucune transaction n’est effectuée tant qu’une ou plusieurs mémoire(s) tampon(s) 36 ne redevient/redeviennent pas disponible(s).

Les mécanismes décrits plus haut peuvent fonctionner uniquement à l'aide de transactions en langage d'assemblage machine et/ou d’opérations atomiques, sans copie des données à un niveau de conception au-delà du langage d'assemblage machine, notamment sans copier les données au niveau du système d'exploitation (par exemple "zéro copie"). Les formes de réalisation décrites plus haut ont pour effet technique que l'opération de zéro copie est réalisée en dirigeant les clients 40 et/ou les serveurs 50, à l'aide de pointeurs d'accès actif 42, 52, vers des mémoires tampons 36 contenant les données de messages, de façon que les données de messages ne soient jamais "verrouillées" ni "bloquées" en empêchant l'accès à d'autres clients 40 et aux serveurs 50. De plus, l'utilisation d'un langage d'assemblage machine permet des opérations de "échange atomique" des références, dans lesquelles l'actualisation est terminée en un seul cycle atomique de fonctionnement, et ne peut donc pas être interrompue par d'autres actualisations des données ou de la mémoire tampon, car d'autres actualisations ne peuvent pas être achevées au cours d'un cycle de fonctionnement plus court que l'échange atomique. De la sorte, les opérations d’échange garantissent que le basculement d’une référence vers une mémoire tampon 36 réussit ou échoue absolument, aussi n’y a-t-il pas de risque de corruption de la référence elle-même, par exemple à la suite d’une interruption de l’échange. Le mécanisme fonctionne sur toute l’emprise du client 40 et/ou du processus 26, 28 et ne repose pas sur la suppression d’interruptions.

En utilisant des instructions en langage d'assemblage machine et des structures de données de base (par exemple, des listes à liaison unique, des pointeurs de base), les mécanismes assurent des communications asynchrones de données interprocessus entre au moins un serveur 50 et au moins un client 40, dans une mémoire partagée 22, à l'aide d'un échange de données à zéro copie, permettant un accès "sans verrouillage" ou "sans blocage" pour les données accessibles sans configuration complexe de priorité d'un processus, ni le phénomène de "inversion de priorité", dans lequel un processus à niveau inférieur de priorité exécutant un pré-accès verrouille les données et ne les "lâche" pas pour qu'elles deviennent accessibles même si un processus d'un niveau de priorité supérieur demande l'accès. En fait, puisque des opérations utilisant des instructions machine tendent vers "le premier qui accède aux données gagne", des processus à niveau de priorité supérieur peuvent toujours être les premiers à effectuer leurs opérations. De plus, les mécanismes assurent un accès “sans attente” aux données accessibles qui peut être effectué au niveau du processus, pas seulement au niveau du thread.

Des formes de réalisation de l'invention peuvent en outre utiliser les mécanismes décrits ci-dessus en réalisant une programmation d'interfaces de programmation d'applications (API) afin d'accéder aux mécanismes au niveau d'un système d'exploitation (ou au niveau application, etc.) par l'intermédiaire des API. Cela a pour effet technique que les formes de réalisation décrites plus haut permettent le procédé à zéro copie afin d'empêcher le verrouillage de données, le blocage de données et/ou l'inversion de priorité.

Les mécanismes décrits plus haut sont en outre conçus et configurés de façon que le mailslot 32 soit apte à attribuer un certain nombre de demandes de transactions de clients 40 et/ou de serveurs 50, même si le nombre de transactions demandées plus grand que prévu ou voulu, ou si les demandes sont créées à un rythme trop élevé pour que le serveur puisse répondre. Par ailleurs, le mécanisme décrit peut parer à une attaque par déni de service au cours de laquelle un ou plusieurs clients cherche(nt) à rendre une machine ou une ressource de réseau indisponible pour ses utilisateurs prévus en saturant de demandes de transactions le serveur cible afin qu’il ne puisse pas assurer le service prévu. Des attaques par déni de service peuvent chercher à monopoliser le serveur 50, le client 40 et/ou des ressources de mémoires tampons 36, notamment la largeur de bande, les moyens de traitement ou l’aptitude à réagir à des transactions prioritaires, ou risquent d’entraver ou de réduire le service prévu ou, au pire, de provoquer une panne du serveur ou de la ressource. Cependant, lors de toute tentative de monopolisation d’une ressource du mécanisme décrit plus haut, la combinaison éventuelle des échecs de demandes de transactions de la mémoire tampon en sus 36 avec la planification du serveur 50 empêchera une telle attaque par déni de service, sans que les demandes de transactions ne puissent avoir lieu sans consommer de ressources, comme décrit plus haut, et sans verrouiller ni bloquer les données respectives.

Un avantage supplémentaire réalisable dans les formes de réalisation ci-dessus consiste en ce que les formes de réalisation décrites plus haut empêchent que le système ne fonctionne mal par suite d'opérations de copie de données à un niveau de langage différent du langage machine. Par ailleurs, des formes de réalisation de l’invention réduisent le nombre de copies nécessaires en utilisant des références et des mémoires tampons, comme décrit plus haut. Un autre avantage des formes de réalisation décrites plus haut comprend un mécanisme intégré pour écraser les données les plus anciennes présentes dans les mémoires tampons, et en ce qu'il nécessite donc aucun type de méthode de gestion de données pour le "ramassage des ordures". En outre, un partage de données classique entre un serveur et un ou plusieurs clients est accompli en créant un stockage global des données et en protégeant celui-ci à l'aide de sémaphores (c’est-à-dire des valeurs de régulation d'accès telles que des indicateurs verrouillés/déverrouillés), par exemple au niveau d'un système d'exploitation, n'importe quel autre mutex ou protection contre le verrouillage de données (par exemple des interruptions de données, etc.), ce qui peut être très coûteux en terme de temps machine, surtout si les données stockées sont volumineuses. Cela permet, comme décrit ici, des opérations d'accès plus efficaces, plus rapides, sans verrouillage. Par ailleurs, les systèmes d’exploitation ne prévoient ordinairement pas de protection par sémaphores entre les processus, mais uniquement entre les threads d’un processus. D'autres avantages réalisables dans les formes de réalisation décrites plus haut comprennent le fait que le type de mailslot présente la souplesse nécessaire à un couplage lâche de processus, il nécessite peu de coordination et il ne nécessite pas de "démarrage échelonné" (c’est-à-dire que des processus, un client et/ou des serveurs peuvent intervenir à tout moment). De plus, la mise en œuvre des API décrits plus haut peut avoir pour effet une diminution des coûts de mise au point pour la mise au point du système, et de plus grandes marges de performances sur le matériel similaire en comparaison de procédés de copie différents.

Dans la mesure où ce n'est pas déjà décrit, les différents aspects et structures des diverses formes de réalisation peuvent être utilisés en combinaison les uns avec les autres à volonté. Le fait qu'un aspect puisse ne pas être illustré dans toutes les formes de réalisation ne signifie pas qu'il doit être interprété comme ne pouvant pas l'être, mais cela ne vise à rendre la description plus concise. Ainsi, les divers aspects des différentes formes de réalisation peuvent être mélangés et adaptés à volonté pour former de nouvelles formes de réalisation, indépendamment du fait que les nouvelles formes de réalisation soient expressément décrites ou non. Toutes les combinaisons ou permutations de détails décrits ici sont couvertes par le présent exposé.

Liste des repères 8 Aéronef 52 Pointeur d’accès actif 10 Fuselage 54 Premier client 12 Système de moteur gauche 55 Premier espace mémoire 14 Système de moteur droit adressable 16 56 Deuxième client 18 Equipements remplaçables en 57 Deuxième espace mémoire escale (LRU) adressable 20 Serveur 58 Première mémoire tampon 22 Mémoire 60 Deuxième mémoire tampon 24 Réseau de communication de 62 données 64 Première communication 26 Processus LRU 66 Deuxième communication 28 Processus serveur 68 Communication 30 Attribution de données 70 Communication 32 Mailslot 72 Communication 33 Liste de références 73 34 Adresse constante 74 36 Pluralité de mémoires 76 tampons 78 37 80 Espace mémoire unidirectionne 38 82 File d’attente de mémoires 40 Clients tampons disponibles 42 Pointeur d’accès actif 84 File d’attente de mémoires 44 Mémoire tampon occupée tampons de demandes 46 Mémoire tampon non occupée 86 Espace mémoire bidirectionnel 48 88 File d’attente de mémoires 50 Serveur tampons de réponses

Claims

REVENDICATIONS

1. Mécanisme pour permettre une communication entre au moins un client (40) et au moins un serveur (50) en accédant à des données de messages dans une mémoire partagée (22), caractérisé en ce qu’il est configuré de sorte que peut être réalisée une attribution (30) de données présentes dans la mémoire partagée (22) à au moins un mailslot (32), l'attribution (30) étant accessible par une adresse constante prédéterminée (34), et une série de mémoires tampons (36) pour le client/chaque client (40) afin d’effectuer des demandes de transactions, chacune des mémoires tampons (36) pouvant être commandée par l’un ou l’autre des client (40) et serveur (50) respectifs ; et en ce que le/les mailslot(s) (32) ont des références identifiant le/les client(s) (40) et le/les serveur(s) (50) ; chaque client (40) et chaque serveur (50) ayant un pointeur d'accès actif (42, 52) ; et le/les client(s) ayant un pointeur d'accès actif (42) qui permet au(x) elient(s) (40) de manipuler directement des données de messages à l’aide d’une/de mémoire(s) tampon(s) (36) commandée(s’) par le/les elient(s) (40) ; et le/les serveur(s) (50) ayant un pointeur d’accès actif (52) qui permet au(x) serveur(s) (50) de manipuler directement des données de messages à l’aide d’une/de mémoire(s) tampon(s) (36) commandée(s) par le/les serveur(s) (50) ; t les pointeurs d'accès actif (42, 52) étant attribués parmi les mémoires tampons (36) uniquement à l'aide d’opérations atomiques sans copier les données au niveau d'un système d'exploitation.
2. Mécanisme selon la revendication 1, le mécanisme étant un système de gestion de vol.
3. Mécanisme selon la revendication 1, dans lequel le/les mailslot(s) (32) et la série de mémoires tampons (36) sont prédéfinis pendant l’initialisation de la mémoire partagée (22).
4. Mécanisme selon la revendication 1, dans lequel la demande de transaction comprend une lecture des données et/ou une écriture de nouvelles données dans la mémoire tampon (36).
5. Mécanisme selon la revendication 4, dans lequel au moins une transaction est attribuée à un espace mémoire unidirectionnel (80) comprenant au moins une file d’attente de mémoires tampons disponibles (82) et une file d’attente de mémoires tampons de demande (84).
6. Mécanisme selon la revendication 4, dans lequel au moins une transaction est attribuée à un espace mémoire bidirectionnel (86) comprenant au moins une file d’attente de mémoires tampons disponibles (82), une file d’attente de mémoires tampons de demande (84) et une file d’attente de mémoires tampons de réponses (88).
7. Mécanisme selon la revendication 1, dans lequel le nombre de mémoires tampons (36) est égal au moins au nombre de transactions demandées par le client respectif (40), plus une mémoire tampon en sus.
8. Procédé pour permettre une communication entre au moins un client (40) et au moins un serveur (50) en accédant à des données de messages dans une mémoire partagée (22), caractérisé en ce qu’il comporte : l'attribution de données présentes dans la mémoire partagée (22) à au moins un mailslot (32) ; l'attribution d'une unique adresse prédéterminée (34) pour accéder au mailslot/à chaque mailslot (32); l'attribution d’un certain nombre de mémoires tampons (36) pour le client au moins unique (40), chaque mémoire tampon (36) pouvant soit être commandée par un client (40) soit être commandée par un serveur (50), le nombre de mémoires tampons (36) étant égal au nombre de transactions demandées par le client respectif (40); et l'attribution d'un pointeur d’accès actif (42) de client par une mémoire tampon (36) commandée par un client (40) afin de passer de la mémoire tampon (36) commandée par un client (40) à une mémoire tampon (36) commandée par un serveur (50) en permettant au serveur (50) de manipuler directement les données de messages par l’aide d’un pointeur d’accès actif (52) de serveur ; l'accès aux données de messages se faisant par l'intermédiaire de pointeurs d’accès actifs des mémoires tampons (36), sans copie des données de messages au niveau du système d'exploitation.
9. Procédé selon la revendication 8, dans lequel l'attribution des données dans au moins un mailslot (32), l’attribution d’une unique adresse prédéterminée et l’attribution du nombre de mémoires tampons (36) pour un/chaque client (40) ont lieu pendant l’initialisation de la mémoire partagée (22).
10. Procédé selon la revendication 8, dans lequel l’accès aux données de messages comprend la lecture des données et/ou l’écriture de nouvelles données dans la mémoire tampon (36).
11. Procédé selon la revendication 10, dans lequel au moins une transaction est effectuée dans un espace mémoire unidirectionnel (80) comprenant au moins une partie état et une partie données de messages.
12. Procédé selon la revendication 10, dans lequel au moins une transaction est effectuée dans un espace mémoire bidirectionnel (86) comprenant au moins une file d’attente de mémoires tampons disponibles (82), une file d’attente de mémoires tampons de demandes (84) et une file d’attente de mémoires tampons de réponses (88).
13. Procédé selon la revendication 8, comportant le lancement d’une nouvelle demande de transaction d’un client (40) dans une mémoire tampon non occupée respective (36) commandée par un client (40).
14. Procédé selon la revendication 8, dans lequel le nombre de mémoires tampons (36) est égal au moins au nombre de transactions demandées par le client respectif (40), plus une mémoire tampon en sus.
15. Procédé selon la revendication 14, dans lequel la nouvelle demande de transaction d’un client échoue si toutes les mémoires tampons de clients respectives (36) sont occupées.