FR2829848A1

FR2829848A1 - Procede de gestion d'acces a des ressources partagees dans un systeme embarque et systeme embarque pour la mise en oeuvre d'un tel procede

Info

Publication number: FR2829848A1
Application number: FR0112144A
Authority: FR
Inventors: Benoit Bole; Nicolas Fougeroux; Patrice Hameau
Original assignee: CP8
Current assignee: CP8
Priority date: 2001-09-20
Filing date: 2001-09-20
Publication date: 2003-03-21

Abstract

L'invention concerne un procédé de gestion d'accès à une ressource partagée (Ry) par un processus (Py) dans un système embarqué multiprocessus, notamment une carte à puce (1). Deux processus (Py) ou plus peuvent poser une requête d'accès à une ressource partagée (Ry) en même temps. Selon l'invention, on met à la disposition de chaque ressource partagée (Ry) un compteur signé (5), initialisé à " 1 ", décrémenté d'une unité lorsqu'un processus (Py) pose une requête et incrémenté d'une unité lorsque la ressource (Ry) est libérée. Une pile (6) enregistre les adresses successives de processus demandeurs (Py), lorsque la ressource est occupée (Ry). On prévoit une routine de réservation de ressource (7) et une routine de libération de ressource (8) coopérant avec le compteur (5) et la pile (6) de manière à mettre en attente les processus demandeurs (Py) et à les réactiver automatiquement.L'invention concerne également un système embarqué, notamment une carte à puce pour la mise en oeuvre du procédé.

Description

PROCEDE DE GESTION D'ACCES A DES RESSOURCES PARTAGEES DANS UN
SYSTEME EMBARQUE ET SYSTEME EMBARQUE POUR LA MISE EN OEUVRE
D'UN TEL PROCEDE
L'invention concerne un procédé de gestion d'accès à des ressources partagées dans un système embarqué à puce électronique.

L'invention concerne encore plus particulièrement un système embarqué du type dit "multi-processus" ou encore "multitâches", ayant à gérer l'accès à des ressources partagées. Pour simplifier, le terme "multi-processus" sera seul utilisé dans ce qui suit.

L'invention concerne encore un système embarqué pour la mise en oeuvre d'un tel procédé.

L'invention s'applique plus particulièrement à une carte à puce.

Dans le cadre de l'invention, le terme"système embarqué"doit être compris dans son sens le plus général. Il concerne notamment toutes sortes de terminaux légers munis d'une puce électronique, et plus particulièrement les cartes à puce proprement dites. La puce électronique est munie elle-même de moyens d'enregistrement et de traitement de données numériques, par exemple un microprocesseur pour ces derniers moyens. Dans tous les cas, la puissance de calcul et la capacité de stockages résidents dans un système embarqué sont relativement limitées, ce par comparaison à un système hôte du système embarqué, par exemple un micro-ordinateur. La comparaison est encore plus défavorable si on considère des systèmes plus puissants : serveurs de réseaux locaux, systèmes dits "mini"ou grands systèmes dits"mainframe".

Toujours dans le cadre de l'invention, le terme"ressources"désigne des ressources informatiques présentes dans le système embarqué, indistinctement de type logiciel ou matériel. De façon plus précise, il s'agira ci-après, de ressources partagées, c'est-à-dire pouvant être mises à la disposition d'au moins deux processus concurrents.

Pour fixer les idées, et sans que cela limite en quoi que ce soit sa portée, on se placera ci-après dans le cas de l'application préférée de l'invention, à savoir les applications à base de cartes à puce, sauf mention contraire.

On va supposer qu'il existe en outre un système de contrôle d'accès aux ressources partagées de la carte à puce permettant d'empêcher l'accès d'un processus à une ressource partagée, temporairement ou de façon permanente, suivant des conditions données. L'accès à une ressource partagée peut être par exemple refusée si ladite ressource partagée est déjà en cours d'utilisation par un autre processus ou encore si le processus demandant l'accès à ladite ressource n'est pas muni de droits d'accès suffisants, notamment pour des raisons liées à la sécurité (confidentialité par exemple).

Dans une demande de brevet français intitulée "Procédé de contrôle d'accès à des ressources partagées dans un système embarqué et système embarqué pour la mise en oeuvre d'un tel procédé", déposée ce jour, la Demanderesse a proposé un tel système de contrôle.

