FR2881239A1 - Procede de gestion d'acces a des ressources partagees dans un environnement multi-processeurs - Google Patents

Abstract

L'invention concerne un procédé de gestion de l'accès à des ressources partagées au sein d'un environnement multi-processeurs ou multi-ordinateurs, y compris lorsque ces processeurs travaillent en parallélisme physique. Une telle gestion d'accès est particulièrement utile pour réaliser un contrôle d'accès à de telles ressources, par exemple de la mémoire partagée, de façon à stabiliser ou optimiser le fonctionnement d'un processus au sein d'une application multitâche utilisant un tel environnement parallèle.Ce procédé comprend en particulier, au cours d'au moins une (SchA) de ses périodes d'activation, une première tâche dite tâche accédante (TA), en réponse à une demande d'accès (InstrA) à ladite ressource cible, se voit attribuer un accès, dit continu, à ladite ressource cible, c'est à dire de façon à exclure tout accès à ladite ressource cible (ShMPi) par au moins une deuxième tâche (TB) pendant la totalité de la période d'activation (SchA) de la tâche accédante suivant immédiatement ladite demande d'accès

Description

Procédé de gestion d'accès à des ressources partagées

dans un environnement multi-processeurs L'invention concerne un procédé de gestion de l'accès à des ressources partagées au sein d'un environnement multi-processeurs ou multi-ordinateurs, y compris lorsque ces processeurs travaillent en parallélisme physique. Une telle gestion d'accès est particulièrement utile pour réaliser un contrôle d'accès à de telles ressources, par exemple de la mémoire partagée, de façon à stabiliser ou optimiser le fonctionnement d'un processus au sein d'une application multitâche utilisant un tel environnement parallèle.

Des environnements parallèles sont en général conçus et utilisés pour obtenir, à partir d'éléments matériels existants, une plus grande puissance de calcul. Il s'agit le plus souvent de réaliser des calculs lourds et complexes, au sein d'applications techniques ou scientifiques conçues essentiellement dans cette optique.

Un tel environnement peut être réalisé en intégrant plusieurs processeurs au sein d'un même ordinateur, qui leur répartira le travail de calcul qui lui est demandé. Plusieurs ordinateurs sont parfois également réunis en réseau et gérés de façon à se partager entre eux une certaine charge de travail, avec pas ou peu d'intervention de la part des utilisateurs.

Lorsque ces différents éléments unitaires, processeurs ou ordinateurs, sont capables de travailler en même temps sur des tâches différentes qui seront réordonnancées ensuite, on parle de parallélisme physique, par exemple par opposition à un parallélisme qui serait simulé en partageant le temps de travail d'un seul élément en plusieurs zones virtuelles de travail.

Les environnements existants dotés de capacités de parallélisme physique, qu'ils s'agisse de multi-processeurs ou de multi-ordinateurs, sont le plus souvent conçus et optimisés pour obtenir la plus grande puissance de calcul globale. Pour cela, les différents éléments travaillent le plus possible de façon découplée, et avec très peu de coordination entre eux.

Or, par exemple pour des raisons de coût ou de souplesse, on cherche souvent à remplacer de gros ordinateurs centraux par des microordinateurs ou stations de travail, seuls ou en groupes. De telles machines existent en version multiprocesseurs travaillant en parallélisme pour plus de puissance, ou peuvent être regroupées de façon à travailler en parallèle au sein d'un réseau constituant en lui-même un environnement de travail unique vis à vis de l'extérieur, c'est à dire se comportant comme un interlocuteur unique vis à vis de l'extérieur.

Il peut alors être intéressant d'utiliser de tels environnements parallèles pour exécuter des applications différentes ou plus variées, en particulier des applications multi-tâches de type transactionnel qui sont courantes dans des domaines de gestion d'entreprises, ou de réseaux de postes de travail, ou de réseaux de communications. De telles applications ont souvent des structures plus variées et comportent très souvent plusieurs tâches qui utilisent des ressources partagées au sein du même environnement.

Cependant, du fait que ces systèmes d'exploitations ou ces applications sont conçues pour des machines mono-processeur, elles ne sont souvent pas prévues pour gérer des interférences entre deux tâches s'exécutant réellement en même temps, comme c'est le cas pour un parallélisme physique. Ainsi, lorsque plusieurs tâches s'exécutant en même temps doivent accéder à une même donnée ( race condition ), le résultat d'une lecture par une tâche pourra être très différent selon qu'une modification par une autre tâche sera intervenue avant ou après cette lecture.

Or la plupart des systèmes d'exploitation multi-tâches ne sont pas prévus pour gérer un environnement travaillant en parallélisme réel, et encore moins pour gérer des ressources partagées en accès direct. Parmi les types de ressources partagées, on peut qualifier d'accès direct celles qui sont accessibles par adressage depuis une instruction programme, comme des zones de mémoire partagée définies initialement par une instruction de type map .

L'accès à ce type de ressource partagée en accès direct, par plusieurs tâches en parallèle, est en général peu ou pas géré par le logiciel système, par opposition à d'autres ressources partagées qui nécessitent un appel système, telles que des ressources à passage de messages du genre pipe ou socket utilisant des appels systèmes comme open , read ou write . La gestion des accès à des ressources partagées à accès direct est alors le plus souvent presque entièrement à la charge de l'application dans des environnements parallèles.

Dans ce type d'environnement, l'utilisation d'application existantes non prévues pour cela peut donc souvent poser de nombreux problèmes si elles ne sont que peu ou pas ( legacy applications ) modifiées dans ce but. Dans certains cas, l'exécution peut être aléatoire voire impossible, par exemple du fait d'interférences non gérées entre différentes tâches au sein d'une même application.

