FR2915006A1

FR2915006A1 - Procede et dispositif de gestion de l'utilisation d'un processeur par plusieurs applications, produit programme d'ordinateur et moyen de stockage correspondants.

Info

Publication number: FR2915006A1
Application number: FR0702708A
Authority: FR
Inventors: Thierry Didi; Jacques Montes
Original assignee: Wavecom SA
Current assignee: Sierra Wireless SA
Priority date: 2007-04-13
Filing date: 2007-04-13
Publication date: 2008-10-17
Anticipated expiration: 2027-04-13
Also published as: EP2145255A1; WO2008125664A1; FR2915006B1; US20100122263A1; CN101836189A; CN101836189B

Abstract

Il est proposé un procédé de gestion, par un système d'exploitation, d'un temps d'utilisation d'un unique processeur par au moins deux applications, ledit temps d'utilisation étant appelé temps processeur. Ce procédé comprend les étapes suivantes : association (1) à chaque application d'une tranche dudit temps processeur, ladite tranche de temps processeur pouvant être nulle ; association (2) à chaque application d'une classe parmi deux possible ; gestion (6) dudit temps processeur en fonction des tranches de temps processeur et des classes associées aux applications. Les deux classes possibles sont : une première classe telle que la tranche de temps processeur qui est associée à ladite application est réservée à ladite application même si ladite application ne l'utilise pas entièrement, ladite application ne pouvant pas utiliser plus que la tranche de temps processeur qui lui est associée ; une seconde classe telle que ladite application est prioritaire pour utiliser le processeur pendant la tranche de temps processeur qui lui est associée, si une partie de la tranche de temps processeur associée à ladite application n'est pas utilisée par ladite application alors ladite partie non utilisée peut être utilisée par une autre application de ladite seconde classe, ladite application pouvant utiliser plus que la tranche temps processeur qui lui est associée en utilisant une partie non utilisée d'une tranche de temps processeur associée à une autre application de ladite seconde classe ou une partie d'une tranche de temps associée à aucune application.

Description

Procédé et dispositif de gestion de l'utilisation d'un processeur par

plusieurs applications, produit programme d'ordinateur et moyen de stockage correspondants. 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des ordinateurs comprenant un unique processeur (aussi appelés ordinateurs mono processeur) et un système d'exploitation permettant de gérer l'exécution, par ce processeur, de plusieurs applications (aussi appelées programmes). Par ordinateur, on entend toute machine permettant de traiter des informations selon des séquences d'instructions ou programmes, y compris notamment des machines de petite taille, telles que des PDA (pour Personal Digital Assistant , ou assistant numérique personnel en français), des dispositifs ou circuits de radiocommunication, ou des appareils électroniques autonomes (sondes spatiales, robot, ordinateur de bord de véhicule,...).

Chaque application comprend un ou plusieurs processus, et permet l'exécution d'une ou plusieurs tâches. En effet, chaque processus comprend une suite d'instructions élémentaires (appelés fils , processus allégés , ou encore threads en anglais) nécessaires à l'exécution d'une tâche. Dans le cas où une application permet l'exécution de plusieurs tâches, chaque tâche peut être associée à un niveau de priorité au sein de l'application. Plus précisément, l'invention concerne une technique de gestion, par un système d'exploitation, d'un temps d'utilisation d'un unique processeur par au moins deux applications. Dans la suite de la description, on appelle temps processeur le temps d'utilisation du processeur. L'invention s'applique notamment, mais non exclusivement, dans le cas où le système d'exploitation est un système d'exploitation temps réel (ou RTOS, pour Real Time Operating System en anglais), c'est-à-dire dans le cas où au moins une des applications doit être exécutée en temps réel. 2. ART ANTÉRIEUR Il est courant que plusieurs processus (et donc plusieurs tâches) soient exécutés en parallèle sur un ordinateur monoprocesseur. Le système d'exploitation est alors qualifié de multi-tâche. En effet, un des rôles du système d'exploitation (et plus précisément de l'ordonnanceur du noyau du système d'exploitation) est de permettre à plusieurs processus de s'exécuter et d'utiliser le processeur de manière optimale du point de vue de l'utilisateur. De façon classique, pour arriver à donner l'illusion que plusieurs processus sont traités simultanément, l'ordonnanceur s'appuie sur des notions de commutation de contexte et d'ordonnancement. On peut distinguer deux familles de systèmes d'exploitation temps-réel : ceux qui mettent en oeuvre un ordonnancement des tâches par priorités (ou Priority Scheduling en anglais), et ceux mettant en oeuvre un ordonnancement des tâches par tranches de temps (ou Time Sharing Scheduling ou encore Time Slicing Scheduling en anglais). Dans le cas d'un système d'exploitation temps-réel mettant en oeuvre un ordonnancement des tâches par priorités, chaque tâche se voit attribuer une priorité et peut se trouver dans l'un des cinq états suivants : dormante (elle n'est pas ordonnancée), exécutable (elle est prête a exécuter des instructions mais ne possède pas en ce moment l'usage du processeur), active (ses instructions sont en cours d'exécution par le processeur), bloquée (son exécution est suspendue en attente d'un signal ou de la disponibilité d'une ressource) et interrompue (elle exécute une routine d'interruption programmée par l'utilisateur). L'ordonnanceur attribue toujours le processeur à la tâche non dormante et non bloquée qui possède la plus haute priorité. S'il est possible que plusieurs tâches de même priorité deviennent actives, plusieurs stratégies sont envisageables : soit on alterne l'exécution de séquences bornées d'instructions de toutes ces tâches (technique dite de Time Slicing en anglais, du fait que chaque tâche dispose de tranches de temps successives), soit on attribue arbitrairement le processeur à une de ces tâches, soit on évite cette situation en interdisant d'attribuer la même priorité à deux tâches distinctes. Quand une tâche T2 plus prioritaire qu'une tâche Ti active passe de l'état bloqué à l'état exécutable, deux mécanismes sont possibles : soit la tâche T2 reste suspendue (état exécutable) jusqu'à la complétion de Ti. L'ordonnanceur n'est alors pas préemptif. L'inconvénient est que le temps de réponse d'une tâche est affecté par le comportement des tâches moins prioritaires ; soit le système d'exploitation bascule la tâche Ti dans l'état exécutable et attribue le processeur à T2. L'ordonnanceur est préemptif.