Selon cette demande de brevet, deux processus ou plus peuvent poser une requête d'accès à une ressource partagée en même temps. Selon un mode de réalisation préféré, on met à la disposition de chaque ressource partagée une position de mémoire stockant un bit dit de verrou, mis à l'état "0" dans une phase initiale. Chaque ressource partagée est associée à une première primitive dite de réservation de ressource qui teste l'état du bit, et lorsqu'il est à"0", le positionne à "1"et accorde l'accès au processus demandeur. Dans le cas contraire, elle interdit l'accès. Chaque ressource partagée est aussi associée à une seconde primitive dite de libération de ressource qui remet le bit à "0" lors de la libération de cette ressource. Selon une caractéristique du procédé, les deux primitives ne sont pas interruptibles.

En se plaçant plus précisément dans le cadre de l'invention, on va maintenant considérer le cas d'un processus donné, ayant droit d'accéder à une ressource partagée particulière, mais qui ne peut y accéder car celle-ci est en cours d'utilisation par un autre processus. Le processus demandeur en question doit donc, d'une façon ou d'une autre, attendre, puis tenter ultérieurement d'accéder de nouveau à la ressource partagée précitée. Ceci implique que le processus demandeur ait les moyens de s'arrêter, de se souvenir qu'il a une nouvelle demande d'accès à faire, mais aussi de "récupérer la main" pour effectuer cette

demande, sans aucune garantie, d'ailleurs, qu'elle aboutisse. En cas de nouvel échec, il est alors nécessaire de réitérer le cycle précédent.

En résumé, les principales contraintes qui se posent sont les suivantes : - conservation d'une demande d'accès posée par un processus demandeur donné quand une ressource partagée n'est pas disponible ; - rappel automatique du processus demandeur en attente quand la ressource partagée se libère ; et, de façon préférentielle, la possibilité d'un accès simultané de n processus (avec n quelconque plus grand que 2, dépendant seulement de la quantité de mémoire disponible) à une ressource partagée.

Il doit être entendu que le terme "simultané" signifie l'accès à cette ressource partagée pendant un intervalle de temps où elle est occupée.

Sauf à modifier profondément les applications logicielles lançant les processus précités, ce qui les rendrait plus complexes, ces dernières ne satisfont pas habituellement aux exigences rappelées ci-dessus. En outre, de telles modifications rendraient les applications logicielles plus gourmandes en ressources informatiques, tant pour le traitement de données que pour le stockage. Or, comme il a été rappelé, les ressources informatiques d'une carte à puce (et de façon plus générale d'un système embarqué) sont limitées par nature.

L'invention vise à pallier les inconvénients des dispositifs et systèmes de l'art connu, et dont certains viennent d'être rappelés, tout en satisfaisant aux besoins qui se font sentir et aux spécificités présentées par les systèmes embarqués.

L'invention se fixe donc pour but, dans un système embarqué, un procédé de gestion d'accès simultané à une ressource partagée permettant de conserver une demande d'accès à cette ressource partagée et d'y répondre favorablement et automatiquement dès que la ressource partagée se libère.

Dans un mode de réalisation préféré, le procédé selon l'invention permet de surcroît la gestion de l'accès simultané à une ressource partagée par plus de deux processus.

On suppose qu'il soit prévu à l'avance que toute application manipulant une ressource partagée doit le faire dans le cadre d'une routine indépendante du reste du processus.

Pour ce faire, on prévoit pour chaque ressource partagée des premiers moyens de stockage pour la génération d'une donnée numérique pouvant prendre une série d'états prédéterminés. Dans une phase initiale, lors de la création d'une ressource partagée donnée, la donnée numérique précitée est initialisée à un état prédéterminé signifiant que la ressource partagée n'est pas utilisée. De façon préférentielle, les premiers moyens de stockage sont constitués par un compteur signé. La donnée numérique précitée est alors un nombre binaire qui peut être incrémenté et/ou décrémenté, la valeur initiale pouvant être égale à"1", par exemple.

On prévoit également pour chaque ressource partagée des seconds moyens de stockage de données permettant de stocker une adresse de reprise des processus lancés par les applications précitées, ces deuxièmes moyens de stockage constituant une"file d'attente".

En outre, on associe à chaque ressource partagée une routine logicielle que l'on appellera"de réservation de ressource"et une routine logicielle que l'on appellera"de libération de ressource".

Lors d'une première étape d'une phase ultérieure, que l'on peut qualifier d'opérationnelle, c'est-à-dire lorsqu'une requête d'accès à une ressource partagée est posée par un processus demandeur, l'état de la donnée numérique est modifié, par exemple le nombre binaire est décrémenté d'une unité si l'on utilise un compteur signé, ce qui indiquera que la ressource partagée est occupée en cas de requête posée par un deuxième processus demandeur.