Un but de l'invention est de permettre une gestion ou un contrôle plus poussé, ou plus souple ou plus performant, de l'accès en multitâche à des ressources partagées au sein d'un environnement parallèle.

Même si le fonctionnement de l'application est possible, son déroulement comporte le plus souvent des aspects non déterministes qui peuvent poser problème pour implémenter une gestion du fonctionnement de cette application. Une telle gestion de fonctionnement peut être recherchée pour pouvoir fiabiliser, tracer ( debugging ), ou répartir ( load balancing ) l'exécution d'une telle application au sein d'un ou plusieurs ordinateurs, qu'ils soient isolés ou en réseau, par exemple sous forme de clusters .

Or ce type de gestion de fonctionnement comprend souvent une journalisation ( log ) du fonctionnement d'une ou plusieurs tâches, de façon à pouvoir ultérieurement rejouer ( replay ) leur déroulement, de façon similaire voire identique. Pour réaliser ces opérations de journalisation ou de rejeu en limitant les pertes de performances que cela entraîne, il est avantageux que ce déroulement comprenne le plus possible d'opérations qui soient déterministes par rapport aux tâches ou à l'application gérées, en particulier dans les résultats qu'elles renvoient.

Pour pouvoir gérer ainsi une telle application au sein d'un ou plusieurs environnements matériels comprenant des structures parallèles, il est donc important de pouvoir obtenir un comportement déterministe pour le plus grand nombre possible d'opérations réalisées dans cette application.

Un but de l'invention est aussi d'obtenir, pour certaines opérations accédant à des ressources partagées, un comportement déterministe en environnement parallèle.

Pour cela, l'invention propose un procédé permettant de gérer ou contrôler l'accès aux ressources partagées, en particulier à accès direct, de façon à ce que chaque tâche puisse obtenir un accès exclusif aux ressources partagées pendant la totalité d'une période où elle est activée par le système.

Ce procédé est en particulier mis en oeuvre par un logiciel système gérant par activation séquentielle une pluralité de tâches de programme au sein d'au moins une application informatique exécutée dans un système informatique dit parallèle comprenant une pluralité de moyens de calcul aptes à exécuter plusieurs tâches simultanément dans au moins deux unités de calcul. Dans ce cadre, le procédé gère l'accès à au moins une ressource partagée, dite ressource cible, accessible par lesdites tâches.

Cette gestion comprend alors, au cours d'au moins une de ses périodes d'activation, une première tâche dite tâche accédante, en réponse à une demande d'accès à ladite ressource cible, se voit attribuer un accès, dit continu, à ladite ressource cible, c'est à dire de façon à exclure tout accès à ladite ressource cible par au moins une deuxième tâche pendant la totalité de la période d'activation de la tâche accédante suivant immédiatement ladite demande d'accès Ce procédé est avantageusement mis en oeuvre dans un système informatique parallèle où au moins une des unités de calcul comprend un mécanisme d'interruption capable, en fonction de la valeur d'au moins une donnée, dite de présence, mémorisée au sein de l'espace mémoire dudit système informatique, d'interrompre l'exécution d'une instruction de programme demandant un accès à une ressource déterminée, déclenchant ainsi un appel à un agent logiciel gestionnaire d'erreur.

Le procédé comprend alors en outre les étapes suivantes: -interruption de l'exécution de la première instruction demandant un accès à la ressource cible au cours d'une période d'activation de la tâche accédante; - test par le gestionnaire d'erreur d'au moins une donnée dite d'accès mémorisée dans ledit espace mémoire et indiquant si ladite ressource cible est actuellement attribuée à une autre tâche en un accès continu excluant ladite tâche accédante; - dans le cas de l'existence d'un tel accès continu déjà attribué à une autre tâche, suspension de l'exécution de la tâche accédante ou clôture de sa période d'activation; -dans le cas contraire, mémorisation dans ledit espace mémoire d'au moins une donnée d'accès représentant l'attribution à la tâche accédante d'un accès continu portant sur ladite ressource cible; - lors de l'exécution de la dernière instruction de la période d'activation de la tâche accédante ou postérieurement à cette dernière instruction, modification de la donnée d'accès représentant son accès continu obtenu pour la ressource cible de façon à libérer celle-ci.

Avantageusement, le procédé est caractérisé en ce que, lorsque l'étape de test de la donnée d'accès de la ressource cible indique que la ressource est libre pour la tâche accédante, l'étape de mémorisation d'un accès continu qui suit ladite étape de test constitue avec cette étape de test une seule opération atomique au sein du fonctionnement du système informatique parallèle.

Plus particulièrement, le procédé comprend en outre une ou plusieurs des étapes suivantes: - postérieurement ou lors de la suspension d'une tâche par un agent logiciel dit ordonnanceur, une étape de clôture comprenant un test de l'ensemble des données de présence correspondant à la tâche suspendue de façon à identifier et libérer l'ensemble des ressources partagées pour lesquelles ladite tâche suspendue détient un accès continu.

- préalablement ou lors de la libération d'une tâche par un agent logiciel dit ordonnanceur débutant une période d'activation de ladite tâche, une étape d'initialisation des données de présence de ladite tâche correspondant à l'ensemble des ressources partagées accessibles par ladite tâche, de façon à ce que chaque première demande d'accès de cette tâche à ces ressources partagées, au cours de ladite période d'activation, déclenche une telle interruption.

Selon une particularité, l'étape d'initialisation des données de présence est subordonnée au résultat d'un test de la valeur d'une donnée dite de gestion, correspondant à la tâche libérée et indiquant si ladite tâche doit ou non être monitorée, c'est à dire se voir appliquer le procédé de gestion d'accès.