Dans le cas d'un système d'exploitation temps-réel mettant en oeuvre un ordonnancement des tâches par tranches de temps, l'algorithme d'ordonnancement est de type Round-robin : il attribue des tranches de temps à chaque processus en proportion égale, sans accorder de priorité aux processus. Malheureusement, aucune des deux techniques connues précitées d'ordonnancement des tâches (par priorités ou par tranches de temps) ne fournit une solution optimale au problème de la gestion d'un temps d'utilisation d'un unique processeur par plusieurs applications. Un inconvénient commun à ces deux techniques connues est qu'elles ne permettent pas de définir précisément les moments où une application donnée pourra disposer du processeur. La technique d'ordonnancement des tâches par priorités présente d'autres inconvénients découlant du fait qu'elle effectue une gestion au niveau tâche, et pas au niveau application : - une tâche d'une première application peut toujours être arrêtée (elle bascule alors dans l'état exécutable) du fait qu'une tâche plus prioritaire d'une deuxième application passe dans l'état exécutable. Donc, cette première application n'a pas un temps processeur minimal assuré. Il paraît difficile d'harmoniser les priorités des tâches de toutes les applications, d'autant plus qu'il est fréquent que les applications devant s'exécuter sur le même processeur proviennent de fournisseurs différents ; - si la tâche la plus prioritaire (toutes applications confondues) provoque un plantage informatique ( crash en anglais), toutes les applications (et pas seulement celle à laquelle appartient la tâche ayant provoqué le plantage) sont bloquées et ne peuvent utiliser le processeur. La solution proposée aujourd'hui pour résoudre ce problème consiste à prévoir un mécanisme de chien de garde ( watchdog en anglais) destiné à s'assurer qu'une application ne s'est pas bloquée à une étape particulière du traitement. Ce mécanisme est une protection destinée à redémarrer le système si une action définie n'est pas exécutée dans un délai donné. La technique d'ordonnancement des tâches par tranches de temps présente elle aussi un inconvénient découlant du fait qu'elle effectue une gestion au niveau tâche, et pas au niveau application. Il possible de garantir un temps processeur minimal par tâche, mais il est impossible de garantir un temps processeur minimal pour une application donnée. En effet, le temps processeur dont dispose réellement chaque application dépend du nombre total d'applications exécutées par le processeur (en outre, toutes les applications n'ont pas le même nombre de tâches). Or certaines applications ont besoin de plus de temps processeur que d'autres et surtout ont besoin d'un temps processeur minimal (cas par exemple d'une application d'appel en urgence, en cas d'accident). Un autre inconvénient de la technique d'ordonnancement des tâches par tranches de temps est qu'elle n'utilise pas de façon optimale le temps processeur. En effet, si une tâche n'utilise pas toute la tranche de temps qui lui est dédiée, la partie non utilisée de cette tranche de temps ne peut pas être affectée à une autre tâche, et est donc perdue. 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique.

Plus précisément, l'un des objectifs de la présente invention, dans au moins un mode de réalisation, est de fournir une technique de gestion, par un système d'exploitation, d'un temps d'utilisation d'un unique processeur par au moins deux applications, cette technique permettant de garantir un temps processeur minimal à chacune des applications, même si une des applications est bloquées.

L'invention a également pour objectif, dans au moins un mode de réalisation, de fournir une telle technique permettant d'optimiser l'utilisation du temps processeur. Un objectif complémentaire de l'invention, dans au moins un mode de réalisation, est de fournir une telle technique qui soit simple à mettre en oeuvre et peu coûteuse.

Un objectif complémentaire de l'invention, dans au moins un mode de réalisation, est de fournir une telle technique qui soit transparente pour les applications quand elles s'exécutent. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de gestion, par un système d'exploitation, d'un temps d'utilisation d'un unique processeur par au moins deux applications, ledit temps d'utilisation étant appelé temps processeur, ledit procédé comprenant les étapes suivantes : - association à chaque application d'une tranche dudit temps processeur, ladite tranche de temps processeur pouvant être nulle ; - association à chaque application d'une des deux classes suivantes : * une première classe telle que la tranche de temps processeur qui est associée à ladite application est réservée à ladite application même si ladite application ne l'utilise pas entièrement, ladite application ne pouvant pas utiliser plus que la tranche de temps processeur qui lui est associée ; * une seconde classe telle que ladite application est prioritaire pour utiliser le processeur pendant la tranche de temps processeur qui lui est associée, si une partie de la tranche de temps processeur associée à ladite application n'est pas utilisée par ladite application alors ladite partie non utilisée peut être utilisée par une autre application de ladite seconde classe, ladite application pouvant utiliser plus que la tranche temps processeur qui lui est associée en utilisant une partie non utilisée d'une tranche de temps processeur associée à une autre application de ladite seconde classe ou une partie d'une tranche de temps associée à aucune application ; et - gestion dudit temps processeur en fonction des tranches de temps processeur et des classes associées aux applications. Le principe général de ce mode de réalisation consiste donc à effectuer une gestion du temps processeur au niveau des applications elles-mêmes (chaque application pouvant comprendre un ou plusieurs processus, chaque processus exécutant une tâche), et non pas au niveau des tâches.

Quelle que soit la classe qui lui est associée, chaque application dispose d'un temps processeur minimal garanti puisqu'une tranche de temps processeur (éventuellement nulle) lui est associée. Par ailleurs, l'utilisation du temps processeur est optimisée puisque, entre applications de la seconde classe, les parties de tranches de temps processeur non utilisées par certaines applications sont réutilisées par d'autres applications. Il est également à noter que cette technique est transparente pour les applications qui s'exécutent. C'est le système d'exploitation qui gère l'utilisation du processeur. Les applications n'ont aucune requête à émettre pour utiliser le processeur.