Dans l'hypothèse où la ressource partagée est occupée, l'adresse de reprise du deuxième processus demandeur est stockée dans la file d'attente précitée. L'adresse de reprise, dans la forme de réalisation décrite plus loin, correspond à l'adresse qui suit l'adresse de l'appel à la routine de réservation dans le cours du programme du deuxième processus demandeur (appelant).

Exemple de programme du processus demandeur (appelant) :
1-... [ligne de code]
2-...

3-R (x) [ligne de code correspondant à l'appel à la routine de réservation] aligne de code suivant celle de l'appel à la routine de réservation et appelée adresse de reprise]
Par contre, lors d'une toute première requête d'accès, le processus demandeur se voit attribuer directement la ressource partagée, puisqu'elle est disponible.

Lors d'une deuxième étape, lorsque la ressource partagée n'est plus utilisée, c'est-à-dire libérée par le premier processus, elle redevient disponible. La valeur de la donnée numérique est de nouveau modifiée (remise à l'état initial), pour signaler cet état de disponibilité. Le deuxième processus demandeur, toujours en attente, est "réveillé", la ressource partagée lui est attribuée et son exécution peut se poursuivre.

Les première et deuxième étapes sont réalisées sous la commande des routines respectives"de réservation de ressource" et "de libération de ressource" précitées, coopérant avec les premiers et deuxièmes moyens de stockage.

Dans une variante de réalisation préférée, le procédé selon l'invention peut gérer l'accès à une ressource partagée par plus de deux processus en même temps. Dans cette hypothèse, l'état de la donnée numérique est modifié à chaque requête d'accès effectuée par un nouveau processus. Elle est, par exemple décrémentée d'une unité, s'il s'agit d'un nombre binaire. Le mécanisme inverse se produit, à chaque fois que la ressource partagée est libérée par un processus utilisateur, ce jusqu'au retour à l'état initial. La mise en mémoire des adresses de reprise successives des processus en attente s'effectue de façon similaire à ce qui vient d'être décrit pour un processus unique. De même, chaque fois qu'un processus utilisateur libère la ressource partagée, une de ces adresses de reprise est rappelée. L'ordre des rappels d'adresses peut s'effectuer selon des mécanismes divers : premier entré-premier sortie ou"FIFO"selon la terminologie anglo-saxonne, en tenant compte de priorités attribuées aux processus, etc.

L'invention a donc pour objet principal un procédé de gestion d'accès à des ressources partagées dans un système embarqué comportant au moins des moyens de mémoire et des moyens de calcul, ledit système embarqué étant multiprocessus et comportant des ressources partagées pouvant être mises à la disposition d'au moins deux processus posant des requêtes d'accès à ces ressources partagées, caractérisé en ce qu'il comprend, lorsqu'au moins un desdits processus, dits demandeur, pose une requête d'accès à l'une desdites ressources partagées, une étape de réservation de ressource consistant à : modifier, pour prendre en compte la requête d'accès du processus, des moyens permettant d'indiquer la disponibilité de la ressource partagée et de tenir compte à cet effet du nombre de processus ayant émis une requête d'accès à la ressource concernée ; * tester lesdits moyens et - si les moyens indique que la ressource est disponible, donner à l'accès à la ressource ; - si les moyens indique que la ressource est indisponible, mettre en attente le processus concerné par mise en mémoire dans des moyens de stockage de données nécessaires à la ré-activation dudit processus ; les deux opérations de modification et de test pouvant être réalisées dans cet ordre ou dans l'ordre inverse.

Le procédé selon l'invention comprend, lorsqu'un processus libère la ressource, une étape de libération de ressource consistant à : w modifier les moyens pour prendre en compte la libération de la ressource par le processus ; tester les moyens pour vérifier si au moins un autre processus a été mis en attente et dans la positive ré-activer un desdits processus mis en attente, ledit processus étant choisi selon un mécanisme donné, et lui donner accès à la ressource ; les deux opérations de modification et de test pouvant être réalisées dans cet ordre ou dans l'ordre inverse.

L'invention a encore pour objet un système embarqué pour la mise en oeuvre de ce procédé.

