FR2956226A1

FR2956226A1 - Procede, programme d'ordinateur et dispositif de supervision d'un ordonnanceur pour la gestion du partage de temps de traitement dans un systeme informatique multitache

Info

Publication number: FR2956226A1
Application number: FR1050932A
Authority: FR
Inventors: Frank Dessertenne; Pierre Guirriec
Original assignee: Airbus Operations SAS
Current assignee: Airbus Operations SAS
Priority date: 2010-02-10
Filing date: 2010-02-10
Publication date: 2011-08-12
Anticipated expiration: 2030-02-10
Also published as: US20110202931A1; CA2731147C; US8527999B2; CA2731147A1; FR2956226B1

Abstract

L'invention a notamment pour objet la supervision d'un ordonnanceur pour la gestion du partage de temps de traitement dans un système informatique multitâche comprenant une unité de calcul ayant un mode d'exécution normal et un mode d'exécution privilégié pour exécuter une pluralité d'applications. Le temps d'exécution de ladite pluralité d'applications est divisé en une pluralité de périodes et un temps d'accès minimal par période à ladite unité de calcul est déterminé pour au moins une application de ladite pluralité d'applications. Pour au moins une période, ledit mode d'exécution privilégié est associé à ladite au moins une application et ladite au moins une application est exécutée selon au moins ledit temps d'accès minimal à ladite unité de calcul. Pour ladite au moins une période, ledit mode d'exécution normale est associé aux applications de ladite pluralité d'applications et au moins l'une quelconque des applications de ladite pluralité d'applications est exécutée.

Description

La présente invention concerne la gestion des ressources d'un système informatique et plus particulièrement un procédé, un programme d'ordinateur et un dispositif de supervision d'un ordonnanceur pour la gestion du partage de temps de traitement, plus particulièrement du temps processeur, dans un système informatique multitâche, notamment dans un système informatique multitâche embarqué dans un aéronef. Les aéronefs modernes comprennent de plus en plus de systèmes électroniques et informatiques pour améliorer leurs performances et assister le pilote ainsi que les membres d'équipage lors de leurs missions. Ainsi, par exemple, les commandes de vol électriques permettent de réduire la complexité mécanique de la transmission des commandes aux actuateurs et donc la masse associée à ces dispositifs de commandes. De même, la présentation d'informations pertinentes permet au pilote d'optimiser les trajectoires de vol et de répondre rapidement à tout incident détecté. De telles informations sont notamment la vitesse, la position, le cap, des données de météorologie et de navigation. Il existe également des systèmes d'information embarqués pour collecter des informations issues de différents éléments de commande et de contrôle d'un aéronef pour permettre d'établir un diagnostic et de faciliter les opérations de maintenance. Ces systèmes comprennent généralement une interface de communication pour échanger ces données de maintenance avec des systèmes au sol. Afin d'améliorer les fonctionnalités des aéronefs, réduire le poids des équipements électroniques grâce à une plus grande intégration, réduire les coûts et faciliter les opérations de maintenance, les systèmes informatiques embarqués intègrent de plus en plus de modules génériques utilisant des systèmes d'exploitation dérivés de systèmes d'exploitation temps réel ou multitâches standard.