Selon l'invention, l'exécution d'au moins une application comprenant au moins une tâche monitorée peut-être est lancée par un agent logiciel dit lanceur qui mémorise au moins une donnée de gestion indiquant que ladite tâche doit être monitorée.

Selon l'invention, la mise en place de la structure logicielle réalisant la gestion d'accès peut en particulier comprendre la création ou l'instanciation d'au moins une tâche nouvelle par au moins un agent logiciel de création, à partir d'une tâche existante. Cette création de tâche comprend alors la création d'au moins une donnée de présence correspondant à ladite nouvelle tâche et se rapportant à une ressource partagée, à partir d'une donnée de présence correspondant à ladite tâche existante et se rapportant à ladite ressource partagée.

De plus, au moins une donnée de présence correspondant à la nouvelle tâche est mise à jour par un agent logiciel d'allocation en fonction des modifications apportées à la ressource partagée à laquelle se rapporte ladite donnée de présence.

L'invention propose aussi de réaliser cette mise en place et/ou sa mise à jour par la modification ou l'instrumentation d'éléments uniquement logiciels au sein du système, en particulier dans le logiciel système.

De telles modifications ou instrumentation peuvent en particulier être réalisées, pour au moins un appel système, par une technique d'interposition dynamique utilisant une bibliothèque préchargée de routines modifiées.

Le procédé selon l'invention particulier à mettre en oeuvre au sein d'un système d'exploitation de type Unix ou Linux, et comprend une modification ou instrumentation des appels systèmes de type create , ou clone , ou map , ou de l'agent logiciel ordonnanceur ou des routines

- I -

de libération et suspension du gestionnaire de changement de contexte, ou de l'agent logiciel gestionnaire d'erreur de page, ou des tables de données noyau de structure mémoire.

Il peut ainsi être avantageusement mis en oeuvre au sein d'au moins un noeud d'un réseau d'ordinateurs, par exemple un réseau constituant un cluster géré par une ou plusieurs applications de gestion de fonctionnement de type middleware. Le procédé peut alors permettre d'étendre ou d'optimiser les performances et fonctionnalités de cette gestion de fonctionnement, en particulier en journalisation et rejeu de séquence d'instructions.

Dans le même esprit, l'invention propose aussi un système comprenant mettant en oeuvre le procédé, appliqué à un ou plusieurs système informatiques de type parallèle ou constituant un système parallèle, et possiblement utilisés en réseau.

D'autres particularités et avantages de l'invention ressortiront de la description détaillée d'un mode de mise en oeuvre nullement limitatif, et des dessins annexés sur lesquels: - la figure 1 est une illustration du fonctionnement, selon l'art antérieur, de l'accès à une mémoire commune entre deux tâches exécutées en parallèle par deux processeurs différents; - la figure 2 illustre, selon l'invention, la création et le maintien, au sein d'une tâche, d'une structure permettant le contrôle d'accès à des pages de mémoire partagées entre plusieurs tâches exécutées en parallèle sur plusieurs processeurs différents d'un même environnement; la figure 3 illustre, selon l'invention, le fonctionnement du contrôle d'accès à des pages de mémoires partagées par deux tâches exécutées en parallèle sur deux processeurs différents d'un même environnement.

En figure 1 est illustré un exemple de fonctionnement d'un environnement multiprocesseur parallèle, comprenant un premier processeur pProX et un deuxième processeur pProY dans un environnement multiprocesseurs, par exemple un système de type Linux. Ces deux processeurs exécutent en parallèle chacun une tâche, respectivement TA et TB, au sein d'un même espace de mémoire de travail RAM, et sont coordonnées par un ordonnanceur SCH. Au cours d'une période d'activation de chaque tâche TA et TB, une séquence SchA, SchB des instructions de son programme EXEA, EXEB va être exécutée dans un processeur pProX, pProY. Lors de l'exécution d'une instruction InstrA, InstrB de cette séquence, le processeur pourra utiliser des ressources qui lui sont internes telles des régistres RegA, RegB une pile PiIA, PiIB.

Au sein de la mémoire de travail RAM, plusieurs zones de mémoire partagées ShMPi à ShMPk sont définies, par exemple par une instruction de type map , et accessibles depuis les différentes tâches TA et TB directement par leur adresse physique.

La figure 1 illustre une situation de l'art antérieur, où les tâches TA et TB sont exécutées en parallèle sur une période commune et comprennent chacune une instruction InstrA et InstrB demandant un accès à une même zone de méoire partagée ShMPi. Ces deux demandes d'accès vont être traitées 11, 13 de façon indépendantes par le module gestionnaire de mémoire MMU de chaque processeur, et vont parvenir 12, 14 à cette zone mémoire partagée indépendamment l'une de l'autre.

Pour les ressources qui ne sont accessibles qu'à partir de certaines instructions de type appel système, il est possible d'instrumenter les routines systèmes réalisant ces instructions, c'est à dire de modifier ces routines ou d'insérer des éléments dans le système qui interceptent ou réagissent à ces appels systèmes. Dans le cadre d'une gestion de fonctionnement par journalisation et rejeu, cette instrumentation peut permettre en particulier d'enregistrer leur comportement pour pouvoir le rejouer ultérieurement à l'identique, ou de modifier ce comportement de façon à ce qu'il devienne déterministe et n'ait pas besoin d'être enregistré.

