Brevet FR2881241A1 — publié le 20060728

Procédé d'op imisation de la journalisation et du rejeu d'applications multitâche dar; un système informatique mono-processeur ou multiprocesseurs La présent invention concerne un procédé de gestion, plus particulièrement ^ar contrôle externe, transparent et non intrusif, du déroulement d'uni ou plusieurs tâches logicielles au sein d'une application multitâche exécut e sur un ordinateur ou un réseau d'ordinateurs. Cette gestion comprend en particulier un enregistrement du déroulement de ces tâches sous form, de données de journalisation, ainsi qu'un rejeu de ce déroulement à p 3rtir de telles données de journalisation de façon à présenter un corn)ortement et un résultat correspondant à ceux obtenus lors de la journalis 3tion. L'invention oncerne également un système mettant en oeuvre un tel procédé dans la g ?stion du fonctionnement des applications logicielles qu'il exécute. Une gestion de fonctionnement non intrusive et transparente vis à vis de l'application gg rée est très intéressante à implémenter, en particulier pour pouvoir utilis les nombreuses applications existantes, dans leur état d'origine ( legacy applications ), avec plus de souplesse ou de fiabilité ou de performance. Des technik ues de gestion de fonctionnement non intrusive par capture intermédi lire et restauration de l'état d'une application lors d'un point de synchron sation ou point de reprise ( checkpoint ) ont déjà été proposées par k s mêmes demandeurs dans la demande de brevet FR 04 07180. De açon complémentaire, des techniques non intrusives de journalisation et r jeu ont déjà été proposées par les mêmes demandeurs, en particulier dans les demandes de brevet FR 05 00605 à FR 05 00613. Cependant, a journalisation d'un ou plusieurs évènements représente toujours une sur:harge de travail pour l'application journalisée ou le système qui l'exéc ate, qu'il est intéressant de minimiser le plus possible. Parmi les é 'ènements constituant le déroulement d'une application, ceux qui ont un comportement non déterministe vis à vis de l'état de l'application doive t être journalisés et rejoués en mémorisant leur résultat dans des donnée! de journalisation, pour pouvoir forcer ou réinjecter ce résultat lors d'un -ejeu ultérieur. Il est donc intéressant de réduire le plus possible le nom)re d'évènements devant être traités comme non déterministes. Les évènerr ?.nts externes à l'application ou au système qui l'exécute ont souvent un co nportement non déterministe par nature, et doivent être en général être m morisés, par exemple comme décrit dans les demandes citées plus haut. Parmi les éN nements internes à l'application gérée, Lorsque tot s les évènements d'une portion du déroulement sont déterministes, l'er semble de cette portion peut être journalisée de façon économique en mi morisant simplement l'état de départ de l'application, par exemple sous la 1)rme d'un point de reprise. Le rejeu s'obtient alors par exemple en restai rant l'application dans l'état de point de reprise tel que mémorisé, et er lançant simplement l'exécution de ces évènements déterministes. On peut alors parler d'un modèle d'exécution déterministes par morceaux ( F iecewise dterministic execution model ), comprenant un assemblage de portions déterministes composées uniquement d'évènements dé erministes. Les portions déterministes sont alors en général bornées)ar des évènements non déterministes, par exemple commençant pari ne arrivée d'un message externe et se terminant par un autre événement r on déterministe. Un but de I' nvention est de simplifier ou d'optimiser la journalisation et le rejeu d'une ti Ile portion déterministe. Certaines d!s demandes citées ci-dessus décrivent des techniques permettant de dir iinuer le coût en charge de calcul de la mémorisation (compression heur istique ou prédictive). D'autres proposent d'instrumenter certaines routines d'appels systèmes pouvant être non déterministes pour rendre leur compo tement déterministe. Parmi les é^ ènements internes, qui sont les plus nombreux, certains conservent cepenc ant un comportement qui peut être non déterministe ou cause de non d terminisme, en particulier des évènements internes accédant à des r ssources partagées telles que des zones de mémoire partagées ou des r émaphores ou des mutex. Un autre lx: de l'invention est de diminuer le nombre d'évènements devant être traité comme non déterministes lors d'une journalisation et/ou rejeu. De plus, ce tains types d'architecture informatique peuvent inclure des causes de non déterminisme par fois inhérentes à leur nature même, en particulier les s' stème à architecture parallèle, parfois qualifiée de parallélisme physil ue ou réel. De tels env -onnements parallèles sont en général conçus et utilisés pour obtenir, à I artir d'éléments matériels existants, une plus grande puissance de calci I. Il s'agit le plus souvent de réaliser des calculs lourds et complexes, au s!in d'applications techniques ou scientifiques conçues essentiellement dE ns cette optique. Un tel enm ironnement peut être réalisé en intégrant plusieurs processeurs au se n 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 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 c!s différents éléments unitaires, processeurs ou ordinateurs, sont capables de travailler en même temps sur des tâches différentes qui SE -ont réordonnancées ensuite, on parle de parallélisme physique, par exe nple par opposition à un parallélisme qui serait simulé en partageant le tel 1ps de travail d'un seul élément en plusieurs zones virtuelles de trava. Les enviror nements existants dotés de capacités de parallélisme physique, qu'ils s', gisse de multi-processeurs ou de multi-ordinateurs, sont le plus souvent cc nç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 écouplée, et avec très peu de coordination entre eux. Or, par ex mple pour des raisons de coût ou de souplesse, on cherche souvent i remplacer de gros ordinateurs centraux par des microordinateurs ou stE:ions de travail, seuls ou en groupes. De telles machines existent en versioi multiprocesseurs travaillant en parallélisme pour plus de puissance, ou peu lent ê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 uniqt e vis à vis de l'extérieur. Il peut alc -s être intéressant d'utiliser de tels environnements parallèles pour e écuter des applications différentes ou plus variées, en particulier des aF Dlications multi-tâches de type transactionnel qui sont courantes dans dl s domaines de gestion d'entreprises, ou de réseaux de postes de travail, Mu de réseaux de communications. De telles applications ont souvent des structures plus variées et comportent très souvent plusieurs tâches c ui utilisent des ressources partagées au sein du même environnement. Cependant, du fait que ces systèmes d'exploitations ou ces applications sont:onç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éelle vent en même temps, comme c'est le cas pour un parallélisme physi lue. 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 pa une tâche pourra être très différent selon qu'une modification par 'ne autre tâche sera intervenue avant ou après cette lecture. Or la plupa t des systèmes d'exploitation multi-tâches ne sont pas prévus pour gére. un environnement travaillant en parallélisme réel, et encore moins pou - gérer des ressources partagées en accès direct. Parmi les types de resso arces partagées, on peut qualifier d'accès direct celles qui sont accessibles p 3r adressage depuis une instruction programme, comme des zones de mén offre 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 à l'autres ressources partagées qui nécessitent un appel système, telles c ae des ressources à passage de messages du genre pipe ou sol ket utilisant des appels systèmes comme open , read ou wri' 2. . 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,ies environnements parallèles. Un autre but de l'invention est alors faciliter ou d'optimiser l'implémentation de fonctions de journalisation et rejeu, et de diminuer les causes de non-d terminisme au sein d'un environnement parallèle, en particulier pour le!; applications multitâches. Dans le ci dre d'une gestion de fonctionnement en architecture redondant, un vautre but de l'invention est alors de fiabiliser le fonctionnement d'une application multitâche exécutée en environnement parallèle. 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 u le ou plusieurs applications de gestion de fonctionnement de type middlew are. Le procédé peut alors permettre d'étendre ou d'optimiser les performances et fonctionnalités de cette gestion de fonctionnement, ,an particulier en journalisation et rejeu de séquence d'instructions. Dans le riême esprit, l'invention propose aussi un système comprenant mettant en oeuvre le procédé, appliqué à un ou plusieurs système informai:iques 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 s Jr lesquels: - les figures 1 Et 2 illustrent une journalisation de l'ordonnancement de l'exécution des tâches au sein d'un processeur, par comptage des tâches selon l'invention; - les figures 3 et 4 illustrent selon l'invention un rejeu d'une période d'activité d'une tâche par comptage d'instructions dans un processeur; -la figure 5 i lustre selon l'invention un rejeu déterministe d'une application mu titâche dans un système monoprocesseur, obtenu à partir d'une journalisation, par comptage d'instructions, de l'ordonnancement des tâches dans un processeur; - la figure 6 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 7 illu:;tre, selon l'invention, la création et le maintien, au sein d'une tâche, dune structure permettant le contrôle d'accès à des pages de mémoire pz rtagées entre plusieurs tâches exécutées en parallèle sur plusieurs processeurs différents d'un même environnement; la figure 8 iII astre, 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; la figure 9 illustre, selon l'invention, une journalisation d'une application multitâche sur un ordinateur multiprocesseurs et son rejeu au fur et à mesure sur une machine monoprocesseur. Les techniques décrites ici correspondent à des modes de réalisation de l'invention utili;ant certaines caractéristiques des processeurs des types employés dans de; ordinateurs de type PC, par exemple des processeurs de type Athlon de la société AMD ou des processeurs Pentium de la société Intel. D'autres processeurs actuels, par exemple utilisés dans des stations de travail, ou futurs peuvent bien sûr présenter tout ou partie de ces caractéristiques ou de caractéristiques similaires, et être employés pour réaliser l'invention. Les figures 1 à 2 présentent une technique de journalisation des différentes portons d'évènements internes déterministes exécutées successivement per un même processeur pProX ou unité de calcul. Ainsi qu'illu:;tré en figure 1, différentes tâches TA et TB peuvent être exécutées par p)rtions, appelées périodes d'activation Schl à Sch3, successivement lancées par l'ordonnanceur SCH, faisant partie d'un agent système appelé çestionnaire de contexte et qui gère ces alternances ou entrelacement. Parmi les différentes tâches exécutées au sein du système informatique ou d'un processeur, certaines peuvent faire partie d'une application que l'cn cherche à gérer et seront qualifiées de monitorées . Ces tâches sont identifiées par l'état (mis à 1) d'un bit de donnée habituellement inutilisé au sein du descripteur de tâche, ici appelé bit de gestion MmA ou P1mB (cf. figure 7). Au sein de la succession des périodes d'activation exécL tées dans un processeur peuvent alterner des tâches monitorées et d'ai tres qui ne le sont pas. Pour les tâches monitorées TA et TB, marquées en figure 1 par une lettre m , les périodes d'activation sont établies de façon à n'être composées que c 'événements déterministes. Ces périodes déterministes sont définies par un ou plusieurs agents logiciels de journalisation. Cet agent de journal sation peut comprendre des éléments exécutés dans l'espace mémoire utilisateur du système informatique, en tant que tâche d'une application de gestion de fonctionnement. Cet agent de journalisation peut aussi comprE ndre ou utiliser des éléments modifiés ou ajoutés au sein du logiciel système, par exemple au sein de l'ordonnanceur. Du fait que la majorité des évènements d'une application sont des évènements internes, et que nombres d'entre eux sont déterministes, une grande partie ce chaque tâche gérée se compose d'évènements déterministes. Cheque fois qu'intervient un événement déterministe, l'agent de journalisation clôture une période déterministe. L'évènement non déterministe déte,:té est alors exécuté, possiblement sous la forme d'une tâche non monitorée, et est journalisé avec son résultat selon une méthode connue. A l'issue de cet événement non déterministe, l'agent de journalisation définit le début d'une nouvelle portion déterministe et relance le comptage des instructions. La journalisation, et possiblement le traitement, des évènements non déterministes est réalisée en dehors des périodes d'activation déterministes, par exemple dans une période d'exécution K1 ou K2 en mode kernel KLv c'est à dire lorsque le mode privilégié du processeur ( processor privilege mode ) est à IE valeur 0, par opposition à la valeur 3 pour le mode utilisateur ( user mode ) Ulv. Pour pouvcir rejouer chaque période d'activation de façon identique que lors de la journalisation, l'invention réalise un comptage des instructions exécutées au cours de cette portion déterministe lors de la journalisation. Lois d'un rejeu RSCH (cf. figures 3 et 4) ultérieur de ces tâches, cette pore ion journalisée n'a donc qu'à être lancée à partir d'un même état que le rs de la journalisation, pour s'exécuter seule jusqu'à un nombre d'instructions de rejeu correspondant exactement au nombre d'instructions exécutées lors de la journalisation par cette même portion et pour cette mêmE tâche. Ce rejeu s'effectue alors sans intervention de forçage de résultats au sein d'une portion déterministe, puis que celle-ci ne contient que des évènements déterministes. Lorsqu'une portion déterministe s'étale sur plusieurs périodes d'activation étables par l'ordonnanceur, chacune de ces périodes d'activation comprend une partie de cette portion déterministe qui peut être traitée elle-même comme une portion déterministe complète. Dans la suite de la description, on ne décrira que la journalisation de périodes d'activation déterministes, mais il est clair que plusieurs périodes d'activation déterministes peu'ient se suivre au sein d'une même portion déterministe. Selon l'invention, ce comptage des instructions d'une période d'activation déterriniste utilise un compteur de performance et de suivi, qui est une particularité matérielle existant actuellement dans un grand nombre de processeurs, 'De exemple à partir du Pentium 2 pour la famille Pentium de la société Intel, Ce compteur de performance et de suivi ( Performance and Monitoring Counter ) est prévu pour mesurer le fonctionnement du processeur, en dL rée ou en nombre d'événement et sert principalement à mesurer les performances, par exemple pour réaliser des analyses statistiques de profils d'applications, par échantillonnage périodique de ses valeurs. Les con:;tructeurs de processeurs précisent d'ailleurs que ces compteurs de performances ne présentent pas une exactitude garantie et doivent être utili L'invention)ropose d'utiliser une des caractéristiques de ce compteur de performance PMC, à savoir le comptage des instructions dites retirées, c'est à dire qui;ont résolues ou ont quitté la liste des instructions à exécuter, indépendamment des diverses techniques spéculatives ou de cache pouvant ft ire exécuter certains instructions à l'avance pour des raisons de performances. Cependant, ce comptage d'instructions retirées présentent certaines caractéristiques limitatives qui sont décrites dans les documentations des sociétés Intel et 4MD. Une première de ces caractéristiques est que les instructions de lecture ( RDPMC ) de ce compteur ne sont pas intégrées directement dans es instructions à résoudre, ce qui n'a pas de conséquence directe sur l'utilisation de ce compteur dans le cadre de l'invention. Par contre, deux autres caractéristiques limitatives peuvent être à l'origine d'impréci:;ions dans le comptage d'instructions pour journalisation et rejeu et doivent être prises en compte. Une quatrième caractéristique pouvant constituer un handicap est le fait que l'interruption de l'exécution par débordement du compteur peut intervenir avec un certain retard après l'instruction ayant provoqué ce débordement. Ces limites d'imprécision concernent d'une part les cas de certaines instructions complexes qui peuvent être comptées deux fois si interrompues avant résolution, et d'autre part des instructions avec interruption matérielle qui pe avent causer un non-comptage d'une instruction. Pour pallier à cette imprécision, l'invention utilise une technique de confirmation complémentaire q ai permet de lever les doutes sur la détermination exacte de la fin d'une pér ode d'activation. Ainsi qu'illu;tré en figure 1, une succession de périodes d'activation 20 déterministes Sch 1, Sch2 et Sch3, exécutées dans un processeur pProX sont journalisées cet enregistrées dans un fichier journal JpProX. Au cours d'une période d'activation journalisée Sch3 où le processeur exécute une tâche TA monitorée, une ou plusieurs lectures RDPMC de la valeur UIVX du compteur PMC fournit un nombre NJ3 d'instructions retirées. A la suspension (lin Sch3) de cette période Sch3, l'agent de journalisation 3SCH utilise une ou plusieurs données d'état issues de l'état de la tâche TA et de son contexte pour calculer une ou plusieurs données représentant cet état de façon suif samment univoque pour lever les doutes pouvant exister sur le nombre e> act d'instructions exécutées au cours de cette période d'activation Sch3 Ces données d'état constituent une signature SG3 correspondant à tette fin de période Sch3. Cet signature comprend en particulier la valeur exacte IPJX3 du pointeur d'instruction immédiatement après la dernière nstruction de cette période, c'est à dire une identification exacte de la position, au sein de l'exécutable de la tâche TA, de l'instruction - 10 - de programme e> écutée en dernier. Cette signature comprend aussi une donnée de contrôle ( checksum ) calculée à partir des valeurs lues dans registre RegJX3 el la pile d'appel PileJX3 du contexte de la tâche TA lors de cette suspension (fin Sch3). Pour chacu ie des périodes SchJ (figure 3) journalisées, le journal pProX de ce proce;seur comprend ainsi une ligne associant en particulier: - une identification de la tâche TJ exécutée dans cette période, par exemple le Ainsi, pour la succession des tâches TA puis TB puis TA illustrée en figure 1, le journal du processeur pProX comprendre les lignes successives suivantes: idA: N33: SG3 idB: N32: SG2 idA: NJ1: SG1 Ainsi qu'illustré en figure 2, la succession des différentes tâches journalisées d'une application journalisée APPJ au sein d'un processeur déterminé pProX peut aussi être transmise d'abord par l'agent de journalisation JSCH à une file d'attente de journalisation QJpProX de type FIFO ( First In First Out ). Les lignes de journalisation en sortie de cette file d'attente sont lues par une tâche de mémorisation de journal TJpProX, qui déclenche la mémorisation dans de ces lignes de façon ordonnée dans le journal JpProX de ce processeur, soit en local MEM soit par une transmission TRANS vers un autre noeud ou une station ou un périphérique de sauvegarde. L'util sation d'une telle file d'attente de journalisation sert en particulier de zonE tampon pour réguler le flot de données de journalisation et éviter de perturber l'application journalisée ou l'application réalisant cette journalisation. Cet avantacie est particulier sensible dans le cas d'une architecture globale où les données de journalisation sont transmises au fur et à mesure à une autre application rejouant le même déroulement, par exemple sur - 11 - une machine de secours pour réaliser un fonctionnement avec tolérance de panne et continuit. de service. Dans cette ':echniques de comptage, il peut être avantageux d'utiliser les instructions d'appel système comme points de synchronisation pour le comptage des ir structions. Il s'agit alors d'instrumenter les routines d'appels système Je façon à ce qu'elles incrémentent un compteur d'appels système. Le corn)tage des instructions par compteur matériel PMC peut alors travailler sur des valeurs qui restent peu élevées, ce qui améliore ses performances. Les figures 3 et 4 présentent une technique de rejeu dans un processeur de rejeu pProZ, d'une période journalisée SchJ. La figure 3 représentent les c erniers états TRi à TR4 d'une tâche rejouée TR, au sein du processeur. La figure 4 représente un diagramme de flux de la méthode utilisée pour mette en oeuvre un tel rejeu. Selon les modes de réalisation ou les paramètres d'utilisation, le rejeu peut aussi se faire se faire dans le même processeur que la journalisation, par exemple pour une gestion de fonctionnement de type traçage d'application, selon le même principe que pour un processeL r de rejeu différent. Lors d'un tel rejeu, par exemple en tant que période d'activation ordonnancée par l'ordonnanceur SCH possiblement modifier pour inclure un agent de rejeu RSCH, la tâche concernée TJ est restaurée dans le processeur visé al'ec son contexte, puis cette tâche est libérée (41) et son exécution est lance. Pour pouv)ir être restaurée et exécutée, dans un système informatique de rejeu différent de celui où a été faite la journalisation, tout ou partie des ressources accessibles à une tâche ou une application doit être virtualisée, c est à dire instanciées ou recrées, par exemple de façon virtuelle, de façon à apparaître à l'application rejouée de la même façon que lors de la journalisation. Sont concernées en général les identificateurs de tâches, threads (TIP) ou processus (PID), ainsi que la plupart des ressources accédÉ es par l'application et qui dépendent du système hôte. Cette virtualisatioi est réalisée au début de la tâche ou de l'application rejouée, et est modifiée au fur et à mesure du rejeu de façon à évoluer de - 12 - la même façon que lors de la journalisation, en fonction de données mémorisées lors de cette journalisation. De façon avantageuse, cette virtualisation est faite en mode kernel, ce qui permet en particulier d'éviter que ses opérations soient prises en compte dans IE comptage des instructions par le compteur de performances PMC. La documentation de la société Intel précise que l'erreur due à une interruption matérielle est limitée à une erreur relative de plus ou moins une instruction. Peur une période déterministe journalisée comprenant au plus une seule interruption matérielle, c'est à dire celle qui a provoqué sa clôture, la surveillance nécessite la prise en compte de deux valeur du compteur PMC: la valeur au début de la période de rejeu et la valeur au point de surveillar ce. L'erreur relative maximale est donc de plus ou moins deux instructions. Tout au Ion] de l'exécution de la tâche de rejeu TR au titre du rejeu de la tâche journalisée Ti, l'agent de rejeu RSCH surveille le nombre d'instructions retirées en lisant (RDPMC) le compteur PMC du processeur pProZ réalisant ce rejeu et en comparant cette lecture avec les données de journalisation IdJ, Ni, SGJ correspondant à cette tâche journalisée Ti. Cette surveillance est agencée de façon à interrompre l'exécution de la tâche TR de rejeu une fois atteinte l'instruction dont la valeur ordinale dans cette exécution de reje a vaut N3-2. Cette interruption est faite par exemple en programmant un débordement ( overflow ) du compteur PMC à la valeur voulue. Du fait de la quatrième caractéristique limitative citée plus haut, l'existence d'un temps de latence entre le débordement et l'interruption peut être compersée en programmant le débordement 41 (figue 4) avec une certaine manie, de façon à être certain que l'interruption se produise avant la valeur re:herchée de N3-2. Cette marge peut être déterminée par expérimentation e: peut être par exemple de l'ordre de 50 instructions. L'exécution initiale de la période SchR rejouée s'interromps alors à un nombre d'instruction entre N3-50 et N3-2. L'agent de rejeu RSCH positionne 42 alors un point d'arrêt d'exécution BK ( breakpoint ) au sein de l'exécutable de la tâche de rejeu TR, sur l'instruction de programme BKI 13 - correspondant à 13 valeur IPJ du pointeur d'instruction mémorisée dans la signature SGJ. L'exécution est alors relancée jusqu'à interruption 43 par ce oint d'arrêt BK, et ce en testant 44 le nombre d'instruction du compteur PMC jusqu'à ce que le nombre d'instructions rejoué soit supérieur ou égal au nombre d'instruction journalisé moins deux instructions, soit NR>=NJ-2. La position exacte de la fin réelle de la période journalisée SchJ se situe alors dans les quatre exécutions suivantes d'instruction unitaires InstrO, à Instr3, d? valeurs ordinales respectives NJ-1 à NJ+2, c'est à dire à une position relative comprise entre moins deux et plus deux par rapport à la position NJ de ln fin supposée de cette même période SchJ. Une phase Je confirmation 40 (figure 4) permet alors de déterminer cette position réelle, par comparaison entre la signature SGJ et une valeur SG1 à SG4 calcul ?e de la même façon à partir de l'état TRI à TR4 de la tâche de rejeu TR, après les exécutions unitaires d'instructions suivantes Instrl à Instr4. Au début de cette phase de confirmation, l'agent de rejeu vérifie 45 la valeur SGO d'L ne signature de rejeu SGR calculée d'après l'état de la tâche de rejeu T. immédiatement après l'interruption provoquée par la surveillance précélente. Selon l'invention, si les signatures SGJ et SGO ne correspondent pas, l'exécution de la 1 âche TR est alors relancée, et s'arrête 46 à la première nouvelle exécutior TR2 de cette instruction d'arrêt BKI. Il peut cependant subsister un doute quant à celle nouvelle position d'arrêt TR2, par exemple si la tâche journalisée TJ a réalisée une boucle très courte en exécutant plusieurs fois cette instruction d'arrêt BKI avant d'être suspendue. A chi que arrêt TR2, TR4 de l'exécution sur cette instruction d'arrêt BKI, rager t de rejeu vérifie 47 alors à nouveau la concordance des signatures SGJ et SGR et relance l'exécution jusqu'à obtenir la concordance. Lorsque les signatures correspondent SGJ=SG4, c'est que la dernière exécution Instr4 de l'instruction d'arrêt BKI correspond à la dernière opération journalisée dans la période journalisée SchJ. L'agent de rejeu clôture 48 alors la période de rejeu SchR. Par ailleurE, l'invention prévoit un mécanisme de sécurité, par exemple un test 9 interrompant le rejeu TR et renvoyant 401 une erreur -14 - de rejeu au delà d'un certain nombre d'exécutions unitaires d'instructions pour éviter une b)ucle infini en cas d'erreur, par exemple au bout de huit exécutions unitaires. Pour rejoue- une pluralité de périodes journalisées, par exemple lors d'un rejeu d'une application de rejeu APPR correspondant à l'application journalisée APPJ, l'agent de rejeu RSCH lit successivement les différentes lignes du journal JpProX, utilise chacune d'elle pour rejouer une période d'activation correspondant à la ligne concernée. Ainsi qu'iliu!;tré en figure 5, les différentes lignes de ce journal JpProX sont reçues TRAI\ S directement ou lues MEM en local par une tâche de lecture de journal TpProZ exécutée dans le processeur de rejeu pProZ. Toutes les I gnes de ce journal JpProX, correspondant chacune à une période journalisée, sont alors transmises à une file d'attente de rejeu QJpProZ de type F.IFO, dans l'ordre où elles ont été journalisées. A la sortie de cette file d'attente, l'agent de rejeu RSCH utilise chacune de ces lignes du journal pour 'aire rejouer la période qu'elle représente par la tâche rejouée TA', TB' el TC' correspondant à la tâche journalisée TA, TB et TC. Pour réalise- l'ordonnancement de ces périodes au sein du processeur de rejeu pProZ, l'agent de rejeu RSCH utilise le fonctionnement de l'ordonnanceur SC H tel qu'il existe dans le logiciel système standard sans changement sémantique. Cet aspect permet en particulier de garder la compatibilité avez les autres tâches TNM exécutées dans le même processeur. Pour obtenir le même ordonnancement que lors de la journalisation sans perturber le fonctionnement normal de l'ordonnanceur SCH, l'agent de rejeu RSCH se contente de bloquer 55b, 55c la libération de chaque tâche de rejeu TB', TC' tant que sont identifiant, TID ou PID, ne correspond pas à l'identifiant idA mémorisé dans la ligne qu'il doit faire rejouer. Ces techniques de journalisation et rejeu de périodes déterministes permettent d'opt miser les performances et les fonctionnalités d'une application de gestion de fonctionnement au sein d'un ou plusieurs ordinateurs mono.processeurs, telle que décrite dans les demandes citées plus haut. - 15 - Dans le cas d'une architecture parallèle, telle qu'un ordinateur multiprocesseurs ou un réseau comprenant plusieurs ordinateurs travaillant en parallèle, l'utilisation de ressources partagées accessibles par plusieurs tâches ajoute une cause de non déterminisme qui peut être à l'origine d'importantes pertes de performances dans le cadre de cette gestion de fonctionnement, voire d'impossibilités d'implémentation de certaines fonctionnalités importantes et utiles. Pour lever tout ou partie de ces causes de non déterminisme, l'invention propose un procédé permettant de gérer ou contrôler l'accès aux ressources partaçées, en particulier à accès direct, de façon à ce que chaque tâche pui;se 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. En figure 6 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écLtent en parallèle chacun une tâche, respectivement TA et TB, au sein d'ur même espace de mémoire de travail RAM, et sont coordonnées par Lin 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 pourri 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 , e.: accessibles depuis les différentes tâches TA et TB directement par leur adresse physique. La figure 6 Illustre une situation de l'art antérieur, où les tâches TA et TB sont exécutée; 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 (le façon indépendantes par le module gestionnaire de - 16 - 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 re!;sources qui ne sont accessibles qu'à partir de certaines instructions de tipe appel système, il est possible d'instrumenter les routines système! réalisant ces instructions, c'est à dire de modifier ces routines ou d'insvrer 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 par:iculier d'enregistrer leur comportement pour pouvoir le rejouer ultérieure lient à 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 potentiellem'nt depuis n'importe quelle instruction de programme, la plupart des systèmes d'exploitation et en particulier ceux de type Unix ou Linux, ne permet:ent 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 7 et 8, 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 ents 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, jour 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 modifica:ions qui ajoutent des fonctionnalités sans compromettre leur compatibilité ascendante. L'invention utilise pour cela certains mécanismes existant dans nombres de micr)-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, o Athlon de la société AMD. Ces processeurs, en particulier depuis le Pentiurn 2, intègrent au sein de leur gestionnaire de mémoire MMU ( Memory Management Unit ) un mécanisme de gestion de mémoire - 17 virtuelle. Ce méciinisme est utilisé pour décharger dans le disque dur certaines pages &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 8, le logiciel système comprend un gestionnaire de mémoire virtuelle VMM ( Virtual Memon Manager ), qui crée, pour chaque page de mémoire virtualisable, une:able 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 attribue- une table d'entrée de page PTEiA à PTEkA dans le processus de la tâ:he 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 fichier de swap du disque dur, par exemple un fichier avec extension .swp dans le 5 ystème Windows de la société Microsoft. Lors de chaque chargement ou &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 corresponc ent. 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 PrB, à 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)u MMUY comprend un mécanisme PFIntX ou PFIntY d'interruption sur 3rreur de page ( Page Fault Interrupt ) par lequel passe toute demande d'accès en provenance d'une instruction de programme InstrAou InstrB el 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 - 18 - 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 PFIritA autorise l'accès. Dans le cas contraire, ce mécanisme d'interruption PFIritA 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 à v s des applications. La figure 7 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 partagées selon l'invention. Pour gérer:es 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 une première tâche '-A 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âcr e TA doit être gérée, ou monitorée , en modifiant à 1 l'état d'un bit de sonnée habituellement inutilisé, ici appelé bit de gestion M mA. 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 PriAi à PrKA1 utilisé par le gestionnaire de mémoire virtuelle VMM comme décrit précédemment. Typiquement, cette structure de pages - 19 - 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 dl? l'exécution de l'application gérée APP, d'autres tâches peuvent être crée- 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éatior d'une nouvelle tâche TB, celle-ci comprend aussi un thread ThrBl et u l 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 rière TA. Au cours de l'exécution de l'application gérée APP, d'autres threads peuvent être créé; au sein d'une tâche TB qui fonctionnait initialement avec 20 sous la forme d'ur processus à un seul thread ThrBl. Au sein d'une tâche TB existante et monitorée, tout nouveau thread ThrB2 est créé p un appel système, telle qu'une instruction clone . Typiquement, un?. 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 p)uvant créer un nouveau thread, telle que l'appel système clone est n-odifiée, par exemple en lui intégrant une partie supplémentaire C;UP. 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 lectu -e 22 du jeu de tables existantes PTEiB1 et la création 23 d'un nouveau jE u de tables d'entrée de pages PTEiB2 à PTEkB2, correspondant au) 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 - 20 - 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éati bn 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 à PrEkBl, 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 M:>UP. La figure 8 illustre le fonctionnement de la gestion d'accès utilisant cette structure a)pliqué à un exemple comprenant deux tâches monothreads TA et TB exécutées en parallèle dans deux processeurs pProX et pProY. Il est à noi er 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 d? 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 muftithreads. Dans le mDde 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'aui res 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 si inilaire 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 - 21 - varier suivant le l:ype ou la version du logiciel système. Dans le cas d'un système de typ e Linux, ces modifications comprennent en général l'instrumentation des routines de type clone et map tel que décrit précédemment, a nsi 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 hardler ), et le chargeur de page PL. Les fonctionnalités systèmes à modiier pour réaliser le type de contrôle d'accès décrit ici peuvent avantageusement constituer exclusivement des extensions par rapport aux fondionnalités du système standard, c'est à dire sans suppression de fonctionnalité ou du moins sans compromettre la compatibilité asceidante 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 Iz 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 ê:re compatible avec elle. Le chargeur de page PL peut par exemple être inst-umenté ou modifié de façon à ce que le chargement en mémoire physique RAM d'une page virtuelle ShMPi ne soit pas répercuté dans le bit de pré1;ence 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'ordornanceur 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:ables PTE correspondant à toutes les pages partagées concernées par ça 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 c"interruption PHIntX du processeur pProX suspend - 22 l'exécution de cetl:e demande d'accès et appelle le gestionnaire d'erreur de page PFH du logic et système, en lui transmettant l'identification de la page et de la tâche cons:ernées. Lors du trai:ement 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 structura de la mémoire KMStr ( Kernel Memory Structure ) à l'intérieur du gesti bnnaire de mémoire virtuelle VMM du logiciel système. Typiquemer t, 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 page est actuellement accordé (bit à 1) ou non (bit à 0) à une tâche. Lorsque le gestionnaire d'erreur page PFH traite l'erreur transmise par le processeur JProX, il consulte 34 le bit d'accès KSi correspondant à la page concernée ShMPi. Si ce bit d'accès n'indique pas d'accès en cours, il modifie 34 ce bit d'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 (bit passant à 1) pour mémoriser le fait que cette tâche TA a maintenant un accès exclusif à la page concernée ShMPPi. Il est à noter que ces opérations de test et modification du bit d'accès KSi de la structure noyau de mémoire KMStr constituent une opération 34 qui est implémen:é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 mtilti-processeurs. Une fois que le gestionnaire d'erreur page PFInt a attribué l'exclusivité sur la page demandée ShMPi, il relance l'exécution de l'instruction InstrA de façon à ce qu'elle accède 36 effectivement au contenu de cette page. - 23 - Si une instruction InstrB d'une autre tâche TB monitorée quelle qu'elle soit, exécuté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 PFIntY de ce processeur va lui aussi consulter le bit de présence PriB de cette page pour la tâche TB demandeuse. Puisque la tâche TB est une tâche monitorée, le bit de présence PriB consulté est en position d'absence (valeur à 0). Le mécanisme d'interruption PFIntY va donc suspendre l'instruction InstrB demandeuse et transmettre 38 une erreur au gestionnaire d'erreur de page PFH. Cette fois, ce gestionnaire d'erreur page PFH constate que le bit d'accès KSi de cette page est à 1, indiquant qu'une exclusivité a déjà été accordée sur cette page ShMPi à une autre tâche. Le gestionnaire d'erreur PFH va alors déclencher 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 de changement de contexte du logiciel système. Lors de sa prochaine période d'activation, cette tâche TB reprendra alors son exécution exactement au point où elle s'était interrompue, et pourra tenter à nouveau d'accéder à cette même page ShMPi. Dans le cas où la tâche demandeuse est un thread ThrB2 (figure 7) appartenant à un processus multi-threads, l'existence d'un jeu de tables d'entrée de pages 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 exclusivité. A l'issue SCHAS de la période SchA d'activation de chaque tâche, l'ordonnanceur suspend l'exécution de cette tâche et sauvegarde son contexte d'exécution. Lors de cette suspension SCHAS ou lors d'une suspension 39 sur une demande de page déjà allouée, l'invention prévoit aussi une phase de libération de toutes les pages de mémoires partagées pour lesquelles cette tâche a reçu un accè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 parcourt 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, - 24 - en consultant l'état des différents bits de présence PriA à PrkA. A partir de cette information 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'autres variantes non représentées, il est aussi possible de découpler la notion de gestion ou monitorage en plusieurs types de gestion, par exemple en pré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 accès exclusif vis à vis de certaines catégories de tâches. De même, une tâche peut ne se voir exclue que par certaines catégories de tâches. Ainsi, en suspendant 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 toute modification d'une même zone de mémoire partagée par deux tâches 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. A partir d'un état initial déterminé, pour cette zone mémoire, au début de chaque période d'activation d'une tâche qui y accède, l'évolution de son contenu ne dépend donc que des actions de cette tâche au cours de cette période d'activation. Pour une séquence déterminée d'instructions exécutées par cette tâche, par exemple une période d'activation ordonnancée, et en partant d'un état initial connu, il est ainsi possible d'obtenir un déroulement 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'allocation 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'une même ressource partagée entre plusieurs tâches cherchant à y accéder concurremment. En combinant ces techniques de contrôle d'accès (figures 7 à 8) avec les techniques de journalisation des périodes déterministes décrites plus haut (figures 1 à 5) ainsi des techniques checkpointing et de journalisation 25 - et rejeu décrites dans les demandes citées plus haut, l'invention propose d'implémenter aussi dans des systèmes à architecture parallèle les différents types de gestion de fonctionnement décrits précédemment. La figure 9 illustre ainsi, selon l'invention, une journalisation d'une application multitâche APPJ exécutée dans un système multiprocesseurs MP1 et son rejeu au fur et à mesure dans un système monoprocesseur UP2. Auprès de l'application journalisée APPJ, l'agent de journalisation JSCH journalise, pour chaque processeur pProX ou pProY, la succession de toutes les périodes d'activation des différentes tâches monitorées TA, TB et TC. Ainsi que décrit plus haut, il les transmet séparément à autant de files d'attente, respectivement QJpProX et QJpProY. Il est à noter que si une tâche est exécutée une fois dans un processeur et une fois un autre processeur, des périodes d'activation de cette seront présentes dans les deux files d'attente. Auprès des ressources partagées ShMPi à ShMPk accédées par l'application journalisée APPJ, un agent de journalisation JVMM enregistre, pour chacune de ces ressources, des données de journalisation représentant lasuccession des accès continus alloués sur cette ressource. Ces données de journalisation des accès continus sont générées au sein du gestionnaire de mémoire virtuelle VMM, par le gestionnaire d'erreur de page PFH, au fur et à mesure des accès continus qu'il alloue aux différentes tâches. Chaque enregistrement de ces données de journalisation d'accès comprend en particulier: - un identifiant univoque de la ressource partagée concernée, par exemple une adresse pour une zone de mémoire partagée; - un identifiant (PID ou TIP) de la tâche qui a obtenu cet accès; - la durée de cet accès exclusif, par exemple obtenue selon la technique de comptage décrite ici; - les informations complémentant permettant de compenser 30 l'imprécision de ce comptage, par exemple un signature comme décrit ici; ainsi que certaines informations complémentaires utiles, par exemple, pour la virtualisation des ressources système et des différents évènements externes ou d'entrée/sortie. - 26 - Ces données de journalisation sont transmises à une file d'attente de journalisation QJShMPi de type FIFO. Selon les modes de réalisation, il est bien sûr possible de mémoriser le contenu de ces files d'attente dans un ou plusieurs fichiers journal pour un usage ultérieur. A partir de ces files d'attentes, les différentes données de journalisation sont transmises au système de rejeu UP2, par des moyens de communication tel qu'un réseau de communication informatique. Les données de chaque file d'attente sont reçues par une file d'attente de rejeu qui correspond à la file d'attente émettrice. En sortie de ces données de journalisation des différents processeurs journalisés pProX et pProY sont combinées entre elles, en fonction des données de journalisation d'accès, de façon à restituer la sérialisation combinée des périodes d'activation journalisées et des accès continus (exclusifs) alloués. Une fois cette sérialisation, ou ordonnancement, de rejeu est définie au sein du système de rejeu, son exécution est lancée dans le processeur de rejeu. Il est à noter que le nombre de processeurs au rejeu peut ne pas avoir d'importance en dehors des performances au rejeu, du moment que les tâches leurs sont réparties d'une façon qui ne brise pas l'ordonnancement de cette sérialisation de rejeu. Il est à noter que les différents mécanismes décrits ici utilisent la partie logicielle de façon bien dissociée de la partie matérielle. On obtient ainsi une bonne indépendance par rapport au matériel, ce qui, en 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 mieux le parallélisme des différents éléments de calcul, qu'il s'agisse de processeurs ou d'ordinateurs. De plus, du fait de l'implémentation le plus souvent purement logicielle de l'invention, il est possible d'utiliser du matériel standard avec les avantages que cela comporte. L'invention permet en particulier d'étendre aux environnements parallèles des techniques de gestion de fonctionnement développées pour -27 - des applications mufti-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 parallèles dans des réseaux ou clusters, dans lesquels cette gestion de fonctionnement est implémentée au sein d'une application de type middleware, par exemple pour gérer des applications distribuées ou des applications à déploiement variable fournissant un service à la demande ( on demand ) Bien sûr, l'invention n'est pas limitée aux exemples qui viennent d'être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l'invention. - 28 - REVENDICATIONS 1. Procédé de gestion de fonctionnement d'au moins deux tâches applicatives (TA, TB), mis en oeuvre au sein d'un logiciel système gérant par activation séquentielle l'exécution desdites tâches (TA, TB) dans un système informatique d'une structure parallèle, dit de journalisation, comprenant une pluralité de moyens de calcul aptes à exécuter plusieurs tâches simultanément dans au moins deux unités de calcul (pProX, pProY), ces deux tâches applicatives (TA, TB) accédant à au moins une ressource partagée (ShMPi), le procédé comprenant: - une journalisation d'une première succession de périodes d'activation de l'une ou l'autre de ces tâches dans une première unité de calcul (pProX) ; et - une journalisation d'une deuxième succession de périodes d'activation de l'une ou l'autre de ces tâches dans une deuxième unité de calcul (pProY) et une journalisation d'une succession d'attributions à l'une ou l'autre de ces tâches dite accédante, en réponse à une demande d'accès (InstrA) à ladite ressource cible, d'un accès dit continu à ladite ressource cible, c'est à dire de façon à exclure tout accès à ladite ressource cible (ShMPi) par une autre de ces tâches pendant la totalité de la période d'activation (SchA) de la tâche accédante suivant immédiatement ladite demande d'accès; le procédé comprenant en outre une combinaison, en une structure ordonnée dite sérialisation de rejeu, des données de journalisation représentant les successions de périodes d'activation dans chacune des unités de calcul avec les données de journalisation représentant la succession des accès continus attribués, de façon à conserver l'ordre de succession des périodes d'activation au sein de chaque tâche et vis à vis de ladite ressource partagée. 2. Procédé selon la revendication 1, caractérisé en ce que les données de la sérialisation de rejeu sont utilisées dans un système informatique de rejeu pour rejouer le déroulement journalisé des tâches journalisées. - 29 - 3. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce qu'il comprend une virtualisation, au sein du système informatique de rejeu, de tout ou partie des ressources logicielles accessibles aux tâches journalisées lors de la journalisation. 4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce qu'il est mis en oeuvre au sein d'au moins un noeud d'un réseau d'ordinateurs. 5. Système informatique mettant en oeuvre le procédé selon l'une des revendications 1 à 4.