L'invention va maintenant être décrite de façon plus détaillée en se référant aux dessins annexés, parmi lesquels : - la figure 1 illustre schématiquement l'architecture d'une carte à puce ;
La figure 2 illustre schématiquement le mécanisme d'un contrôle d'accès à une ressource partagée ; - la figure 3 est un organigramme montrant les principales étapes d'un accès à une ressource partagée par un processus ; et - les figures 4 et 5 sont des organigrammes montrant les étapes du procédé de gestion d'accès à des ressources partagées selon un mode de réalisation préféré de l'invention.

On va maintenant décrire de façon plus détaillée un exemple de réalisation d'un procédé de gestion d'accès à une ressource partagée selon l'invention par référence aux figures 1 à 5. Comme il a été indiqué, à titre d'exemple non limitatif et pour fixer les idées, on se placera dans le cas du domaine d'applications préférées de l'invention, à savoir les applications à base de cartes à puce.

La figure 1 illustre très schématiquement l'architecture d'une carte à puce 1. Celle-ci comprend au moins les éléments suivants : un microprocesseur ou équivalent (microcontrôleur) 10, constituant des moyens de traitement de données numériques, des moyens de stockage de données et de programmes, comprenant notamment une zone de mémoire vive ou"RAM" ("Random Access Memory") 11 et une zone de mémoire fixe ou semi-fixe 12, par exemple de type"ROM" ("Read Only Memory") ou "PROM" ("Programmable Read Only Memory"), ainsi que des circuits d'entrée-sortie "1/0" ("Input/Output) 13 communiquant avec le milieu extérieur, c'est- à-dire avec le terminal hôte 2 de la carte à puce 1 (par exemple un microordinateur). Ces différents éléments communiquent entre eux avec un ou plusieurs bus, représenté (s) sous une référence unique B. Généralement, les applications logicielles, microprogrammes, appliquettes, ou"applets"selon la terminologie anglo-saxonne, que l'on appellera de façon générique programmes, sont stockés dans la mémoire fixe ou semi-fixe 12, mais peuvent être également téléchargés

directement dans la mémoire vive 11 en provenance du monde extérieur, notamment du terminal 2, via les circuits d'entrée-sortie 13.

Pour qu'une application puisse être exécutée, il est nécessaire de charger tout ou partie de son code en mémoire vive 11. Un ou plusieurs processus peut (peuvent) donc être lancé (s), correspondant (s) à une ou plusieurs applications.