Pour des ressources accessibles directement sans appel système, donc potentiellement depuis n'importe quelle instruction de programme, la plupart des systèmes d'exploitation et en particulier ceux de type Unix ou Linux, ne permettent pas de contrôler l'ordre d'arrivée de ces accès au niveau de cette zone de mémoire partagée ShMPi.Pour résoudre ce problème, ainsi qu'illustré en figures 2 et 3, l'invention propose de modifier le code de certains éléments du logiciels système, ou d'en ajouter certains autres, de façon à détourner ou étendre certaines fonctions matérielles existantes, actuellement utilisées pour d'autres fonctions.

En particulier, il est possible de résoudre ce problème en modifiant un petit nombre d'éléments d'un logiciel système de type Unix ou Linux, et sans modifier les caractéristiques matérielles de processeurs courants. Il est alors possible d'utiliser des machines d'un type courant, donc économiques et bien au point, pour exécuter et gérer des applications multi-tâches peu ou pas modifiées, en n'apportant aux logiciels systèmes existants que quelques modifications qui ajoutent des fonctionnalités sans compromettre leur compatibilité ascendante.

L'invention utilise pour cela certains mécanismes existant dans nombres de micro-processeurs récents, tels que les processeurs utilisés dans les architectures de type PC, par exemple les processeurs Pentium de la société Intel, ou Athlon de la société AMD. Ces processeurs, en particulier depuis le Pentium 2, intègrent au sein de leur gestionnaire de mémoire MMU ( Memory Management Unit ) un mécanisme de gestion de mémoire virtuelle. Ce mécanisme est utilisé pour décharger dans le disque dur certaines pages définies dans la mémoire de travail quand elles ne sont pas utilisées, et les y entreposer pour libérer l'espace correspondant au sein de la mémoire physique. Pour les applications en cours d'exécution ces pages sont toujours répertoriées dans la mémoire de travail, mais elles doivent être chargées à nouveau en mémoire physique à partir du disque dur pour qu'une tâche puisse y accéder réellement.

Pour gérer cette mémoire virtuelle, ainsi qu'illustré en figure 3, le logiciel système comprend un gestionnaire de mémoire virtuelle VMM ( Virtual Memory Manager ), qui crée, pour chaque page de mémoire virtualisable, une table d'entrée de page PTE ( Page Table Entry ) au sein de chacun des différents processus applicatifs. Ainsi, pour deux tâches TA et TB exécutées chacune s sous forme de processus, c'est à dire avec un contexte d'exécution qui lui est propre, chacune des pages ShMPi à ShMPk se verra attribuer une table d'entrée de page PTEiA à PTEkA dans le processus de la tâche TA, ainsi qu'une table d'entrée de page PTEiB à PTEkB dans le processus de la tâche TB.

Le gestionnaire de mémoire virtuelle VMM comprend un agent logiciel chargeur de page PL, qui charge et décharge des pages mémoires dans un 10 - fichier de swap du disque dur, par exemple un fichier avec extension .swp dans le système Windows de la société Microsoft. Lors de chaque chargement ou déchargement d'une page ShMPi, son état de présence ou non en mémoire physique est mémorisé et tenu à jour 30 par le gestionnaire VMM dans chacune des tables d'entrée de pages PTEiA et PTEiB qui lui correspondent. Au sein de ces tables PTEiA et PTEiB, cet état de présence est mémorisé sous la forme d'un bit de donnée PriA et respectivement PriB, à la valeur 1 pour une présence et à la valeur 0 pour une absence.

Au sein de chaque processeur pProX et pProY, le gestionnaire de mémoire MMUX ou MMUY comprend un mécanisme PFIntX ou PFIntY d'interruption sur erreur de page ( Page Fault Interrupt ) par lequel passe toute demande d'accès en provenance d'une instruction de programme InstrAou InstrB en cours d'exécution. Lorsqu'une instruction InstrA d'une tâche TA exécutée par le processeur pProX demande 33 un accès portant sur une page de mémoire ShMPi, le mécanisme d'interruption PFIntA du processeur vérifie si cette page est présente en mémoire physique RAM, en prenant connaissance de la valeur de son bit de présence PriA dans la table d'entrée PTEiA correspondante.

Si ce bit PriA indique la présence de la page, le mécanisme d'interruption PFIntA autorise l'accès. Dans le cas contraire, ce mécanisme d'interruption PFIntA interromps l'exécution de la tâche TA et transmet les paramètres de l'erreur à un agent logiciel gestionnaire d'erreur de page PFH ( Page Fault Handler ) appartenant au gestionnaire de mémoire virtuelle VMM du logiciel système. C'est alors ce gestionnaire d'erreur PFH qui s'exécute et gère les conséquences de cette erreur au sein du logiciel système et vis à vis des applications.

La figure 2 illustre la façon dont ces mécanismes existants sont modifiés et adaptés ou détournés pour gérer l'accès aux ressources 30 partagées selon l'invention.

Pour gérer ces accès de la part d'une application APP exécutée dans un tel environnement parallèle, on utilise un logiciel lanceur LCH pour lancer l'exécution de cette application, par exemple dans un système de type Unix ou Linux. Lors de son lancement, l'application APP est crée avec - 11 une première tâche TA sous la forme d'un processus comprenant un fil d'exécution ou thread ThrAl, et utilisant une table de données formant un descripteur de tâche TDA.

Au sein de ce descripteur de tâche TDA, le lanceur mémorise 21 le fait que cette tâche TA doit être gérée, ou monitorée , en modifiant à 1 l'état d'un bit de donnée habituellement inutilisé, ici appelé bit de gestion MmA.