De façon avantageuse, ledit temps processeur est découpé en cycles, chaque cycle comprenant un nombre N d'intervalles de temps, et la tranche de temps processeur associée à chaque application comprend un nombre K; d'intervalles de temps dans chaque cycle, avec 1 s K, < N, et i un indice relatif à l'application. La durée de chaque intervalle de temps définit la granularité de la commutation de contexte entre applications. Une durée faible risque d'alourdir le fonctionnement du système avec, potentiellement, un nombre élevé de commutations de contexte entre applications. Une durée élevée ne permet pas de répartir de façon fine le temps processeur entre les applications. Avantageusement, ledit procédé comprend l'étape suivante : si, pendant un cycle courant, une application de seconde classe n'a pas utilisé la totalité de la durée de ses K; intervalles de temps du fait qu'elle n'avait pas besoin du processeur pendant X desdits K; intervalles de temps mais requiert finalement l'utilisation d'un nombre d'intervalles de temps supérieur au nombre Y d' intervalles de temps restants pour ladite application de seconde classe, avec Y = K; ù X, alors modification dynamique du nombre d'intervalles de temps K, pendant au moins un cycle suivant. Ainsi, un premier mécanisme de rattrapage est proposé, permettant à une application donnée, sur plusieurs cycles, d'utiliser le processeur pendant un nombre d'intervalles de temps égal ou proche du nombre d'intervalles de temps réellement associés à cette application.

Selon une caractéristique avantageuse, ledit procédé comprend l'étape suivante : si, pendant un cycle courant, une application de seconde classe n'a pas utilisé la totalité de la durée de ses K; intervalles de temps du fait qu'elle n'avait pas besoin du processeur pendant X desdits K; intervalles de temps mais requiert finalement l'utilisation d'un nombre d'intervalles de temps supérieur au nombre Y d' intervalles de temps restants pour ladite application de seconde classe, avec Y = K; û X, alors modification dynamique de la durée d'au moins un cycle suivant. Ainsi, un second mécanisme de rattrapage est proposé, permettant à une application donnée, sur plusieurs cycles, d'utiliser le processeur pendant une durée totale cumulée égale ou proche de la durée réellement associée à cette application. De façon avantageuse, ledit procédé comprend l'étape suivante, pour au moins une desdites applications : association à ladite application d'un instant de début pour la tranche de temps processeur associée à ladite application, ou d'un instant de début pour chaque intervalle de temps compris dans la tranche de temps processeur associée à ladite application. Ainsi, il est possible de garantir qu'une application va prendre la main à des moments précis. Ceci est très important notamment dans le cas où certaines applications doivent être synchronisées avec d'autres. Avantageusement, ledit procédé comprend l'étape suivante, pour au moins une application de la seconde classe : association à ladite application d'un niveau de priorité, permettant de décider quelle application de la seconde classe peut utiliser le processeur dans le cas où plusieurs applications de la seconde classe sont éligibles pour utiliser le processeur. Ainsi, on décide à l'avance quelles applications de la seconde classe vont prioritairement utiliser le temps processeur disponible du fait que des applications de la seconde classe n'utilisent pas toutes les tranches de temps processeur qui leur sont associées. Selon une variante, on utilise un algorithme de type Round-robin pour décider quelle application de la seconde classe peut utiliser le processeur dans le cas où plusieurs applications de la seconde classe sont éligibles pour utiliser le processeur. En d'autres termes, on répartit équitablement entre applications de la seconde classe le temps processeur disponible du fait que des applications de la seconde classe n'utilisent pas toutes les tranches de temps processeur qui leur sont associées.

Avantageusement, ledit procédé comprend une étape de vérification que la somme des tranches de temps processeur de toutes les applications est inférieure ou égale à 100% d'un temps processeur application, défini comme la différence entre ledit temps processeur et une partie dudit temps processeur utilisée par ledit système d'exploitation. De cette façon, on vérifie que le système est convenablement configuré pour fonctionner dans le pire cas, c'est-à-dire si chacune des applications utilisait la totalité de la tranche de temps processeur qui lui a été associée (du fait qu'elle en a réellement besoin, cas d'une application gourmande en temps processeur, ou du fait qu'il y un bogue, cas d'une application entrée en boucle). Dans un mode de réalisation particulier de l'invention, ledit système d'exploitation est un système d'exploitation temps réel. La présente invention est particulièrement adaptée pour répondre aux contraintes temps réel. II convient de choisir convenablement la tranche de temps associée à chaque application devant s'exécuter en temps réel. De façon avantageuse, au moins une interruption, dite interruption d'un premier type, n'est associée à aucune desdites applications et n'est pas prise en compte dans la gestion dudit temps processeur. Chaque interruption du premier type est donc considérée comme du bruit système . Avantageusement, au moins une interruption, dite interruption d'un deuxième type, n'est associée à aucune desdites applications et est prise en compte dans la gestion dudit temps processeur de la façon suivante : une quantité de temps est réservée pour l'ensemble des interruptions du deuxième type, de sorte que la somme des tranches de temps processeur de toutes les applications est inférieure ou égale à 100% dudit temps processeur moins ladite quantité de temps réservée. Ainsi, on tient compte des interruptions du deuxième type dans la gestion du temps processeur, mais indépendamment des applications. Selon une caractéristique avantageuse, au moins une interruption, dite interruption d'un troisième type, est associée à au moins une desdites applications et est prise en compte dans la gestion dudit temps processeur de la façon suivante : une quantité de temps processeur nécessaire à ladite interruption du troisième type est prise en compte dans la tranche de temps processeur de la ou les applications associée(s) à ladite interruption du troisième type ; et - le temps processeur préempté par ladite interruption du troisième type sur au moins une autre application est rétrocédé à ladite au moins une autre application. Ainsi, on tient compte des interruptions du troisième type dans la gestion du temps processeur, mais en relation avec les applications auxquelles elles sont associées. Dans un mode de réalisation particulier de l'invention, ledit processeur est compris dans un circuit de radiocommunication, et lesdits applications comprennent une application de gestion d'une pile de radiocommunication et au moins une application cliente. L'invention s'applique notamment, mais non exclusivement, dans le cas où le circuit de radiocommunication est un module électronique de radiocommunication destiné à être intégré à un dispositif de radiocommunication. Par dispositifs de radiocommunication (aussi appelés terminaux de radiocommunication ou terminaux sans-fil), on entend tous dispositifs ou moyens capables d'échanger des signaux à l'aide d'un système de radiocommunication, implantés par exemple dans des machines ou des véhicules (marchés M2M, pour Machine to Machine , et automobile). Le module électronique de radiocommunication est par exemple un module de la famille WISMO (marque déposée) de la société WAVECOM (déposante de la présente demande de brevet). La société WAVECOM a en effet depuis plusieurs années proposé une approche palliant un certain nombre de ces inconvénients, consistant à regrouper dans un module unique (appelé module électronique de radiocommunication), tout ou au moins la plupart des fonctions d'un dispositif de radiocommunication numérique. Un tel module se présente sous la forme d'un boîtier unique, préférentiellement blindé, que les fabricants de dispositifs peuvent implanter directement, sans devoir prendre en compte une multitude de composants. Ce module est formé d'un regroupement de plusieurs composants sur un substrat, de façon à être implanté sous la forme d'un unique élément. Il comprend les composants (notamment un processeur, des mémoires, et des logiciels) essentiels nécessaires au fonctionnement d'un dispositif de radiocommunication utilisant des fréquences radioélectriques. Il n'y a donc plus d'étapes complexes de conception du design, et de validation de celui-ci. Il suffit de réserver la place nécessaire au module. Un tel module permet donc d'intégrer facilement, rapidement et de façon optimisée l'ensemble des composants dans des terminaux sans-fil (téléphones portables, modems, ou tout autre dispositif exploitant un standard sans fil).