Le bon déroulement de ces processus, sous la commande du microprocesseur 10 et d'un système d'exploitation de la carte à puce 1, ou"OS" ("Operating System" selon la terminologie anglo-saxonne"), exige que des ressources informatiques, tant matérielles que logicielles soient mises à leurs dispositions, notamment des ressources partagées si la carte à puce 1 est du type multi-processus comme il a été précédemment indiqué.

Lorsqu'un processus demandeur donné pose une requête pour avoir accès à une ressource partagée particulière, il est nécessaire de contrôler si le processus peut avoir effectivement accès à celle-ci.

En premier lieu, notamment pour des raisons liées à la sécurité, un processus peut se voir interdire l'accès à une ressource partagée, même si elle est disponible, car il n'est pas possesseur de droits suffisants ou, a fortiori, ne possède aucun droit d'accès à la ressource partagée précitée.

Lorsque le système embarqué, en l'occurrence la carte à puce 1, est du type multi-processus, par définition plusieurs processus peuvent s'exécuter en simultanéité. On suppose, dans un premier temps, qu'une ressource peut être partagée entre deux processus concurrents. Il est alors nécessaire de contrôler aussi, lorsqu'un des deux processus pose sa requête d'accès, si la ressource partagée en question n'est pas déjà en cours d'utilisation par l'autre processus.

La demande de brevet rappelée dans le préambule de la présente demande permet de répondre à ce premier besoin, à savoir de contrôler la possibilité d'accès à une ressource partagée.

La figure 2 illustre schématiquement l'architecture d'un système de contrôle d'accès. Un processus Px pose une requête pour utiliser une ressource partagée Ry. Dans ce premier exemple, x peut prendre les valeurs arbitraires 1 ou 2, puisqu'il existe deux processus distincts pouvant avoir accès à la ressource partagée Ry. La

valeur y est comprise entre 1 et m, nombre total de ressources partagées. Cette requête est filtrée par un module de contrôle d'accès 3, qui peut être de type logiciel ou matériel.

Les phases et étapes de ce contrôle d'accès sont résumées sur l'organigramme de la figure 3.

A l'étape 400, une requête d'accès à une ressource partagée Ry est posée par le processus Px. Le premier test, étape 401, consiste à examiner les droits d'accès du processus demandeur Px à la ressource partagée en question Ry. Ceci peut être exécuté de façon connue en soi, par comparaison de droits attachés au processus Px avec ceux nécessaires pour accéder à la ressource partagée Ry. Si l'accès est refusé, la requête est rejetée et le cycle se termine à ce point (branche "NON"). Les données nécessaires à la comparaison sont stockées préférentiellement dans une zone protégée de la mémoire fixe 12 (figure 1).

Également de façon classique en soi, l'application et/ou le système d'exploitation ("OS") est/sont informé (es) de ce fait par la transmission de données appropriées, en vue d'actions ultérieures qui sortent du cadre strict de l'invention (par exemple l'arrêt du processus demandeur Px).

Si le résultat du test de l'étape 401 est positif (branche"OUI"), un deuxième test est réalisé à l'étape 402. Ce test consiste à déterminer si la ressource partagée Ry n'est pas déjà utilisée par un autre processus. Si le résultat du test est négatif (branche"NON"), c'est-à-dire si la ressource partagée Ry est libre, le processus Px a accès à la ressource partagée Ry. Sinon (branche"OUI"), le processus demandeur doit attendre : étape 403. Lorsque la ressource Ry est disponible, un des processus mis en attente à l'étape 403 est réveillé. Le processus à réveiller est choisi selon un mécanisme donné de rappel : étape 404. Ce cycle peut se réitérer plusieurs fois.

L'invention est plus particulièrement concernée par les étapes 402 à 404.

Comme il a été rappelé, on constate que le processus Px, lorsque la ressource partagée Ry est déjà utilisée, doit être mis en attente. En outre, cette mise à disposition de la ressource partagée libérée doit être réalisée de façon automatique.

Selon une caractéristique du procédé de l'invention, on prévoit à l'avance que toute application manipulant une ressource partagée doive le faire dans le cadre d'une routine indépendante du reste des processus la composant.

Selon une deuxième caractéristique, dans un mode de réalisation préféré de l'invention, comme illustré par la figure 4, on met à la disposition de chaque ressource partagée Ry un compteur 5. Dans une forme de réalisation préférée, le compteur 5 est signé. Dans une phase initiale ou préliminaire, par exemple lorsque la ressource partagée Ry est créée, le compteur 5 est initialisé à une valeur arbitraire prédéterminée, par exemple à la valeur s = 1. Cette valeur signifie que la routine Ry n'est pas actuellement utilisée.

La capacité du compteur 5 (longueur du mot binaire stocké par celui-ci) dépend du nombre de processus pouvant avoir un accès simultané à une ressource partagée Ry occupée, comme il va l'être montré ci-après.

En effet, lorsque la ressource partagée Ry est mise à la disposition d'un processus, par exemple le processus Px (avec x arbitraire, compris entre 1 et n, n étant le nombre maximum de processus pouvant être géré) ayant posé une requête d'accès (et, le cas échéant, sous réserve que ce processus Px ait des droits suffisants pour y avoir accès : voir figure 3, étape 401), la valeur s du nombre binaire stockée par le compteur 5 est modifiée, par exemple décrémentée d'une unité, et passe donc à s = 0. Ce mécanisme est répété pour chaque processus demandeur supplémentaire tant que la ressource partagée Ry n'est pas libre.

Naturellement, le compteur 5 pourrait tout aussi bien être incrémenté et la valeur initiale de"1"est tout à fait arbitraire. N'importe quelle valeur convenue à l'avance peut convenir.

De façon plus générale, le compteur 5 peut être remplacé par une zone de mémoire stockant une donnée numérique pouvant prendre une suite d'états prédéterminés, dont l'un représente l'état de disponibilité d'une ressource partagée qui lui est associé, et dont l'ensemble des autres états sont en relation biunivoque avec le nombre de processus en attente.

Selon une troisième caractéristique du procédé selon l'invention, une ressource partagée, par exemple la ressource partagée Ry, est associée à une

première routine 7, dite de"réservation de ressource" (voir figure 4). C'est cette dernière qui commande la décrémentation (dans l'exemple décrit) du compteur 5 et qui en teste le contenu.

Dans ces conditions (figure 4), si un processus demandeur quelconque, par exemple le processus Px, pose une requête d'accès à la ressource partagée Ry, la valeur s W 0 (le compteur est décrémenté par le processus demandeur dans l'étape précédent le test dudit compteur : s-1=0 pour une ressource libre) signale que la ressource partagée Ry n'est pas libre. Dans ce cas, le processus Px doit être mis en attente. Ce test est réalisé à l'étape 501.