Les différentes zones de mémoire partagées en mémoire de travail, ici qualifiées de pages de mémoire partagée ShMPi, ShMPj, et ShMPk, sont répertoriées au sein de la tâche TA dans une table de données formant une structure de pages mémoires PMStrA. Dans cette structure PMStrA, les pages partagées sont décrites et mises à jour sous la forme de tables d'entrées de pages PTEiA1 à PTEkA1, comportant chacune un bit de données PriAl à PrKA1 utilisé par le gestionnaire de mémoire virtuelle VMM comme décrit précédemment. Typiquement, cette structure de pages PMStrA est crée en même temps que la tâche TA, et mise à jour 20 au fur et à mesure des changements dans la mémoire partagée par les différentes routines système qui assurent ces changements, telles que les routines de type map .

Au cours de l'exécution de l'application gérée APP, d'autres tâches peuvent être créer par des instructions CRE de type create , à partir de cette première tâche TA ou à partir d'autres crées de la même façon. Lors de toute création d'une nouvelle tâche TB, celle-ci comprend aussi un thread ThrBl et un descripteur de tâche TB,ainsi qu'une structure de pages mémoires PMStrB. Par relation d'héritage INH à partir de sa tâche mère, la nouvelle structure de pages PMStrB comprend elle aussi les différentes tables d'entrée de pages mages PTEiB1 à PTEkB1, avec leur bit de présence PriBl à PrkBl, qui sont maintenues à jour de la même façon.

Lors de la création CRE d'une nouvelle tâche TB à partir d'une tâche TA monitorée, le nouveau descripteur de tâche TDB comprend aussi un bit de gestion MmB, dont la valeur est héritée INH de celle du bit de gestion MmA de la tâche mère TA.

- 12 - Au cours de l'exécution de l'application gérée APP, d'autres threads peuvent être créés au sein d'une tâche TB qui fonctionnait initialement avec sous la forme d'un processus à un seul thread ThrBl.

Au sein d'une tâche TB existante et monitorée, tout nouveau thread ThrB2 est créé par un appel système, telle qu'une instruction clone . Typiquement, une tâche sous forme de processus multi-threads ne comporte qu'un seul jeu de tables d'entrée PTEiB1 à PTEkB1 au sein de sa structure de pages PMStrB. Selon l'invention, le fonctionnement de toute routine système pouvant créer un nouveau thread, telle que l'appel système clone est modifiée, par exemple en lui intégrant une partie supplémentaire CSUP. Cette modification est réalisée de façon à ce que toute création d'un nouveau thread ThrB2 dans une tâche existante TB comprend la lecture 22 du jeu de tables existantes PTEiB1 et la création 23 d'un nouveau jeu de tables d'entrée de pages PTEiB2 à PTEkB2, correspondant aux mêmes pages partagées ShMPI à ShMPk et fonctionnant spécifiquement avec le nouveau thread ThrB2. Cette modification peut par exemple se faire par une instrumentation de ces routines CLONE en utilisant une technique d'interposition dynamique par chargement de bibliothèques partagées au sein du système, tel que décrit dans le brevet FR 2 820 221 des mêmes demandeurs.

Cette création est faite de façon à ce que les nouvelles tables PTEiB2 à PTEkB2 soient aussi mises à jour 24, 25 de façon similaire à leurs tables mères PTEiB1 à PTEkB1, soit en les inscrivant pour mise à jour auprès des routines systèmes MAP gérant cette mise à jour, soit en instrumentant aussi ces routines systèmes MAP, par exemple en leur intégrant une partie supplémentaire MSUP.

La figure 3 illustre le fonctionnement de la gestion d'accès utilisant cette structure appliqué à un exemple comprenant deux tâches monothreads TA et TB exécutées en parallèle dans deux processeurs pProX et pProY. Il est à noter que l'extension de la structure des tables d'entrées de page PTE à chaque thread ThrB2 cloné au sein de chaque tâche permet aussi de gérer de la même façon les accès venant de tous les thread appartenant à des tâches monitorées, qu'elles soient mono-thread ou mufti-threads.

- 13 - Dans le mode de réalisation décrit ici, la gestion d'accès selon l'invention est agencée pour garantir à chaque tâche, au sens du processus TA mais aussi au sens de chaque thread ThrBl ou ThrB2, un accès aux pages mémoires partagées qui soit exclusif sur tout la durée d'une période d'activation ou leur cohérence (ou consistence) est garantie par le logiciel système. Une telle période est ici décrite comme étant une période d'activation allouée et gérée par l'ordonnanceur SCH du logiciel système. Il est clair que d'autres types de période de cohérence peuvent être choisies dans le même esprit.

De même, les ressources partagées dont l'accès est géré ou contrôlé sont ici décrite sous la forme de mémoire partagée définies en tant que zones unitaires de mémoire ou pages mémoire. Le même concept peut bien sûr aussi s'appliquer à d'autres types de ressources moyennant une instrumentation similaire des routines systèmes leur correspondant. La mise en oeuvre de l'invention peut comprendre une modification de

certains éléments du logiciel système, de façon à ce qu'ils fonctionnent tel que décrit ci-après. Le niveau de modification nécessaire peut bien sûr varier suivant le type ou la version du logiciel système. Dans le cas d'un système de type Linux, ces modifications comprennent en général l'instrumentation des routines de type clone et map tel que décrit précédemment, ainsi que des modifications et ajouts de code au sein des agents réalisant l'ordonnanceur SCH, le gestionnaire d'erreur de page PFH ( page fault handler ), et le chargeur de page PL. Les fonctionnalités systèmes à modifier pour réaliser le type de contrôle d'accès décrit ici peuvent avantageusement constituer exclusivement des extensions par rapport aux fonctionnalités du système standard, c'est à dire sans suppression de fonctionnalité ou du moins sans compromettre la compatibilité ascendante avec les applications développées pour la version standard.