Ainsi, les fonctionnalités des systèmes informatiques embarqués des aéronefs utilisent autant que possible des ressources génériques de calcul et d'entrées/sorties dans lesquels elles sont implémentées. Néanmoins, un système de ségrégation ou de partitionnement permet d'isoler chacune des fonctionnalités de telle sorte que la défaillance d'une fonction n'ait pas d'influence sur une autre. De telles ressources de calcul, appelées calculateurs dans la suite de la description, mettent généralement en oeuvre un système d'exploitation multitâche tel que LINUX (LINUX est une marque). Ils permettent ainsi l'exécution d'applications logicielles ayant différents niveaux de criticité. Un niveau de priorité élevé est affecté aux applications les plus critiques afin de tenter de satisfaire leurs contraintes de temps, quel que soit le comportement des applications moins critiques (de tels systèmes ne permettent généralement pas de satisfaire des contraintes de temps réel). Généralement, ces dernières n'ont pas une garantie d'accès minimal à la ressource de calcul (processeur ou CPU, sigle de Central Processing Unit en terminologie anglo-saxonne), qui peut être monopolisée en partie, ou en totalité, par les tâches plus critiques. Plus précisément, le temps processeur est partagé entre les applications logicielles en cours d'exécution par un ordonnanceur qui utilise différents critères pour allouer des tranches d'accès au processeur à chaque application logicielle. Typiquement, un ordonnanceur peut fonctionner selon deux modes d'exécution. Dans un premier mode, correspondant au mode d'utilisation normal, appelé SCHED_OTHER sous LINUX, le temps est réparti selon une priorité dont la valeur est gérée dynamiquement. Il se base sur un critère de priorité et une mesure du temps d'exécution des applications pour mettre en oeuvre une politique d'ordonnancement. Dans un second mode, appelé SCHED_FIFO (acronyme de First ln û First Out en terminologie anglo-saxonne) sous LINUX, l'ordonnanceur alloue tout l'usage du processeur, pour un temps indéterminé, à l'application prête à s'exécuter et de plus haute priorité. Si plusieurs applications de même priorité sont prêtes à s'exécuter, elles sont gérées par ordre chronologique et la première de la liste s'exécute jusqu'à ce qu'elle soit bloquée. Dans ce cas, l'application suivante dans la liste s'exécute. Si une application de plus haute priorité devient prête, l'application en cours d'exécution est préemptée (elle perd l'allocation du processeur) et celle de plus haute priorité s'exécute. L'ordonnanceur garantit qu'une telle application qui a été préemptée reste en tête de liste, pour reprendre son exécution avant les autres dès lors que la plus prioritaire (dans cet exemple) aura rendu la main, c'est-à-dire aura fini de monopoliser le processeur. Cependant, aucun de ces deux modes ne donne entière satisfaction dans un contexte de systèmes d'exploitation multitâches où des applications non contraintes par conception s'exécutent de façon concurrente. En outre, lors de l'exécution d'applications dans un environnement tel que celui présenté précédemment, des pics de charges estimés à 300% de la puissance processeur disponible seraient nécessaires pour garantir un comportement nominal. Dans ce contexte de pics de charge, un comportement dégradé du système est donc attendu. Plusieurs solutions ont été proposées pour répondre à ce problème. Une solution consiste ainsi à modifier le noyau du système d'exploitation pour limiter le temps d'accès au processeur pour chaque application par quota statique, par exemple en pourcentage de temps d'accès au processeur sur une tranche de temps donnée. Cependant, une telle solution conduit à une sous-utilisation du processeur. Une autre solution, proche de la précédente, consiste à limiter le temps d'accès moyen au processeur pour chaque application durant une période prédéterminée selon des valeurs estimées dynamiquement. Elle consiste donc à attribuer un quota dynamique calculé sur une fenêtre glissante dont la moyenne de consommation effective (mesurée) est asservie sur un quota cible configuré. Cependant, cette solution est difficile à paramétrer efficacement et présentent notamment des problèmes de convergence. Il existe donc un besoin pour améliorer la gestion d'accès d'applications à une unité de calcul, notamment pour fiabiliser un système embarqué ayant des contraintes temps réel et mettant en oeuvre un système d'exploitation multitâche.

L'invention permet de résoudre au moins un des problèmes exposés précédemment. L'invention a ainsi pour objet un procédé de supervision d'un ordonnanceur pour la gestion du partage de temps de traitement dans un système informatique multitâche comprenant une unité de calcul ayant un mode d'exécution normal et un mode d'exécution privilégié pour exécuter une pluralité d'applications, ce procédé comprenant les étapes suivantes, - division du temps d'exécution de ladite pluralité d'applications en une pluralité de périodes ; - détermination d'un temps d'accès minimal par période à ladite unité de calcul pour au moins une application de ladite pluralité d'applications ; - pour au moins une période de ladite pluralité de période, o association dudit mode d'exécution privilégié à ladite au moins une application et exécution de ladite au moins une application 15 selon au moins ledit temps d'accès minimal à ladite unité de calcul ; et, o association dudit mode d'exécution normale aux applications de ladite pluralité d'applications et exécution d'au moins l'une quelconque des applications de ladite pluralité d'applications. 20 Le procédé selon l'invention permet ainsi l'exécution d'un ensemble d'applications en garantissant un quota de temps en mode privilégié permettant à au moins une application de disposer d'un minimum de puissance de calcul disponible, sans modifier le noyau du système d'exploitation ni les applications. De façon avantageuse, pour éviter d'induire des effets de bord sur 25 l'exécution des applications et pour répartir au mieux la puissance de calcul entre les processus d'une application, ladite au moins une application comprend au moins deux processus, ladite étape d'association dudit mode d'exécution privilégié à ladite au moins une application comprenant une étape d'association dudit mode d'exécution privilégié à chacun desdits au moins deux 30 processus, le procédé comprenant en outre une étape de modification de l'ordre d'association dudit mode d'exécution privilégié à chacun desdits au moins deux processus de ladite au moins une application, lorsque ledit mode d'exécution privilégié est associé à ladite au moins une application, entre deux périodes de ladite pluralité de périodes. Selon un mode de réalisation particulier, toujours pour éviter d'induire des effets de bord sur l'exécution des applications et pour répartir au mieux la puissance de calcul entre les processus légers d'un processus d'une application, au moins un desdits au moins deux processus comprend au moins deux processus légers, ladite étape d'association dudit mode d'exécution privilégié audit au moins un desdits au moins deux processus comprenant une étape d'association dudit mode d'exécution privilégié à chacun desdits au moins deux processus légers, le procédé comprenant en outre une étape de modification de l'ordre d'association dudit mode d'exécution à chacun desdits au moins deux processus légers, lorsque ledit mode d'exécution privilégié est associé à ladite au moins une application, entre deux périodes de ladite pluralité de périodes.

Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de détermination d'un second temps d'accès minimal par période à ladite unité de calcul pour au moins une seconde application de ladite pluralité d'applications, ledit temps d'accès minimal étant appelé premier temps d'accès minimal et ladite au moins une application étant appelée au moins une première application, et, pour ladite au moins une période, une étape d'association dudit mode d'exécution privilégié à ladite au moins une seconde application et d'exécution de ladite au moins une seconde application selon au moins ledit second temps d'accès minimal à ladite unité de calcul.

Le procédé selon l'invention permet ainsi l'exécution d'un ensemble d'applications en garantissant à chacune un quota de temps en mode privilégié, leur permettant ainsi de disposer d'un minimum de puissance de calcul disponible, sans modifier le noyau du système d'exploitation ni les applications. De façon avantageuse, toujours pour éviter d'induire des effets de bord sur l'exécution des applications, le procédé comprend en outre une étape de modification de l'ordre d'association dudit mode d'exécution privilégié auxdites au moins une première et seconde applications, lorsque ledit mode d'exécution privilégié est associé auxdites au moins une première et seconde applications, entre deux périodes de ladite pluralité de périodes. Selon un mode de réalisation particulier, ledit ordre d'association dudit mode d'exécution privilégié auxdites au moins une première et une seconde applications est déterminé par un index sur une liste comprenant des références auxdites au moins une première et seconde applications, la valeur dudit index étant modifiée à la fin de chacune desdites périodes. Le procédé selon l'invention est ainsi particulièrement simple à mettre en oeuvre. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de détection d'au moins une interruption temporelle périodique, le mode d'exécution d'au moins une application de ladite pluralité d'applications étant déterminé à chaque interruption détectée. L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur, un dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit précédemment ainsi qu'un aéronef comprenant ce dispositif. Les avantages procurés par ce programme d'ordinateur, ce dispositif 20 et cet aéronef sont similaires à ceux évoqués précédemment. D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels : - la figure 1, comprenant les figures la et 1 b, illustre le principe 25 général de l'invention ; - la figure 2, comprenant les figures 2a et 2b, illustre schématiquement une partie de séquence de partage du temps d'accès à une unité de calcul, conformément à l'invention ; - la figure 3 représente une séquence de trois périodes consécutives 30 durant laquelle l'ordre d'exécution des applications dans le mode d'exécution privilégié subit une rotation à chaque période ; - la figure 4 illustre la mise en oeuvre d'un mécanisme de changement de l'ordre des changements de mode d'exécution de tâches lors de l'exécution d'applications similaires à celles présentées en référence à la figure 3; - la figure 5, comprenant les figures 5a et 5b, illustre un exemple d'algorithme pour gérer le partage de temps d'une unité de calcul, conformément à l'invention ; et, - la figure 6 illustre un exemple d'architecture matérielle adaptée à mettre en oeuvre l'invention.

De façon générale, l'invention a pour objet de garantir un temps d'accès minimal par unité de temps (c'est-à-dire un taux minimal) à l'unité de calcul utilisée pour certaines applications exécutées (ou un niveau de puissance de cette unité de calcul), permettant de gérer les priorités élevées de certaines applications sans ignorer les besoins minimaux des autres applications.

A ces fins, une période de traitement algorithmique est construite pour définir des temps d'accès à l'unité de calcul, c'est-à-dire, ici, à un ou plusieurs processeurs. Elle comprend deux parties. Une première partie est allouée à certaines applications dans un mode d'exécution privilégié, c'est-à-dire dans un mode d'exécution particulier de l'ordonnanceur mis en oeuvre dans le système d'exploitation utilisé, par exemple le mode SCHED_FIFO de l'ordonnanceur LINUX, tandis que la seconde partie est allouée aux applications selon le mode normal d'exécution de l'ordonnanceur, par exemple le mode SCHED OTHER de l'ordonnanceur LINUX. La répartition de temps (ou de puissance) entre ces deux parties est déterminée en fonction des besoins des applications exécutées en mode d'exécution privilégié. Elle peut être avantageusement paramétrable, par exemple sous la forme d'un pourcentage de réservation minimum pour chaque application identifiée. Ainsi, une partie du temps (ou de la puissance) de l'unité de calcul est garantie pour chaque application le requérant tandis qu'une autre partie du temps (ou de la puissance) de l'unité de calcul est répartie de façon classique (globalement équirépartie) entre toutes les applications exécutées.

De façon avantageuse, la somme des temps (ou puissances) minimum alloués dans la partie utilisant le mode d'exécution privilégié est inférieure ou égale à 100%. Le temps (ou puissance) non alloué par le système d'exploitation dans ce mode d'exécution privilégié est alors distribué aux applications exécutées dans le mode d'exécution normal. Il est observé que la tâche de gestion de partage du temps est ici toujours exécutée dans le mode d'exécution privilégié, avec le niveau de priorité le plus élevé. La figure 1, comprenant les figures la et 1 b, illustre le principe général de l'invention lorsque l'utilisation des processeurs est proche de cent pourcent. L'axe des ordonnées représente ici la puissance de l'unité de calcul, pouvant être représentée, par exemple, sous forme de pourcentages de temps d'accès pour une période donnée. Comme illustré sur la figure la, le temps d'accès à l'unité de calcul pour une période donnée référencée 100 comprend une première partie 105 durant laquelle le temps d'accès à l'unité de calcul est réparti entre différentes applications afin de garantir un temps d'accès minimum à chacune d'elles. La gestion du temps d'accès à l'unité de calcul est, pour cette première partie 105, réalisée dans un mode d'exécution privilégié (ou mode superviseur) afin d'inhiber le mécanisme d'allocation normal de l'ordonnanceur. Dans cet exemple, le temps minimum alloué à l'application 1 est de 40%, le temps minimum alloué à l'application 2 est de 30% et le temps minimum alloué à l'application 3 est de 30%. Chacune de ces trois applications utilise ici la totalité du temps qui lui est alloué.

La période de temps donnée 100 comprend en outre une seconde partie 110 durant laquelle l'accès à l'unité de calcul est déterminée par un ordonnanceur standard, par exemple en mode SCHED_OTHER. La gestion du temps d'accès à l'unité de calcul est ainsi réalisée dans un mode d'exécution normale.

Dans cet exemple, le temps alloué aux applications 1, 2 et 3 est de 20% pour chacune et le temps alloué à l'application 4 est de 40%.

Il est observé que la répartition entre les modes d'exécution privilégié et normal est ici déterminée selon les besoins des applications exécutées en mode d'exécution privilégié. Dans ce cas précis, la puissance de l'unité de calcul est également répartie entre les parties 105 et 110 (50% chacune).

La figure 1 b illustre un exemple de mise en oeuvre de l'invention lorsqu'une application n'utilise pas tout le temps minimum qui lui est alloué dans le mode d'exécution privilégié (c'est-à-dire lorsque le temps d'accès à l'unité de calcul est réparti entre différentes applications afin de garantir un temps d'accès minimum à chacune d'elles). Le temps CPU non consommé par l'application privilégiée est réparti entre les autres applications. Ainsi, comme illustré et conformément à la mise en oeuvre représentée sur la figure 1 a, le temps d'accès à l'unité de calcul pour une période donnée référencée 100' comprend une première partie 105' durant laquelle le temps d'accès à l'unité de calcul est réparti entre différentes applications afin de garantir un temps d'accès minimum à chacune de ces applications et une seconde partie 110' durant laquelle l'accès à l'unité de calcul est déterminée par un ordonnanceur standard. La puissance de l'unité de calcul est toujours également répartie entre les deux parties (50% chacune). De même, dans la partie 105', le temps minimum alloué à l'application 1 est toujours de 40%, tandis que le temps minimum alloué aux applications 2 et 3 est toujours de 30% pour chacune. Cependant, alors que l'application 1 utilise ici effectivement les 40% qui lui sont réservés, l'application 2 n'utilise que 10% (référence 115). Le temps réservé non utilisé peut alors être utilisé par les autres applications, ici par l'application 3 qui utilise ainsi 50% (référence 120). Dans la partie 110', le temps alloué aux applications 1 et 2 par l'ordonnanceur est de 40% pour chacune et le temps alloué à l'application 4 est de 20%. Selon un mode de réalisation particulier, le temps est divisé en périodes, appelées périodes cpu manager, chacune de ces périodes étant elle- même subdivisée en unités de temps, appelées timeslots, selon des interruptions d'un compteur périodique. Chacune de ces interruptions correspond à un appel à la tâche de gestion du partage de temps de l'unité de calcul. La figure 2, comprenant les figures 2a et 2b, illustre schématiquement une partie de séquence de partage du temps d'accès à une unité de calcul, conformément à l'invention. La figure 2a illustre un tel découpage temporel. Comme représenté, la séquence 200 de partage du temps d'accès à une unité de calcul est découpée en périodes cpu manager 205 qui sont elles-mêmes découpées en timeslots numérotés de 1 à 9 par période. Il convient de noter que si chaque période ne comprend ici que 9 timeslots, c'est simplement dans un souci de clarté et d'illustration, le nombre de timeslots par période étant typiquement compris entre 5 et 100. La figure 2b illustre plus précisément le format d'une période cpu manager 205-i comprenant ici trois parties. La partie 210 correspond à la partie durant laquelle le temps d'accès à l'unité de calcul est réparti entre différentes applications, dans un mode d'exécution privilégié, afin de garantir un temps d'accès minimum à chacune de ces applications. La partie 215 correspond à la partie durant laquelle l'accès à l'unité de calcul est déterminée automatiquement et de façon standard par l'ordonnanceur. Enfin, la partie 220, optionnelle, correspond notamment au contrôle de la gestion du partage de temps de l'unité de calcul. Ainsi, les fenêtres sont gérées à chaque timeslot afin de déterminer s'il faut changer l'application utilisant le mode d'exécution privilégié. Comme décrit ci-après, des listes de processus et de processus légers sont mises à jour en fin de période cpu manager, c'est-à-dire dans le dernier timeslot (qui n'est pas consacré exclusivement à cette tâche). Il convient de noter ici que la mise à jour des listes de processus et processus légers peut être avantageusement opérée toutes les N périodes cpu manager. Enfin, comme décrit ci-après, des rotations sont de préférence effectuées sur les listes d'applications, de processus et de processus légers en fin de période cpu manager, dans le dernier timeslot.

Dans cet exemple, la période cpu manager 205-i indique que, durant la phase d'exécution en mode privilégié, l'unité de calcul devra permettre l'exécution de l'application 1 durant au moins 1 timeslot, puis l'application 2 durant au moins 5 timeslots et enfin l'application 3 durant au moins 4 timeslots.

Comme indiqué précédemment, si une application n'utilise pas tout le temps qui lui est consacré, le temps restant peut être utilisé par une autre application à laquelle un temps minimum d'exécution est associé par ailleurs. Selon un mode de réalisation particulier, la gestion du partage du temps est réalisée en modifiant, si nécessaire, le mode d'exécution associé à chaque application (ou plus précisément à chaque tâche ou processus de chaque application). Lors de chaque interruption de type timeslot, la tâche de gestion de partage du temps détermine si le mode d'exécution privilégié doit être utilisé et, s'il doit l'être, vis-à-vis de quelle application. Le mode d'exécution privilégié est associé à l'application devant être exécutée dans ce mode, le mode d'exécution normal étant associé à toutes les autres applications (à l'exception de la tâche de gestion de partage du temps qui est toujours dans ce mode, avec le niveau de priorité le plus élevé). Ainsi, par exemple, en référence à la figure 2b, lors de l'interruption 0, la tâche de gestion de partage du temps détermine que l'application 1 doit être exécutée en mode d'exécution privilégié. L'application 1 est alors placée en mode SCHED_FIFO (plus précisément, tous les processus constituant cette application et tous les processus légers de chacun de ces processus sont placés en mode SCHED_FIFO). Toutes les autres applications sont placées en mode SCHED_OTHER (plus précisément, tous les processus constituant ces applications et tous les processus légers de chacun de ces processus sont placés en mode SCHED_OTHER). De façon similaire, lors de l'interruption 1, la tâche de gestion de partage du temps détermine que l'application 2 doit être exécutée en mode d'exécution privilégié. Le mode SCHED_FIFO est alors associé à l'application 2 tandis que le mode SCHED_OTHER est associé à toutes les autres applications. En pratique, seule l'application 1 passe, de préférence, du mode SCHED_FIFO au mode SCHED_OTHER, toutes les autres étant déjà en mode SCHED OTHER. Aucune modification de mode n'est apportée aux interruptions 2 à 5. Puis, lors de l'interruption 6, la tâche de gestion de partage du temps détermine que l'application 3 doit être exécutée en mode d'exécution privilégié. Le mode SCHED_FIFO est alors associé à l'application 3 tandis que le mode SCHED_OTHER est associé à toutes les autres applications, en particulier à l'application 2 qui était précédemment dans le mode SCHED_FIFO. A nouveau, en pratique, seule l'application 2 passe, de préférence, du mode SCHED_FIFO au mode SCHED_OTHER, toutes les autres étant déjà en mode SCHED OTHER. Aucune modification de mode n'est apportée aux interruptions 7 à 9. Il est observé ici que, dans une fenêtre d'exécution privilégiée, une application reste en mode d'exécution privilégié, qu'elle consomme ou non les ressources du ou des processeurs mises à sa disposition. Ainsi, si elle souhaite consommer ces ressources, elle est prioritaire durant cette fenêtre. Si elle effectue, par exemple, des opérations d'entrée/sortie, elle rend temporairement la main sur le ou les processeurs du fait des appels systèmes impliqués. Pendant ces opérations d'entrée/sortie, une autre application moins prioritaire peut donc accéder aux ressources du ou des processeurs. Cependant, cette seconde est préemptée en fin de l'opération d'entrée/sortie par la précédente qui reprend alors le cours de son traitement. Il en est de même si une application exécutée dans le mode d'exécution privilégié rend temporairement la main du fait, par exemple, d'un appel système de type Sleep(durée).

Lors de l'interruption 10, la tâche de gestion de partage du temps détermine que le temps d'exécution en mode privilégié est terminé. Le mode SCHED OTHER est alors associé à toutes les applications. Pour ne pas induire d'effets de bord sur l'exécution des applications, l'ordre d'entrée des applications dans le mode d'exécution privilégié est, de préférence, changé à chaque période cpu manager. En effet, il a été observé que l'ordre d'entrée des applications dans le mode d'exécution privilégié influence leur exécution dans le mode d'exécution normal.

Ainsi, une rotation de l'ordre d'entrée des applications dans le mode d'exécution privilégié est avantageusement effectuée à chaque période cpu manager. A titre d'illustration, la figure 3 représente une séquence de trois périodes cpu manager consécutives durant laquelle l'ordre d'exécution des applications dans le mode d'exécution privilégié subit une rotation à chaque période. Comme illustré, l'ordre d'exécution des applications 1, 2 et 3 est modifié entre chacun des cycles. A ces fins, un mécanisme de gestion de liste est ici utilisé. Toutes les applications devant être exécutées dans le mode d'exécution privilégié sont mémorisées dans une liste qui comprend un index désignant la première application à exécuter lorsque le mode d'exécution passe du mode d'exécution normal au mode privilégié. Cet index est incrémenté (modulo le nombre d'applications présentes dans la liste) à chaque fin de période. La table 1 donnée en annexe illustre une telle liste comprenant l'ensemble des applications devant être exécutées en mode d'exécution privilégié. Comme illustré, un index, incrémenté à la fin de chaque période cpu manager, désigne la première application devant être exécutée lorsque le mode d'exécution privilégié est mis en oeuvre, ici l'application 2. La référence de l'index à utiliser pour une période donnée est ici déterminée dans le dernier timeslot de la période cpu manager précédente réservé à la mise à jour des listes. A titre d'illustration, la première application à exécuter lorsque le mode d'exécution privilégié est mis en oeuvre dans le cycle i+1 est déterminée durant la période définie par l'indication 220 du cycle i. De façon avantageuse, un mécanisme similaire est mis en oeuvre pour chaque processus de chaque application exécutée dans le mode d'exécution privilégié. Comme indiqué précédemment, le mode d'exécution d'un processus est identique à celui de l'application à laquelle il appartient (le mode d'exécution d'une application étant défini par celui de ses processus). Une liste des processus est établie pour chaque application. Elles sont par exemple obtenues à l'aide de la commande appropriée du système d'exploitation.

Chacune de ces listes comprend un index désignant le premier processus devant être exécuté lorsque l'application à laquelle il appartient est exécutée dans le mode d'exécution privilégié. Comme pour la liste d'applications, l'index de démarrage de chaque liste de processus est incrémenté à la fin de chaque période cpu manager. La table 2 donnée en annexe illustre de telles listes comprenant l'ensemble des processus de chaque application devant être exécutée en mode d'exécution privilégié. Comme illustrée, un index, incrémenté à la fin de chaque période, désigne le premier processus devant être exécuté lorsque le mode d'exécution privilégié est mis en oeuvre, pour chaque application. La figure 4 illustre la mise en oeuvre de ce mécanisme lors de l'exécution d'applications similaires à celles présentées en référence à la figure 3. Comme représenté, l'ordre d'entrée dans un mode d'exécution (normal ou privilégié) des processus appelés Ti et T2 est modifié entre chaque période cpu manager. En ce qui concerne l'ordre des applications, l'index du premier processus à exécuter, pour chaque application exécutée dans le mode d'exécution privilégié, est de préférence déterminé durant le dernier timeslot de la période cpu manager précédente.

De façon similaire, les processus peuvent être divisés en sous tâches, aussi appelées processus légers ou threads en terminologie anglo-saxonne, l'ordre d'entrée de ceux-ci dans un mode d'exécution (normal ou privilégié) étant alors avantageusement permutés à chaque période. Cependant, pour un processus donné, le nombre de processus légers étant potentiellement élevé, l'ordre des processus légers est, de préférence, géré par des listes dont l'ordre varie de façon aléatoire. La figure 5, comprenant les figures 5a et 5b, illustre un exemple d'algorithme pour gérer le partage de temps d'une unité de calcul, conformément à l'invention. La figure 5a illustre la phase d'initialisation tandis que la figure 5b illustre la phase de gestion du partage de temps de l'unité de calcul.

Comme illustré sur la figure 5a, une première étape a pour objet de lire la configuration du système (étape 500) afin d'obtenir, en particulier, la période cpu manager T, la liste des applications devant être contrôlées, c'est-à-dire la liste des applications auxquelles est associée une valeur minimale de puissance de l'unité de calcul, et la valeur minimale de puissance (Pi) de l'unité de calcul devant être attribuée à chaque application (i), exprimée en pourcentage. La lecture de la configuration peut également viser des paramètres liés à la rotation des applications, de leurs processus et de leurs processus légers. Il s'agit, par exemple, d'un indicateur ayant une signification prédéfinie. A titre d'illustration, la valeur zéro d'un tel indicateur peut signifier qu'aucune rotation ne doit être effectuée, la valeur 1 peut signifier que seule une rotation sur les applications doit être effectuée, la valeur 2 peut signifier que seule une rotation sur les applications et les processus doit être effectuée et la valeur 3 peut signifier qu'une rotation doit être effectuée sur les applications, les processus et les processus légers. Durant la lecture de la configuration, un test est de préférence effectué pour vérifier que la somme des valeurs minimales de puissance de l'unité de calcul requises n'excède pas 100%, c'est-à-dire pour vérifier la relation suivante, 1Pi100 Le temps minimal Ti devant être alloué par période à chaque application (i) est déterminé en fonction de la période cpu manager T et la valeur minimale de puissance (Pi) de l'unité de calcul devant être attribuée à chaque application (i), de la façon suivante, Ti= Pa •T 100 pour permettre de placer chaque application i en mode d'exécution privilégié dans chaque période cpu manager pendant <ni> timeslots (T =< nl > x < timeslot > où <timeslot> représente la largeur temporelle du timeslot).

Alternativement, la valeur minimale de puissance (P'i) de l'unité de calcul devant être attribuée à chaque application peut être définie de façon relative en fonction d'un ratio (R) exprimé entre la période d'exécution en mode d'exécution privilégié et la période d'exécution en mode d'exécution non privilégié. Le temps minimal Ti devant être alloué à chaque application (i) est alors déterminé de la façon suivante,

Ti= Pi •R•T 1P'i

La taille du timeslot devant être utilisé, c'est-à-dire la fréquence d'appel de la tâche de gestion de partage du temps de l'unité de calcul, est calculée dans une étape suivante (étape 505) selon les données de configuration.

Selon un mode de réalisation particulier, le timeslot est estimé selon le plus petit multiple commun (en termes de temps minimal d'exécution requis) entre les pourcentages minimum configurés par application.

La tâche de gestion du partage de temps est placée dans le mode d'exécution privilégié, avec le niveau de priorité le plus élevé.

La liste des processus est établie pour chacune des applications contrôlées. De façon similaire, la liste des processus légers est établie pour chacun des processus et chacune des applications contrôlées. Ces listes peuvent notamment être établies à l'aide de la commande 'ps ûeL' sous LINUX.

Le compteur d'interruption est ensuite lancé (étape 510) pour permettre de gérer le partage de temps de l'unité de calcul conformément à l'algorithme illustré à la figure 5b. Le processus décrit en référence à cette figure s'exécute ici tant qu'une interruption particulière n'est pas détectée.

Tous les processus et les processus légers sont placés dans le mode d'exécution SCHED OTHER à l'exception des processus et des processus légers correspondant à la première application à exécuter dans le mode d'exécution privilégié qui sont placés dans le mode d'exécution SCHED FIFO.

Lorsqu'une interruption est détectée (étape 515), un test est effectué pour en déterminer le type (étape 520). Si l'interruption est d'un type spécifique, le procédé prend fin. Si, au contraire, l'interruption est du type timeslot, un test est effectué pour déterminer si l'interruption correspond à la fin de la fenêtre d'exécution privilégiée de l'application courante (étape 525). Dans la négative, l'algorithme se poursuit à l'étape 545 décrite ci-dessous. Si, au contraire, l'interruption correspond à la fin de la fenêtre d'exécution privilégiée de l'application courante, le mode d'exécution de l'application courante est changé. L'application courante est placée en mode d'exécution normal, ici en mode SCHED_OTHER (étape 530). Comme indiqué précédemment, placer une application dans un mode particulier consiste à placer chacun de ses processus et chacun de ses processus légers dans ce mode d'exécution. Ainsi, tous les processus et les processus légers de l'application courante sont placés en mode SCHED_OTHER. Un test est ensuite effectué pour déterminer si l'interruption correspond au début d'une fenêtre d'exécution privilégiée d'une autre application (étape 535). Dans la négative, l'algorithme se poursuit à l'étape 545 décrite ci-dessous.

Si, au contraire, l'interruption correspond au début d'une fenêtre d'exécution privilégiée d'une autre application, le mode d'exécution de l'application suivant l'application courante dans la liste des applications devant être exécutées en mode d'exécution privilégié est changé pour passer en mode d'exécution privilégié. Cette application devient l'application courante.

L'application courante est ainsi placée en mode SCHED_FIFO (étape 540). Plus précisément, tous les processus et les processus légers correspondant à l'application courante sont placés en mode SCHED_FIFO, les uns après les autres (dans un intervalle de temps aussi bref que possible) selon l'ordre défini dans les listes des processus et des processus légers, à partir des index. Les processus et les processus légers sont ainsi traités par ordre d'entrée dans la FIFO pour leur affecter / retirer le mode d'exécution privilégié.

Un test est ensuite effectué pour déterminer si l'interruption correspond à la dernière fenêtre temporelle de traitement (dernier timeslot) de la période cpu manager en cours (étape 545). Comme indiqué précédemment, cette étape est également effectuée si l'interruption ne correspond pas à la fin de la fenêtre d'exécution privilégiée de l'application courante (étape 525) ou si l'interruption ne correspond pas au début d'une fenêtre d'exécution privilégiée d'une autre application (étape 535). Si l'interruption ne correspond pas à la dernière de la période cpu manager en cours, les étapes précédentes (étapes 515 à 545) sont répétées pour traiter la période cpu manager suivante ou mettre fin à l'algorithme. Si, au contraire, l'interruption correspond à la dernière de la période cpu manager en cours, les listes des applications, des processus et des processus légers sont mises à jour et une rotation est effectuée (étape 550).

Comme indiqué précédemment, les rotations effectuées sur les listes des applications, des processus et des processus légers peuvent consister à incrémenter des index. Ces rotations sont effectuées ou non selon des paramètres prédéterminés liés au choix de l'utilisateur. Plus précisément, au cours de cette étape, une rotation est, si nécessaire, effectuée dans la liste des applications, puis les listes des processus et des processus légers sont, le cas échéant, mises à jour, pour toutes les applications, en fonction des processus et des processus légers de chacune d'elles. Une rotation est alors, si nécessaire, effectuée dans la liste des processus et une rotation (de préférence aléatoire) est, si nécessaire, effectuée dans la liste des processus légers. Les étapes précédentes (étapes 515 à 550) sont ensuite répétées pour traiter la période cpu manager suivante ou mettre fin à l'algorithme. La figure 6 illustre un exemple d'architecture matérielle adaptée à la mise en oeuvre de l'invention. Le dispositif 600, de type calculateur embarqué pour aéronef, comporte ici un bus de communication 605 auquel sont reliés : - une unité centrale de traitement ou microprocesseur 610 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - une horloge temps réel pour générer des interruptions (non représentée) ; - une mémoire morte 615 (ROM, acronyme de Read Only Memory en terminologie anglo-saxonne) pouvant comporter les programmes nécessaires à la mise en oeuvre de l'invention ; - une mémoire vive ou mémoire cache 620 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à l'enregistrement de variables et paramètres créés et modifiés au cours de l'exécution des programmes précités ; et - une interface de communication 650 adaptée à la transmission et à la réception de données. Le dispositif 600 dispose également, de préférence, des éléments suivants : - un écran 625 pouvant servir d'interface graphique avec l'utilisateur qui pourra interagir avec les programmes, à l'aide d'un clavier et d'une souris 630 ou d'un autre dispositif de pointage tel qu'un écran tactile ou une télécommande ; - un disque dur 635 pouvant comporter les programmes précités et des données traitées ou à traiter selon l'invention ; et - un lecteur de cartes mémoires 640 adapté à recevoir une carte mémoire 645 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention. Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 600 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du dispositif 600 directement ou par l'intermédiaire d'un autre élément du dispositif 600. Le code exécutable de chaque programme permettant au dispositif programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 635 ou en mémoire morte 615.

Selon une variante, la carte mémoire 645 peut contenir des données, notamment une table de correspondance entre les événements détectés et les commandes pouvant être sollicitées, ainsi que le code exécutable des programmes précités qui, une fois lu par le dispositif 600, est stocké dans le disque dur 635. Selon une autre variante, le code exécutable des programmes pourra être reçu, au moins partiellement, par l'intermédiaire de l'interface de communication 650, pour être stocké de façon identique à celle décrite précédemment.

De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage du dispositif 600 avant d'être exécutés. L'unité centrale 610 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 635 ou dans la mémoire morte 615 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 635 ou la mémoire morte 615, sont transférés dans la mémoire vive 620 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente.

ANNEXE Appli.

1 Appli.

2 Appli.

3 Appli. n Table 1 Table 2Appli.

1 Appli.2 -> Appli. n -> Processus 1 Processus 2 Processus i Processus 1 Processus 2 Processus j Processus 1 Processus k

Claims

REVENDICATIONS1. Procédé de supervision d'un ordonnanceur pour la gestion du partage de temps de traitement dans un système informatique multitâche comprenant une unité de calcul ayant un mode d'exécution normal et un mode d'exécution privilégié pour exécuter une pluralité d'applications, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - division du temps d'exécution de ladite pluralité d'applications en une pluralité de périodes (205) ; - détermination (500) d'un temps d'accès minimal par période à ladite unité de calcul pour au moins une application de ladite pluralité d'applications ; - pour au moins une période de ladite pluralité de périodes, o association (540) dudit mode d'exécution privilégié à ladite au moins une application et exécution de ladite au moins une application selon au moins ledit temps d'accès minimal à ladite unité de calcul ; et, o association (530) dudit mode d'exécution normale aux applications de ladite pluralité d'applications et exécution d'au moins l'une quelconque des applications de ladite pluralité d'applications.
2. Procédé selon la revendication précédente selon lequel ladite au moins une application comprend au moins deux processus, ladite étape d'association dudit mode d'exécution privilégié à ladite au moins une application comprenant une étape d'association dudit mode d'exécution privilégié à chacun desdits au moins deux processus, le procédé comprenant en outre une étape de modification de l'ordre d'association dudit mode d'exécution privilégié à chacun desdits au moins deux processus de ladite au moins une application, lorsque ledit mode d'exécution privilégié est associé à ladite au moins une application, entre deux périodes de ladite pluralité de périodes.
3. Procédé selon la revendication précédente selon lequel au moins un desdits au moins deux processus comprend au moins deux processus légers, ladite étape d'association dudit mode d'exécution privilégié audit au moins un desdits au moins deux processus comprenant une étape d'association dudit mode d'exécution privilégié à chacun desdits au moins deux processus légers, le procédé comprenant en outre une étape de modification de l'ordre d'association dudit mode d'exécution à chacun desdits au moins deux processus légers, lorsque ledit mode d'exécution privilégié est associé à ladite au moins une application, entre deux périodes de ladite pluralité de périodes.
4. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de détermination d'un second temps d'accès minimal par période à ladite unité de calcul pour au moins une seconde application de ladite pluralité d'applications, ledit temps d'accès minimal étant appelé premier temps d'accès minimal et ladite au moins une application étant appelée au moins une première application, et, pour ladite au moins une période, une étape d'association dudit mode d'exécution privilégié à ladite au moins une seconde application et d'exécution de ladite au moins une seconde application selon au moins ledit second temps d'accès minimal à ladite unité de calcul.
5. Procédé selon la revendication précédente comprenant en outre une étape de modification de l'ordre d'association dudit mode d'exécution privilégié auxdites au moins une première et seconde applications, lorsque ledit mode d'exécution privilégié est associé auxdites au moins une première et seconde applications, entre deux périodes de ladite pluralité de périodes.
6. Procédé selon la revendication précédente selon lequel ledit ordre d'association dudit mode d'exécution privilégié auxdites au moins une première et seconde applications est déterminé par un index sur une liste comprenant des références auxdites au moins une première et seconde applications, la valeur dudit index étant modifiée à la fin de chacune desdites périodes.
7. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de détection d'au moins une interruptiontemporelle périodique, le mode d'exécution d'au moins une application de ladite pluralité d'applications étant déterminé à chaque interruption détectée.
8. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédentes lorsque ledit programme est exécuté sur un ordinateur.
9. Dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 7.
10. Aéronef comprenant le dispositif selon la revendication précédente.