Selon une quatrième caractéristique du procédé selon l'invention, on met à la disposition de chaque ressource partagée, par exemple la ressource partagée Ry, une zone de mémoire 6, avantageusement constituée par une pile ou "stack"selon la terminologie anglo-saxonne, par exemple du type dit"premier entré- premier sorti"ou"FIFO", des registres, ou tout autre organe analogue. Cette zone peut être avantageusement comprise dans la mémoire vive 11 (figure 1) ou être constituée par des registres indépendants.

Lorsqu'un processus demandeur Px pose une requête pour accéder à la ressource partagée Ry et que cette dernière n'est pas libre, l'adresse de reprise du processus Px (et plus précisément, comme vu précédemment, l'adresse suivant celle de l'appel à la routine de réservation) est mise en mémoire dans la pile 6. Les données afférentes au processus lui-même sont conservées dans une zone appropriée de mémoire vive (figure 1 : 11) ou dans des registres, par exemple dans la zone de mémoire vive qu'ils occupent à l'instant de la requête d'accès à la ressource partagée Ry.

Dans le mode de réalisation préféré du procédé selon l'invention, qui permet la gestion d'un nombre de requêtes d'accès plus grand que deux (en même temps), à chaque fois qu'un nouveau processus demandeur, par exemple Pm (avec m arbitraire, compris entre 1 et n), pose une requête d'accès à la ressource partagée Ry, le compteur 5 est décrémenté d'une unité.

Selon une cinquième caractéristique du procédé selon l'invention, comme illustré par la figure 5, une ressource partagée, par exemple la ressource partagée

Ry, est associée à une seconde routine 8, dite de'libération de ressource" (voir figure 5). Lorsque le processus initial, en l'occurrence le processus Pq, relâche la ressource partagée Ry, la routine de libération agit sur le compteur 5 et l'incrémente d'une unité. Elle teste également le contenu du compteur 5.

Deux cas peuvent se présenter comme illustré par le test à l'étape 501 sur la figure 5 :
Si s = 1 (ou toute autre valeur initiale du compteur 5), cela signifie qu'aucun processus n'est en attente. La ressource partagée Ry peut être mise à la disposition immédiatement de tout processus demandeur futur.

Si s : 1= 1, cela signifie qu'au moins un processus est en attente et que l'adresse de reprise dudit processus est stockée dans la pile 6. La routine de libération 8 va chercher ladite adresse de reprise dans la pile 6 et "réveille" un processus en attente, dont l'exécution reprend au point correspondant. Cette adresse que la routine de libération 8 va chercher dans la pile 6 est bien entendu retirée de la pile 6.

Si plusieurs processus sont mis en attente, le processus "réveillé" peut être le dernier arrivé, si le mécanisme retenu est du type"premier arrivé-premier servi" ("FIFO"). Mais, dans des variantes de réalisation supplémentaires, d'autres mécanismes peuvent être retenus, et notamment des mécanismes tenant compte de priorités de traitement, fixes ou dynamiques, associées aux divers processus mis en attente. Si on retient ce dernier type de mécanisme, on "réveille" le processus ayant le niveau de priorité le plus important. Ceci peut être réalisé, de façon bien connue en soi, par consultation d'un fichier ou d'une base de données dite de sécurité, avantageusement enregistrée dans une zone sécurisée de la mémoire fixe de la carte à puce 1 (figure 1).

Par conséquent, l'invention concerne un procédé de gestion d'accès à une ressource partagée par un processus dans un système embarqué multiprocessus, notamment une carte à puce. Deux processus ou plus peuvent poser une requête d'accès à une ressource partagée en même temps. Selon l'invention, on met à la disposition de chaque ressource partagée un compteur signé 5, initialisé à"1", décrémenté d'une unité lorsqu'un processus pose une requête et incrémenté d'une

unité lorsque la ressource est libérée. Une pile 6 enregistre les adresses successives de processus demandeurs, lorsque la ressource est occupée. On prévoit une routine de réservation de ressource et une routine de libération de ressource coopérant avec le compteur 5 et la pile 6 de manière à mettre en attente les processus demandeurs et à les réactiver automatiquement.