Par ailleurs, bien qu'utilisant le mécanisme matériel prévu dans le processeur pour la gestion de la mémoire virtuelle, le contrôle d'accès décrit peut être ne nécessite pas forcément la désactivation de cette mémoire virtuelle et peut être compatible avec elle. Le chargeur de page PL peut par exemple être instrumenté ou modifié de façon à ce que le - 14chargement en mémoire physique RAM d'une page virtuelle ShMPi ne soit pas répercuté dans le bit de présence PriB de cette page auprès d'une tâche TB monitorée si cette page est déjà utilisée par une autre tâche TA.

Au début d'une de ses périodes d'activation SchA, une tâche TA est libérée par l'ordonnanceur SCH en un instant SCHAL. Avant de libérer cette tâche, l'ordonnanceur SCH teste 31 le bit de gestion MmA de cette tâche TA pour savoir si le contrôle d'accès doit s'appliquer à elle. Si c'est le cas, l'ordonnanceur SCH va alors 32 positionner à 0 tous les bits de présence PriA à PrkA des tables PTE correspondant à toutes les pages partagées concernées par ce contrôle d'accès, de façon à ce que toute demande d'accès de cette tâche TA provoque par défaut une erreur de page au niveau du mécanisme d'interruption PFIntX de tous les processeurs pProX où pourra être exécutée cette tâche TA.

Au cours de cette période d'activation SchA au sein du processeur pProX, une instruction InstrA demande 33 un accès à une page de mémoire partagée ShMPi. Du fait que le bit de présence PriA correspondant est à 0, le mécanisme d'interruption PHIntX du processeur pProX suspend l'exécution de cette demande d'accès et appelle le gestionnaire d'erreur de page PFH du logiciel système, en lui transmettant l'identification de la page et de la tâche concernées.

Lors du traitement de cette erreur, une fonctionnalité supplémentaire PFHSUP du gestionnaire d'erreur de page PFH effectue alors une opération de test et/ou modification au sein d'une table de données formant l'agent noyau de structure de la mémoire KMStr ( Kernel Memory Structure ) à l'intérieur du gestionnaire de mémoire virtuelle VMM du logiciel système.

Typiquement, cet agent noyau de structure mémoire KMStr mémorise de façon univoque pour l'ensemble de l'environnement de travail, ou de la mémoire de travail, des informations représentant la structure des ressources de mémoire et leur évolution. Selon l'invention, cet agent noyau de structure mémoire KMStr comprend également un ensemble de bits de données, appelés ici bits d'accès KSi, KSj et KSk qui représentent, pour chacune des pages partagées ShMPi à ShMPk concernées, le fait qu'un accès à cette pag est actuellement accordé (bit à 1) ou non (bit à 0) à une tâche.

- 15 - Lorsque le gestionnaire d'erreur page PFH traite l'erreur transmise par le processeur pProX, il consulte 34 le bit d'accès KSi correspondant à la page concernée hMPi. Si ce bit d'accès n'indique pas d'accès en cours, il modifie 34 ce bit l'accès KSi pour mémoriser qu'il accorde un accès à cette page, et modifie 5 aussi le bit de présence PriA correspondant de la tâche TA demandeuse ()it passant à 1) pour mémoriser le fait que cette tâche TA a maintenant un ccès exclusif à la page concernée ShMPPi.

Il est à n^ ter que ces opérations de test et modification du bit d'accès KSi de I i structure noyau de mémoire KMStr constituent une opération 34 qui g st implémentée de façon atomique, c'est à dire dont il est garanti qu'elle SE déroule soit complètement soit pas du tout, même en environnement m alti-processeurs.

Une fois lue le gestionnaire d'erreur page PFInt a attribué l'exclusivité sur la page demandée ShMPi, il relance l'exécution de l'instruction Instr de façon à ce qu'elle accède 36 effectivement au contenu de cette gage.

Si une ins ruction InstrB d'une autre tâche TB monitorée quelle qu'elle soit, exéci tée en parallèle par un autre processeur pProY, demande 37 alors un acc ?s à cette page ShMPi déjà attribuée, le mécanisme d'interruption PFl 1tY de ce processeur va lui aussi consulter le bit de présence PriB de ette page pour la tâche TB demandeuse. Puisque la tâche TB est une tâche nonitorée, le bit de présence PriB consulté est en position d'absence (valeu - à 0). Le mécanisme d'interruption PFIntY va donc suspendre l'instru;tion InstrB demandeuse et transmettre 38 une erreur au gestionnaire d'err pur de page PFH.

Cette fois, ce gestionnaire d'erreur page PFH constate que le bit d'accès KSi de cE:te page est à 1, indiquant qu'une exclusivité a déjà été accordée sur cett page ShMPi à une autre tâche. Le gestionnaire d'erreur PFH va alors déc ?.ncher 39 une suspension de l'ensemble de la tâche TB demandeuse, par exemple en mettant fin à sa période d'activation auprès du gestionnaire d changement de contexte du logiciel système. Lors de sa prochaine périod d'activation, cette tâche TB reprendra alors son exécution exacter lent au point où elle s'était interrompue, et pourra tenter à nouveau d'accé^ er à cette même page ShMPi.

- 16 - Dans le cal où la tâche demandeuse est un thread ThrB2 (figure 2) appartenant à ur processus multi-threads, l'existence d'un jeu de tables d'entrée de page! PTEiB2 spécifiques à ce seul thread ThrB2 permet de ne suspendre que le thread qui demande l'accès à une page déjà allouée en accès exclusif, et non les autres threads ThrBl qui n'entreraient pas en conflit avec cette xclusivité.

A l'issue S HAS de la période SchA d'activation de chaque tâche, l'ordonnanceur s ispend l'exécution de cette tâche et sauvegarde son contexte d'exécut on.