Dans une variante d'application de l'invention, le circuit de radiocommunication n'est pas un module de radiocommunication au sens précité mais un circuit imprimé compris dans un dispositif de radiocommunication et sur lequel sont directement implantés un ensemble de composants électroniques ayant pour but d'assurer les différentes fonctions de radiocommunication nécessaires, depuis la réception d'un signal RF jusqu'à la génération d'un signal audible (dans le cas d'un radio-téléphone), et inversement. Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, ce produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre du procédé précité, lorsque ledit programme est exécuté sur un ordinateur. Dans un autre mode de réalisation, l'invention concerne un moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé précité. Dans un autre mode de réalisation, l'invention concerne un dispositif comprenant un système d'exploitation permettant de gérer un temps d'utilisation d'un unique processeur par au moins deux applications, ledit temps d'utilisation étant appelé temps processeur. Ce dispositif comprend : des moyens d'association à chaque application d'une tranche dudit temps processeur, ladite tranche de temps processeur pouvant être nulle ; - des moyens d'association à chaque application d'une des deux classes suivantes : * une première classe telle que la tranche de temps processeur qui est associée à ladite application est réservée à ladite application même si ladite application ne l'utilise pas entièrement, ladite application ne pouvant pas utiliser plus que la tranche de temps processeur qui lui est associée ; * une seconde classe telle que ladite application est prioritaire pour utiliser le processeur pendant la tranche de temps processeur qui lui est associée, si une partie de la tranche de temps processeur associée à ladite application n'est pas utilisée par ladite application alors ladite partie non utilisée peut être utilisée par une autre application de ladite seconde classe, ladite application pouvant utiliser plus que la tranche temps processeur qui lui est associée en utilisant une partie non utilisée d'une tranche de temps processeur associée à une autre application de ladite seconde classe ou une partie d'une tranche de temps associée à aucune application ; et - des moyens de gestion dudit temps processeur en fonction des tranches de temps processeur et des classes associées aux applications. Plus généralement, le dispositif comprend des moyens de mise en oeuvre du procédé de gestion de temps processeur tel que décrit précédemment (dans l'un quelconque de ses différents modes de réalisation). 5. LISTE DES FIGURES D'autres caractéristiques et avantages de modes de réalisation de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif (tous les modes de réalisation de l'invention ne sont pas limités aux caractéristiques et avantages des modes de réalisation décrits ci-après), et des dessins annexés, dans lesquels : la figure 1 présente un organigramme d'un mode de réalisation particulier du procédé selon l'invention ; - la figure 2 illustre un premier exemple de partage du temps processeur entre trois applications associées à la classe CTR, selon un mode de réalisation particulier de l'invention ; la figure 3 illustre un second exemple de partage du temps processeur entre trois applications, l'une associée à la classe CTR et les deux autres à la classe VTR, selon un mode de réalisation particulier de l'invention ; la figure 4 illustre un exemple de tables de tâches et de gestionnaires d'interruption associés à trois applications, ainsi que le partage du temps processeur entre ces trois applications ; et la figure 5 illustre un troisième exemple de partage du temps processeur entre trois applications associées à la classe VTR, selon un mode de réalisation particulier de l'invention. 6. DESCRIPTION DÉTAILLÉE On présente maintenant, en relation avec la figure 1, un mode de réalisation particulier du procédé selon l'invention de gestion, par un système d'exploitation, d'un temps d'utilisation d'un unique processeur (appelé temps processeur par la suite) par au moins deux applications. Dans une étape 1, on associe à chaque application une tranche du temps processeur (ou CPU Time Slice en anglais). Pour cela, on utilise par exemple une minuterie ( timer en anglais) périodique permettant de découper le temps processeur en cycles, chaque cycle comprenant un nombre N d'intervalles de temps (aussi noté AST par la suite, pour Application Scheduling Tick en anglais). La tranche de temps processeur associée à chaque application comprend un nombre K; d'intervalles de temps dans chaque cycle, avec 1 s K, < N, et i un indice relatif à l'application. Chaque tranche de temps est donc composée de la récurrence d'un certain nombre d'intervalles de temps au sein d'une structure cyclique comprenant un nombre déterminé d'intervalles de temps. Par exemple, si un intervalle de temps a une durée de 20 ms et si un cycle comprend 5 intervalles de temps, une application peut être associée à une tranche de temps comprenant 2*20 ms toutes les 100 ms. Dans une étape 2, on associe à chaque application une des deux classes d'application suivantes : - classe CTR (pour Constant Time Rate en anglais, ou part de temps constante en français), telle que la tranche de temps processeur qui est associée à une application CTR est réservée à cette application même si elle ne l'utilise pas entièrement (c'est-à-dire même si elle n'a pas d'activité logicielle pendant cette tranche de temps). Une application CTR ne peut pas utiliser plus que la tranche de temps processeur qui lui est associée, même si le processeur est au repos ; - classe VTR (pour Variable Time Rate en anglais, ou part de temps variable en français), telle qu'une application CTR est prioritaire pour utiliser le processeur pendant la tranche de temps processeur qui lui est associée. Si une partie de la tranche de temps processeur associée à une application VTR n'est pas utilisée par celle-ci, alors elle peut être utilisée par une autre application VTR. Une application VTR peut utiliser plus que la tranche temps processeur qui lui est associée, en utilisant une partie non utilisée d'une tranche de temps processeur associée à une autre application VTR ou une partie d'une tranche de temps associée à aucune application. Dans une étape 3, un instant de début d'exécution peut être associé à au moins une application. Cet instant de début est par exemple défini par le numéro (rang au sein du cycle précité) du premier des intervalles de temps affectés à cette application. Si l'on reprend l'exemple ci-dessus (intervalle de temps de 20 ms et cycle de 5 intervalles de temps), la tranche de temps comprenant 2*20 ms toutes les 100 ms débute par exemple, à chaque cycle, avec le premier des cinq intervalles du cycle. Dans une étape 4, on associe à chacune desapplications VTR (ou seulement à certaines d'entre elles) un niveau de priorité. Cette priorité est utilisée pour décider quelle application VTR peut utiliser le processeur dans le cas où plusieurs applications VTR sont éligibles pour utiliser le processeur (quand ce dernier est au repos). A l'issue de ces étapes 1 à 4, l'ensemble des informations associées aux applications peuvent être stockées dans une mémoire par le système d'exploitation, par exemple sous la forme de la table ci-dessous (on y a noté M le nombre d'applications). Cette table est appelée par la suite table ART (pour Applications Rate Table en anglais). Application Classe Nombre Priorité Date de début d'AST (si application VTR) (numéro d'AST) Application n 1 Cl K, Pl X Application n M CM KM Pm Y Ainsi, par exemple, l'application n 1 est associée à la classe C, (CTR ou VTR), à une tranche de temps processeur comprenant K, intervalles de temps par cycle et commençant au Xème intervalle de temps de chaque cycle, et à une priorité P, (s'il s'agit d'une application VTR).

Dans une étape 5, le système d'exploitation vérifie que la somme des tranches de temps processeur de toutes les applications est inférieure ou égale à 100% d'un temps processeur application, défini comme la différence entre le temps processeur total et une partie de ce temps processeur total qui est utilisée par le système d'exploitation. Dans l'exemple précité, cela revient à vérifier que le nombre total cumulé d'intervalles de temps associés aux différentes applications n'est pas supérieur au nombre d'intervalles de temps dans un cycle. Dans une étape 6, le système d'exploitation gère le temps processeur en fonction de l'ensemble des informations associées aux applications (c'est-à-dire en fonction du 10 contenu de la table ART précitée). La figure 2 illustre un premier exemple de partage du temps processeur, dont la table ART est la suivante : Application Classe Nombre Priorité Date de début d'AST (si application VTR) (numéro d'AST) Al CTR 1 (20 ms) non applicable let AST A2 CTR 2 (40 ms) non applicable 2' AST A3 CTR 1 (20 ms) non applicable 4'me AST On suppose que chaque intervalle de temps (AST) a une durée (DAST) de 20 ms, et qu'un cycle comprend 5 intervalles de temps, c'est-à-dire a une durée (Dcyc,e) de 100 15 ms. On voir sur la figure 2 que le premier intervalle de temps est réservé à l'application Al, qui l'utilise entièrement. Les deuxième et troisième intervalles de temps sont réservés à l'application A2, qui ne les utilise pas entièrement. Mais la partie (référencée 20) non utilisée par 20 l'application A2 ne peut pas être utilisée par une autre application, du fait que l'application A2 est une application de la classe CTR. Le quatrième intervalle de temps est réservé à l'application A3, qui l'utilise entièrement. Le cinquième intervalle de temps (référencé 21) ne pouvant être utilisé par 25 aucune des applications Al, A2 et A3 (car elles sont toutes de la classe CTR), le processeur peut commuter en mode basse consommation. Ce cinquième intervalle de temps est disponible en cas de modification du jeu d'applications se partageant le temps processeur. La figure 3 illustre un deuxième exemple de partage du temps processeur, dont la table ART est la suivante : Classe Nombre Priorité Date de début d'AST (si application VTR) (numéro d'AST) Al CTR 1 (20 ms) non applicable le" AST A2 VTR 2 (40 ms) Pmax Non spécifié A3 VTR 0 (0 ms) Pmin Non applicable On suppose à nouveau que chaque intervalle de temps (AST) a une durée (DAST) de 20 ms, et qu'un cycle comprend 5 intervalles de temps, c'est-à-dire a une durée (Dcyc,e) de 100 ms. On voir sur la figure 3 que le premier intervalle de temps est réservé à l'application Al, qui l'utilise entièrement.

Les deuxième et troisième intervalles de temps sont réservés à l'application A2, qui ne les utilise pas entièrement. A partir de l'instant référencé T1, l'application A2 n'a plus besoin du processeur et du fait qu'il s'agit d'une application de classe VTR, elle peut passer la main à une autre application de classe VTR : l'application A3 en l'espèce. A l'instant référencé T2 situé avant la fin du troisième intervalle de temps, un événement externe intervient pour l'application A2, qui reprend la main puisque les deuxième et troisième intervalles de temps lui sont réservés. A l'instant référencé T3 situé avant la fin du troisième intervalle de temps, l'application A2 n'a à nouveau plus besoin du processeur et passe donc la main à l'application A3. Les quatrième et cinquième intervalles de temps ne sont réservés à aucune des applications mais peuvent être utilisés par les applications de la classe VTR, c'est-à-dire les applications A2 et A3 (l'application 2 étant prioritaire sur l'application 3, dans le cas où elles souhaitent toutes les deux utiliser le processeur au même moment. Dans l'exemple illustré sur la figure 3, une partie (référencée 30) des quatrième et cinquième intervalles de temps n'est pas utilisée.

On présente avec la figure 4 un exemple de tables de tâches et de gestionnaires d'interruption associés à trois applications, ainsi que le partage du temps processeur entre ces trois applications. Chaque application (Al, A2 et A3 respectivement) est associée à : - une table de tâches (401, 402 et 403 respectivement), comprenant : * une tâche REPOS (Tâche Al-repos, Tâche A2-repos et Tâche A3-repos respectivement) permettant de détecter l'inactivité de l'application concernée et des commutations entre applications possibles ; * des tâches classiques (par exemple Tâches Al-1, Al-2 et Al-3 pour l'application Al) ; et - un gestionnaire d'interruption (411, 412 et 413 respectivement) ( Interrupt Handler ou ISR (Interrupt Service Routine) en anglais). On décrit maintenant un mode de mise en oeuvre particulier de l'invention. Chaque application comprend un jeu de tâches temps réel, chacune de ces tâches étant affectée d'un niveau de priorité (entre 0 et 100 par exemple). Le système d'exploitation temps réel configure la durée d'un intervalle de temps (20 ms par exemple). La table ART stocke les informations associées à chaque application : classe de cette application (CTR ou VTR), nombre d'intervalles de temps affectés à cette application, niveau de priorité de cette application (pour les applications VTR seulement) (à ne pas confondre avec les niveaux de priorité des tâches comprises dans cette même application) et, éventuellement, instant de début de cette application dans le cycle (c'est-à-dire le rang, au sein du cycle, du premier intervalle de temps affecté à cette application). Au démarrage, le système d'exploitation : - crée une table de tâches pour chaque application, avec ses tâches correspondantes (cf figure 4) ; - commence le premier intervalle de temps ; - lance la première application de la table ART, en chargeant la table de tâches correspondante ; - ordonnance les tâches en fonction de leur état et de leur priorité.

A chaque expiration d'un intervalle de temps, le système d'exploitation temps réel vérifie que la durée affectée à l'application active courante est atteinte. En cas de vérification positive, alors il lance l'application suivante (en chargeant la table de tâches correspondante). Quand l'application active courante entre dans sa tâche REPOS : - si l'application est de la classe CTR, alors aucune commutation d'application ne se produit (la tranche de temps est non préemptive) ; - si l'application est de la classe VTR, alors le système d'exploitation : * mémorise la proportion de sa tranche de temps processeur que cette application a déjà utilisée ; * vérifie si une autre application VTR est en attente du processeur. Si plusieurs applications VTR sont éligibles, celle de plus haute priorité est choisie) ; * si une telle application est trouvée, elle est lancée (en chargeant la table de tâches correspondante). Un mécanisme de type chien de garde ( watchdog en anglais) est par exemple mis en oeuvre pour détecter qu'une application ne revient pas au repos après un nombre déterminé de cycles. En effet, une telle situation peut être normale (par exemple, s'il s'agit d'une application utilisant intensivement le processeur) ou non (l'application est entrée dans une boucle infinie). Quand une telle situation est détectée, au moins une des actions suivantes est mise en oeuvre : notification à l'application (rappel) qu'elle a dépensé plus qu'une quantité de temps prédéfinie avant de repasser à la tâche REPOS, réinitialisation de l'application, réinitialisation de l'ensemble du système. Si une première application de la classe VTR n'a pas besoin du processeur pendant un de ses intervalles de temps (c'est-à-dire un des intervalles de temps qui lui ont été associés), le processeur peut être utilisé par une autre application de la classe VTR. Si la première application a finalement besoin du processeur avant la fin de son intervalle de temps, il reprend la main et peut utiliser le processeur. Néanmoins, à la fin du cycle courant, la première application peut ne pas avoir eu le temps processeur qui lui était réservé pendant ce cycle. Au moins un des mécanismes de compensation suivant est par exemple mis en oeuvre : pendant au moins un cycle suivant, modification dynamique du nombre d'intervalles de temps associés à la première application (par pas de +10% ou - 10% par exemple) ; -modification dynamique de la durée d'au moins un cycle suivant (par pas de 5 +10% ou -10% par exemple). On présente maintenant, en relation avec la figure 5, un troisième exemple de partage du temps processeur, dont la table ART est la suivante : Application Classe Nombre Priorité Date de début d'AST (si application VTR) (numéro d'AST) Al (eCall) VTR 1 (20 ms) P1 (medium) Non spécifié A2 (Nav) VTR 1 (20 ms) P2 (min) 1ei AST A3 (Kit main VTR 3 (60 ms) P3 (max) Non spécifié libre) On suppose à nouveau que chaque intervalle de temps (AST) a une durée (DAST) de 20 ms, et qu'un cycle comprend 5 intervalles de temps, c'est-à-dire a une durée 10 (Dcyc,e) de 100 ms. On suppose également qu'attribuer un intervalle de temps de 20 ms toutes les 100 ms à une application est équivalent à accorder une capacité d'utilisation du processeur de 20 MIPS. L'application Al est une application d'appel d'urgence, par exemple l'application eCall . En cas d'accident, le dispositif de radiocommunication qui 15 exécute l'application eCall et qui est installé dans un véhicule envoie un appel d'urgence à un centre de réception des appels d'urgence le plus approprié, et envoie en même temps un certains nombre de données relatives au véhicule (notamment sa localisation précise). L'appel d'urgence peut être déclenché manuellement par les occupants du véhicule ou automatiquement, en cas d'accident grave, grâce à des capteurs 20 installés dans le véhicule. Les contraintes principales de l'application eCall sont : - utilisation de 5 MIPS en mode normal, et 15 MIPS pendant un appel d'urgence ; - protection contre les bogues dans d'autres applications embarquées dans le même dispositif de radiocommunication (elle doit pouvoir s'exécuter dans tous les cas) ; et 25 - réaction à un accident en moins de lseconde.

Ces contraintes sont respectées par l'attribution d'un intervalle de temps de 20 ms toutes les 100 ms, ce qui est équivalent à 20 MIPS. L'application A2 est une application de navigation GPS ( Nav ), qui par exemple envoie sur une liaison sans fil Bluetooth des messages conformes au protocole NMEA-0183 ( National Marine Electronics Association ). Ses contraintes principales sont : - exécution au moins une fois par seconde (pendant 100 ms) ; et - utilisation d'au moins 1 MIPS. Ces contraintes sont respectées par l'attribution d'un intervalle de temps de 20 ms toutes les 100 ms, ce qui est équivalent à 20 MIPS. En outre, le fait que l'intervalle de temps attribué soit le premier du cycle garantit que des messages NMEA peuvent être envoyés précisément à chaque seconde (c'est-à-dire tous les dix cycles). L'application A3 est une application de kit main libre (KML), qui par exemple peut mettre en oeuvre : une reconnaissance vocale automatisée (ASR, pour Automatic Speech Recognition en anglais) et une synthèse vocale (TTS, pour Text To Speech en anglais) ; et un établissement d'appel GSM, qui utilise 2 MIPS. La contrainte principale de l'application A3 est que la reconnaissance vocale automatisée (ASR) doit traduire une phrase en moins de deux secondes pour une bonne interaction humaine, et pour cela doit disposer d'au moins 60 MIPS quand elle est exécutée. Cette contrainte est respectée par l'attribution de trois intervalles de temps (soit 60 ms au total) toutes les 100 ms (ce qui est équivalent à 60 MIPS), et du niveau de priorité maximal. Ainsi, les fonctions de reconnaissance vocale (ASR) et synthèse vocale (TTS) peuvent utiliser tout le temps processeur non utilisé par les autres applications. En mode nominal, l'application eCall utilise 15 MIPS en cas d'urgence et l'application Nav utilise 1 MIPS. Il reste donc 84 MIPS pour les fonctions ASR et TTS. Dans le pire des cas, les applications eCall et Nav sont entrées dans une boucle infinie, et bloque chacune 20 MIPS. Il reste quand même 60 MIPS pour les fonctions ASR et TTS.

Par ailleurs, diverses stratégies peuvent être envisagées pour la gestion des interruptions. Ces différentes stratégies peuvent être appliquées simultanément à différentes interruptions. On rappelle qu'une interruption est l'appel d'une routine spéciale appelée ISR (pour Interrupt Service Routine ).

Stratégie n 1 : une interruption d'un premier type n'est associée à aucune des applications (soit parce qu'elle sert plusieurs applications, soit parce qu'elle utilise une très petite quantité de temps, ou encore pour toute autre choix de conception) et elle n'est pas prise en compte dans la gestion du temps processeur. Elle est considérée comme du bruit système .

Stratégie n 2 : une interruption d'un deuxième type n'est associée à aucune des applications (soit parce qu'elle sert plusieurs applications, soit parce qu'elle utilise une très petite quantité de temps, ou encore pour toute autre choix de conception) mais elle doit être prise en compte dans la gestion du temps processeur. Une quantité de temps est réservée pour l'ensemble des interruptions de ce deuxième type, de sorte que la somme des tranches de temps processeur de toutes les applications est inférieure ou égale à 100% du temps processeur moins la quantité de temps réservée. On suppose que cette quantité de temps réservée est redistribuée de façon égale entre toutes les applications. Par conséquent, statistiquement, toutes les applications se voient attribuées leurs tranches de temps respectives.

Stratégie n 3 : une interruption d'un troisième type est associée à une ou plusieurs applications et est prise en compte dans la gestion du temps processeur de la façon suivante : - une quantité de temps processeur nécessaire à l'interruption du troisième type est prise en compte dans la tranche de temps processeur de la ou les applications associée(s) à cette interruption du troisième type ; et - le temps processeur préempté par cette interruption du troisième type sur au moins une autre application est rétrocédé à cette au moins une autre application (sauf si cette au moins une autre application est celle à laquelle est associée l'interruption du troisième type).

Dans un mode de réalisation particulier, le processeur est partagé entre une application de gestion d'une pile de radiocommunication ( pile GSM par exemple) et au moins une application cliente. Ceci s'applique notamment dans le cas où le processeur est compris dans un circuit de radiocommunication, comme par exemple un module électronique de radiocommunication destiné à être intégré à un dispositif de radiocommunication. Ce module électronique de radiocommunication est par exemple un module de la famille WISMO (marque déposée) de la société WAVECOM (déposante de la présente demande de brevet). Dans ce cas, la pile de radiocommunication est considérée comme une application, à laquelle peuvent être associées diverses informations, comme par exemple : classe (CTR ou VTR), nombre d'intervalles de temps, niveau de priorité (pour les applications VTR seulement) et, éventuellement, instant de début de cette application dans le cycle. La pile de radiocommunication possède typiquement une interruption (ISR) forte consommatrice de temps processeur. Cette interruption est gérée selon l'une des trois stratégies précitées. Dans un mode de réalisation particulier de l'invention, la stratégie n 3 est adoptée : l'interruption est associée avec la pile elle-même, et le temps processeur consommée par cette interruption est restituée aux applications auxquelles ce temps a été préempté.

Claims

REVENDICATIONS

1. Procédé de gestion, par un système d'exploitation, d'un temps d'utilisation d'un unique processeur par au moins deux applications, ledit temps d'utilisation étant appelé temps processeur, caractérisé en ce qu'il comprend les étapes suivantes : - association (1) à chaque application d'une tranche dudit temps processeur, ladite tranche de temps processeur pouvant être nulle ; - association (2) à chaque application d'une des deux classes suivantes : * une première classe telle que la tranche de temps processeur qui est associée à ladite application est réservée à ladite application même si ladite application ne l'utilise pas entièrement, ladite application ne pouvant pas utiliser plus que la tranche de temps processeur qui lui est associée ; * une seconde classe telle que ladite application est prioritaire pour utiliser le processeur pendant la tranche de temps processeur qui lui est associée, si une partie de la tranche de temps processeur associée à ladite application n'est pas utilisée par ladite application alors ladite partie non utilisée peut être utilisée par une autre application de ladite seconde classe, ladite application pouvant utiliser plus que la tranche temps processeur qui lui est associée en utilisant une partie non utilisée d'une tranche de temps processeur associée à une autre application de ladite seconde classe ou une partie d'une tranche de temps associée à aucune application ; et - gestion (6) dudit temps processeur en fonction des tranches de temps processeur et des classes associées aux applications.

2. Procédé selon la revendication 1, caractérisé en ce que ledit temps processeur est découpé en cycles, chaque cycle comprenant un nombre N d'intervalles de temps, et en 25 ce que la tranche de temps processeur associée à chaque application comprend un nombre K, d'intervalles de temps dans chaque cycle, avec 1 s K, < N, et i un indice relatif à l'application.

3. Procédé selon la revendication 2, caractérisé en ce qu'il comprend l'étape suivante : si, pendant un cycle courant, une application de seconde classe n'a pas utilisé 30 la totalité de la durée de ses K, intervalles de temps du fait qu'elle n'avait pas besoin du processeur pendant X desdits K; intervalles de temps mais requiert finalement 15 20l'utilisation d'un nombre d'intervalles de temps supérieur au nombre Y d' intervalles de temps restants pour ladite application de seconde classe, avec Y = K; ù X, alors modification dynamique du nombre d'intervalles de temps K, pendant au moins un cycle suivant.

4. Procédé selon la revendication 2 ou 3, caractérisé en ce qu'il comprend l'étape suivante : si, pendant un cycle courant, une application de seconde classe n'a pas utilisé la totalité de la durée de ses K, intervalles de temps du fait qu'elle n'avait pas besoin du processeur pendant X desdits K, intervalles de temps mais requiert finalement l'utilisation d'un nombre d'intervalles de temps supérieur au nombre Y d' intervalles de temps restants pour ladite application de seconde classe, avec Y = K, ù X, alors modification dynamique de la durée d'au moins un cycle suivant.

5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce qu'il comprend l'étape suivante, pour au moins une desdites applications : association (3) à ladite application d'un instant de début pour la tranche de temps processeur associée à ladite application, ou d'un instant de début pour chaque intervalle de temps compris dans la tranche de temps processeur associée à ladite application.

6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il comprend l'étape suivante, pour au moins une application de la seconde classe : association à ladite application d'un niveau de priorité, permettant de décider quelle application de la seconde classe peut utiliser le processeur dans le cas où plusieurs applications de la seconde classe sont éligibles pour utiliser le processeur.

7. Procédé selon l'une quelconque des revendications 2 à 6, caractérisé en ce qu'il comprend une étape de vérification (5) que la somme des tranches de temps processeur de toutes les applications est inférieure ou égale à 100% d'un temps processeur application, défini comme la différence entre ledit temps processeur et une partie dudit temps processeur utilisée par ledit système d'exploitation.

8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que ledit système d'exploitation est un système d'exploitation temps réel.

9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que au moins une interruption, dite interruption d'un premier type, n'est associée à aucune desdites applications et n'est pas prise en compte dans la gestion dudit temps processeur.

10. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce que au moins une interruption, dite interruption d'un deuxième type, n'est associée à aucune desdites applications et est prise en compte dans la gestion dudit temps processeur de la façon suivante : une quantité de temps est réservée pour l'ensemble des interruptions du deuxième type, de sorte que la somme des tranches de temps processeur de toutes les applications est inférieure ou égale à 100% dudit temps processeur moins ladite quantité de temps réservée.

11. Procédé selon l'une quelconque des revendications 1 à 10, caractérisé en ce que au moins une interruption, dite interruption d'un troisième type, est associée à au moins une desdites applications et est prise en compte dans la gestion dudit temps processeur de la façon suivante : - une quantité de temps processeur nécessaire à ladite interruption du troisième type est prise en compte dans la tranche de temps processeur de la ou les applications associée(s) à ladite interruption du troisième type ; et - le temps processeur préempté par ladite interruption du troisième type sur au moins une autre application est rétrocédé à ladite au moins une autre application.

12. Procédé selon l'une quelconque des revendications 1 à 11, caractérisé en ce que ledit processeur est compris dans un circuit de radiocommunication, et en ce que lesdits applications comprennent une application de gestion d'une pile de radiocommunication et au moins une application cliente.

13. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé selon au moins une des revendications 1 à 12, lorsque ledit programme est exécuté sur un ordinateur.

14. Moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé selon_au moins une des revendications 1 à 12.

15. Dispositif comprenant un système d'exploitation permettant de gérer un temps d'utilisation d'un unique processeur par au moins deux applications, ledit temps d'utilisation étant appelé temps processeur, caractérisé en ce qu'il comprend : 5 10 15- des moyens d'association à chaque application d'une tranche dudit temps processeur, ladite tranche de temps processeur pouvant être nulle ; - des moyens d'association à chaque application d'une des deux classes suivantes : * une première classe telle que la tranche de temps processeur qui est associée à ladite application est réservée à ladite application même si ladite application ne l'utilise pas entièrement, ladite application ne pouvant pas utiliser plus que la tranche de temps processeur qui lui est associée ; * une seconde classe telle que ladite application est prioritaire pour utiliser le processeur pendant la tranche de temps processeur qui lui est associée, si une partie de la tranche de temps processeur associée à ladite application n'est pas utilisée par ladite application alors ladite partie non utilisée peut être utilisée par une autre application de ladite seconde classe, ladite application pouvant utiliser plus que la tranche temps processeur qui lui est associée en utilisant une partie non utilisée d'une tranche de temps processeur associée à une autre application de ladite seconde classe ou une partie d'une tranche de temps associée à aucune application ; et - des moyens de gestion dudit temps processeur en fonction des tranches de temps processeur et des classes associées aux applications.