Dans une variante de réalisation supplémentaire encore, on peut effectuer des vérifications d'intégrité sur le contenu de la pile 6 (ou de façon plus générale, de la zone de stockage d'adresses de reprise des processus en attente) et du contenu du compteur 5 (ou, de façon plus générale, du contenu de la zone de stockage de la valeur associée à l'état d'occupation de la ressource partagée et du nombre de processus en attente).

Pour ce faire, on peut calculer une valeur dite de"contrôle d'intégrité"ou "checksum"selon la terminologie anglo-saxonne, de type connu tel que, par exemple, de type Adler. Cette opération est exécutée lors de la phase préliminaire d'initialisation. Lorsque l'on incrémente ou décrémente le compteur 5, les "checksum"sont vérifiés et recalculés, sur les contenus de pile 6 et de compteur 5.

A la lecture de ce qui précède, on constate aisément que l'invention atteint bien les buts qu'elle s'est fixés.

Le procédé permet notamment de gérer l'accès simultané d'au moins deux processus concurrents à une même ressource partagée, et de façon préférentielle d'un nombre de processus supérieur à deux. Cette gestion, qui n'exige que la mise en oeuvre de moyens simples, comprend la mise en attente de chaque processus demandeur, lorsque la ressource partagée est occupée, et leur rappel automatique, pour une reprise correcte des processus arrêtés ou non commencés.

Le procédé offre une grande souplesse, car dans le mode de réalisation préféré autorisant la gestion de plus de deux processus, la réactivation des processus en attente peut s'effectuer selon des mécanismes divers : premier entrépremier servi, prise en compte de niveaux de priorité associés à chaque processus, etc.

De façon avantageuse, des mesures de conservation de l'intégrité des données manipulées peuvent également être adoptées, sans augmenter la complexité de façon significative.

Le procédé convient donc parfaitement aux applications mettant en oeuvre des cartes à puce.

Il doit être clair cependant que l'invention n'est pas limitée aux seuls exemples de réalisations explicitement décrits, notamment en relation avec les figures 1 à 5.

Elle n'est pas non plus limitée, comme il a été indiqué, seulement à des carte à puce, mais de façon plus générale à tout système embarqué, qui par nature ne dispose que de ressources informatiques limitées.

La présente invention porte également sur le produit programme d'ordinateur chargeable directement dans la mémoire du système embarqué, comprenant des portions de code de logiciel pour l'exécution des étapes du procédé précédemment décrit lorsque ledit programme est exécuté dans le système embarqué.

Claims

REVENDICATIONS

1-Procédé de gestion d'accès à des ressources partagées dans un système embarqué comportant au moins des moyens de mémoire et des moyens de calcul, ledit système embarqué étant multiprocessus et comportant des ressources (Ry) partagées pouvant être mises à la disposition d'au moins deux processus (Px) posant des requêtes d'accès à ces ressources partagées, caractérisé en ce qu'il comprend, lorsqu'au moins un desdits processus (Px), dits demandeur, pose une requête d'accès à l'une desdites ressources partagées (Ry), une étape (7) de réservation de ressource consistant à : . modifier, pour prendre en compte la requête d'accès du processus (Px), des moyens (5) permettant d'indiquer la disponibilité de la ressource partagée et de tenir compte à cet effet du nombre de processus (Px) ayant émis une requête d'accès à la ressource (Ry) concernée ; tester lesdits moyens (5) et - si les moyens (5) indique que la ressource (Ry) est disponible, donner à (Px) l'accès à la ressource (Ry) ; - si les moyens (5) indique que la ressource (Ry) est indisponible, mettre en attente le processus (Px) concerné par mise en mémoire dans des moyens (6) de stockage de données nécessaires à la ré-activation dudit processus ; les deux opérations de modification et de test pouvant être réalisées dans cet ordre ou dans l'ordre inverse.

2 -Procédé selon la revendication 1, caractérisé en ce qu'il comprend, lorsqu'un processus (Px) libère la ressource (Ry), une étape de libération de ressource consistant à : * modifier les moyens (5) pour prendre en compte la libération de la ressource (Ry) par le processus (Px) ; * tester les moyens (5) pour vérifier si au moins un autre processus a été mis en attente et dans la positive ré-activer un desdits processus mis en attente, ledit processus étant choisi selon un mécanisme donné, et lui donner accès à la ressource (Ry).

les deux opérations de modification et de test pouvant être réalisées dans cet ordre ou dans l'ordre inverse.

3. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce que l'étape (7) de réservation consiste à : incrémente ou décrémenter un compteur (5), la valeur obtenue du compteur lorsqu'une unique incrémentation ou décrémentation de la valeur initiale a été effectuée correspondant à l'état disponible de la ressource concernée et étant appelée valeur de l'état disponible ; tester le compteur (5) et - si le compteur a pour valeur la valeur de l'état disponible, donner à (Px) l'accès à la ressource (Ry) ; - si la valeur du compteur est différente de la valeur de l'état disponible, mettre en attente le processus.

4. Procédé selon la revendication 3, caractérisé en ce que l'étape de libération consiste à : * modifier de manière inverse le compteur (5) ; . tester le compteur (5) et si la valeur du compteur est différente de sa valeur initiale, ré-activer un desdits processus mis en attente, ledit processus étant choisi selon un mécanisme donné, et lui donner accès à la ressource (Ry).

5. Procédé selon les revendications 1 et 2, caractérisé en ce que les étapes de réservation et de libération de ressource sont réalisées par des routines indépendantes.

6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce que les données mises en mémoire et nécessaires à la réactivation du processus dans l'étape de réservation sont une adresse de reprise du processus en question, soit l'adresse suivant celle de l'appel à la routine de réservation.

7. Procédé selon l'une des revendications 2 ou 4, caractérisé en ce que, lesdits processus (Px) étant associés à des niveaux de priorité de traitement déterminés, le mécanisme de réactivation d'un processus mis en attente dans l'étape de libération s'effectue avec prise en compte desdits niveaux de priorité, de manière à ce que, lorsque au moins deux desdits processus demandeurs (Px) sont en attente, le processus demandeur ayant un niveau de priorité le plus élevé soit réactivé en premier.

8. Procédé selon l'une des revendications 1 à 7, caractérisé en ce qu'il comprend en outre des étapes de vérification de l'intégrité de données stockées dans lesdits moyens (5) et moyens (6) de stockage, et en ce que cette vérification s'effectue par le calcul sur chacune de ces données, d'une valeur dite de "contrôle d'intégrité".

9. Système embarqué comportant au moins des moyens de mémoire et des moyens de calcul, ledit système embarqué étant multiprocessus et comportant des ressources partagées pouvant être mises à la disposition d'au moins deux processus posant des requêtes d'accès à ces ressources partagées, caractérisé en ce qu'il comprend, associés à chacune desdites ressources partagées (Ry), des moyens (5) permettant d'indiquer la disponibilité de la ressource partagée à laquelle lesdits moyens sont associés et de tenir compte à cet effet du nombre de processus (Px) ayant émis une requête d'accès à ladite ressource (Ry) concernée, et en ce que lesdits moyens (5) de mémoire stockent une routine dite de réservation de ressource destinée après modification et test des moyens (5), à donner l'accès d'une ressource à un processus demandeur ou à mettre en attente ledit processus si la ressource est indisponible.

10. Système selon la revendication 9, caractérisé en ce qu'il comprend des moyens (6) de stockage permettant la mise en mémoire de données nécessaires à la reprise de processus ayant requis un accès à une ressource donnée et mis en attente compte-tenu de la non-disponibilité de ladite ressource et en ce que les dits moyens (6) de stockage stockent une routine dite de libération de ressource destinée, après modification et test des moyens (5), à donner l'accès au prochain

processus demandeur de ladite ressource concernée ou à réveiller un processus mis en attente pour lui donner accès à ladite ressource.

11. Système selon l'une des revendications 9 ou 10, caractérisé en ce que lesdits moyens (5) consistent en des moyens de stockage d'états prédéterminés, dont l'un représente l'état de disponibilité de la ressource partagée et dont l'ensemble des autres états sont en relation biunivoque avec le nombre de processus en attente.

12. Système selon l'une des revendications 9 à 11, caractérisé en ce que, lesdits moyens (5) consistent en un compteur signé et initialisé à une valeur telle que la ressource est libre lorsque la valeur du compteur est égale à zéro au moment du test.

13. Système selon l'une des revendications 9 à 12, caractérisé en ce qu'il est constitué par une carte à puce (1).

14. Système embarqué comportant au moins des moyens de mémoire et des moyens de calcul, ledit système embarqué étant multiprocessus et comportant des ressources partagées pouvant être mises à la disposition d'au moins deux processus posant des requêtes d'accès à ces ressources partagées caractérisé en ce qu'il met en oeuvre le procédé selon l'une des revendications 1 à 8

15. Programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon l'une des revendications 1 à 8 lorsque ledit programme est exécuté sur un système embarqué.