Lors de cet e suspension SCHAS ou lors d'une suspension 39 sur une demande de paç ?. déjà allouée, l'invention prévoit aussi une phase de libération de tout, s les pages de mémoires partagées pour lesquelles cette tâche a reçu un ccès exclusif. Ainsi, lorsque l'ordonnanceur SCH constate 301 par le bit de gestion MmA que la tâche TA en cours de suspension est monitorée, il par:ourt l'ensemble des tables d'entrée de page PTEiA à PTEkA de cette t che pour savoir sur quelles pages elle dispose d'un accès exclusif, en consi. Itant l'état des différents bits de présence PriA à PrkA. A partir de cette inf)rmation il va alors libérer l'ensemble de ces pages ShMPi en réinitialisant 0 leur bit d'accès KSi dans la structure noyau de mémoire KMStr.

Dans d'aut es variantes non représentées, il est aussi possible de découpler la notic de gestion ou monitorage en plusieurs types de gestion, par exemple en)révoyant plusieurs bits de gestion au sein d'un même descripteur de t che. Ainsi une tâche peut être monitorée de façon à bénéficier d'un ac:ès exclusif vis à vis de certaines catégories de tâches. De même, une tâchc peut ne se voir exclue que par certaines catégories de tâches.

Ainsi, en st. ;pendant toutes les tâches qui cherchent à accéder à une page déjà allou( e, on obtient une exclusivité de cette page pour la première tâche qui la demande, sans perturber la cohérence du déroulement des autres tâches ainsi suspendues.

En évitant 1 pute modification d'une même zone de mémoire partagée par deux tâcher s'exécutant en même temps, on évite ainsi toute interférence entrE elles dans l'évolution du contenu de cette zone mémoire.

- 17 - A partir d'un état initial déterminé, pour cette zone mémoire, au début de chaque période c 'activation d'une tâche qui y accède, l'évolution de son contenu ne déper d donc que des actions de cette tâche au cours de cette période d'activa ion. Pour une séquence déterminée d'instructions exécutées par tette tâche, par exemple une période d'activation ordonnancée, el en partant d'un état initial connu, il est ainsi possible d'obtenir un dér)ulement de cette séquence qui soit déterministe et répétable vis à vis de cette tâche.

Du fait, en particulier, de l'utilisation d'une opération atomique pour mémoriser l'alloc ition d'exclusivité sur la zone de mémoire accédée, le procédé permet d'éviter ou de diminuer les risques d'interblocage ( deadlock ) d ane même ressource partagée entre plusieurs tâches cherchant à y acc der concurremment.

De plus, ( u fait de l'implémentation le plus souvent purement logicielle de l'invE ntion, il est possible d'utiliser du matériel standard avec les avantages que cela comporte.

Il est à ne:er que le fonctionnement du contrôle d'accès décrit ici utilise la partie Lgicielle de façon bien dissociée de la partie matérielle, dans le sens où n le logiciel système ni l'application n'a besoin de savoir ou de fixer le choix c a processeur dans lequel sera exécutée chaque tâche lors de sa libération. )n obtient ainsi une bonne indépendance par rapport au matériel, ce qui, n particulier, rend l'implémentation plus simple et plus fiable et conserve de bonnes performances en laissant l'architecture gérer elle-même au mil ux le parallélisme des différents éléments de calcul, qu'il s'agisse de proce seurs ou d'ordinateurs.

L'invention permet en particulier d'étendre aux environnements parallèles des tec iniques de gestion de fonctionnement développées pour des applications nulti-tâches fonctionnant en temps partagé sur un seul élément de calcul L'invention permet ainsi en particulier d'intégrer de tels environnements iarallèles dans des réseaux ou clusters, dans lesquels cette gestion de 1)nctionnement est implémentée au sein d'une application de type middlewa.e, par exemple pour gérer des applications distribuées ou des applications à déploiement variable fournissant un service à la demande ( on dg mand ) - 18 - Bien sûr, I invention n'est pas limitée aux exemples qui viennent d'être décrits et c e nombreux aménagements peuvent être apportés à ces exemples sans so tir du cadre de l'invention.

- 19 -

Claims (13)

REVENDICATIONS

1. Procédé de gestion d'accès, mis en oeuvre par un logiciel système gérant par active:ion séquentielle une pluralité de tâches de programme (TA, TB) au sein d'au moins une application informatique (APP) exécutée dans un systèmE informatique dit parallèle comprenant une pluralité de moyens de calcul aptes à exécuter plusieurs tâches simultanément dans au moins deux unité de calcul (pProX, pProY), ce procédé gérant l'accès à au moins une ressoL te partagée, dite ressource cible (ShMPi), accessible par lesdites tâches (T /, TB), caractérisé en ce que, au cours d'au moins une (SchA) de ses périodes d'activation, une) remière tâche dite tâche accédante (TA), en réponse à une demande d'a:cès (InstrA) à ladite ressource cible, se voit attribuer un accès, dit contins, à ladite ressource cible, c'est à dire de façon à exclure tout accès à ladi:e ressource cible (ShMPi) par au moins une deuxième tâche (TB) penda It la totalité de la période d'activation (SchA) de la tâche accédante suivant immédiatement ladite demande d'accès

2. Procédé se)n la revendication 1, caractérisé en ce qu'au moins une des unités de r alcul (pProX) comprend un mécanisme d'interruption (PFIntX) capable, en fonction de la valeur d'au moins une donnée, dite de présence (PriA), r iémorisée au sein de l'espace mémoire (RAM) du système informatique parallèle, d'interrompre l'exécution d'une instruction de programme deme Idant un accès à une ressource déterminée, déclenchant ainsi un appel un agent logiciel gestionnaire d'erreur, ce procédé comprenant en or tre les étapes suivantes: - interruption (PFIntX, PFIntY) de l'exécution de la première instruction (InstrA, In5:rB) demandant (33, 37) un accès à la ressource cible (ShMPi) au:ours d'une période d'activation (SchA, SchB) de la tâche accédante (-A, TB) ; - test (34) p, r le gestionnaire d'erreur (PFH) d'au moins une donnée dite d'accès (KSi) mémorisée dans ledit espace mémoire et indiquant si ladite res source cible est actuellement attribuée à une autre tâche en un accès continu excluant ladite tâche accédante (TA, TB) ; dans le cas de l'existence d'un tel accès continu déjà attribué à une autre tâchE (TA), suspension (39) de l'exécution de la tâche accédante ("B) ou clôture de sa période d'activation; dans le cas contraire, mémorisation (34) dans ledit espace mémoire d'au moins une donnée d'accès (KSi) représentant l'attribution à la tâche accéd ante (TA) d'un accès continu portant sur ladite ressource cible (ShMP - ; lors de l'exÉ :ution de la dernière instruction de la période d'activation (SchA) de la tâche accédante (TA) ou postérieurement à cette dernière in truction, modification (303) de la donnée d'accès (KSi) représentan: son accès continu obtenu pour la ressource cible de façon à libéi ar celle-ci (ShMPi).

3. Procédé SE on la revendication 2, caractérisé en ce que, lorsque l'étape de test dl la donnée d'accès de la ressource cible indique que la ressource est libr 3 pour la tâche accédante, l'étape de mémorisation d'un accès continu qui suit ladite étape de test constitue avec cette étape de test une seule opérati)n (34) atomique au sein du fonctionnement du système informatique para lèle.

4. Procédé se)n l'une des revendications 2 ou 3, caractérisé en ce qu'il comprend en ou re, postérieurement ou lors de la suspension (SCHAL) d'une tâche (TA) par un agent logiciel dit ordonnanceur (SCH), une étape de clôture comp -enant un test (302) de l'ensemble des données de présence (PriA à rkA) correspondant à la tâche suspendue (TA) de façon à identifier et libér r l'ensemble des ressources partagées pour lesquelles ladite tâche suspE ndue détient un accès continu.

5. Procédé se)n l'une des revendications 2 à 4, caractérisé en ce qu'il comprend en out.e, préalablement ou lors de la libération (SCHAL) d'une tâche (TA) par n agent logiciel dit ordonnanceur (SCH) débutant une période d'activati n (SchA) de ladite tâche, une étape d'initialisation (33) des données de résence de ladite tâche correspondant à l'ensemble des ressources partaç =es (ShMPi à ShMPk) accessibles par ladite tâche (TA), de - 21 - façon à ce que chaque première demande d'accès de cette tâche à ces ressources parta^ ées, au cours de ladite période d'activation, déclenche une telle interrupi on (PFIntX).

6. Procédé SE on la revendication 5, caractérisé en ce que l'étape d'initialisation (3:) des données de présence est subordonnée au résultat d'un test (31) ie la valeur d'une donnée dite de gestion (MmA), correspondant à a tâche libérée (TA) et indiquant si ladite tâche doit ou non être monitor e, c'est à dire se voir appliquer le procédé de gestion d'accès.

7. Procédé sel)n l'une des revendications 1 à 6, caractérisé en ce qu'au moins une tâche ouvelle (ThrB2) est instanciée ou créée par au moins un agent logiciel de création (CLONE, CSUP) à partir d'une tâche existante (ThrBl), cette cr ration comprenant la création (22, 23) d'au moins une donnée de préser ce (PriB2) correspondant à ladite nouvelle tâche (ThrB2) et se rapportant; une ressource partagée (ShMPi), à partir d'une donnée de présence (PriE 1) correspondant à ladite tâche existante (ThrBl) et se rapportant à ladit, . ressource partagée.

8. Procédé se)n la revendication 7, caractérisé en ce que qu'au moins une donnée de pr.sence (PriB2) correspondant à la nouvelle tâche (ThrB2) est mise à jour p r un agent logiciel d'allocation (MAP, MSUP) en fonction des modifications apportées à la ressource partagée (ShMPi) à laquelle se rapporte ladite do Inée de présence.

9. Procédé se)n l'une des revendications 6 à 8, caractérisé en ce que l'exécution d'au noins une application (APP) comprenant au moins une tâche monitorée 1 TA) est lancée par un agent logiciel dit lanceur (LCH) qui mémorise au ma ns une donnée de gestion (MmA) indiquant que ladite tâche (TA) doit êt e monitorée.

10. Procédé se)n l'une des revendications 1 à 9, caractérisé en ce qu'il est mis en oeuvr au sein d'un système d'exploitation de type Unix ou - 22 - Linux, et comprend une modification ou instrumentation des appels systèmes de typ create , ou clone , ou map , ou de l'agent logiciel ordonnant eur (SCH) ou des routines de libération et suspension du gestionnaire de et angement de contexte, ou de l'agent logiciel gestionnaire d'erreur de pagE (PFH), ou des tables de données noyau de structure mémoire (KMStr)

11. Procédé se)n la revendication 10, caractérisé en ce qu'au moins un appel système est instrumenté par une technique d'interposition 10 dynamique utilisa it une bibliothèque préchargée de routines modifiées.

12. Procédé se)n l'une des revendications 1 à 11, caractérisé en ce qu'il est mis en oeuvre au sein d'au moins un noeud d'un réseau d'ordinateurs.

13. Système nettant en oeuvre un procédé selon l'une des revendications 1 < 12.