FR2997774A1 - Procede, dispositif et programme d'ordinateur de placement de taches dans un systeme multi-cœurs - Google Patents

Abstract

L'invention a notamment pour objet le placement de tâches dans un système multi-cœurs, des contraintes de temps étant associées à chaque tâche. Après avoir affecté (205) au moins une tâche distincte à chaque cœur, une tâche non affectée est sélectionnée (220). Un cœur susceptible d'exécuter la tâche sélectionnée selon des contraintes de temps associées à cette tâche et des contraintes de temps associées à des tâches préalablement affectées à ce cœur est alors identifié (225). La tâche sélectionnée est ensuite affectée (235) au cœur identifié.

Description

La présente invention concerne la gestion de processus dans les systèmes d'information et plus particulièrement un procédé, un dispositif et un programme d'ordinateur de placement de tâches dans un système multi-coeurs, permettant notamment de certifier le comportement d'une application multitâche et temps réel en calculant le placement de ses tâches sur une machine multi- coeurs en fonction de contraintes de temps réel de chacune des tâches. Un problème important rencontré lors du développement d'applications logicielles multitâches et temps réel est relatif à la garantie du fait que toutes les tâches de cette application puissent s'exécuter en respectant des contraintes de temps. En particulier, des interruptions affectant une tâche ne doivent pas empêcher cette dernière de s'exécuter dans un délai imparti. Il est rappelé ici qu'un système est dit temps réel lorsqu'il est capable de réagir de façon fiable et répétée selon des délais d'exécution prédéterminés. A ces fins, une tâche exécutée par ce système doit s'exécuter en fonction d'autres tâches exécutées par celui-ci selon des contraintes de temps prédéterminées. Le principe général du temps réel consiste à contrôler quelle partie du programme intervient à chaque instant, sans laisser de place à l'aléatoire. Lorsque le système de traitement de l'information utilisé est un système multi-coeurs, c'est-à-dire un système comprenant plusieurs unités de traitement, le placement des tâches sur chaque coeur est particulièrement important pour le comportement temps réel de l'application considérée. Une solution couramment utilisée aujourd'hui pour optimiser le comportement d'une application multitâche et temps réel vis-à-vis de cette dernière caractéristique consiste à affecter, à chaque tâche, de façon empirique, une priorité de placement d'autant plus élevée que le temps de réponse associé à la tâche considérée est petit afin d'influencer le placement (automatique) de la tâche. En effet, un séquenceur temps réel de tâches, appelé scheduler en terminologie anglo-saxonne, ordonne et place les tâches d'une application en partant du principe qu'à un instant donné, les n coeurs d'un système de traitement doivent exécuter les n tâches les plus prioritaires. Dans ce contexte, une garantie liée au comportement temps réel effectif de l'application peut être obtenue en effectuant une simulation de ce comportement à partir de scénarii d'exécution de l'application. Cependant, une telle approche a ses limites car les scénarii utilisés doivent décrire de façon fidèle le comportement de l'application, ce qui peut être difficile à démontrer. Ainsi, à titre d'illustration, plusieurs tâches ayant chacune une forte priorité peuvent empêcher une tâche de moindre priorité de respecter sa propre contrainte de temps d'exécution et, par conséquent, empêcher un fonctionnement normal de l'application. Pour contenir un tel risque, une solution couramment utilisée consiste à sur-dimensionner le système, notamment au niveau de sa puissance de calcul et/ou du nombre de coeurs mis en oeuvre. Cependant, l'inconvénient majeur d'une telle approche est lié à son coût, sans que le surcoût ne garantisse le comportement temps réel de l'application. Il existe donc un besoin pour améliorer le placement de tâches d'une application multitâche et temps réel dans un système multi-coeurs.

L'invention a ainsi pour objet un procédé pour ordinateur de placement d'une pluralité de tâches dans un système comprenant une pluralité de coeurs, avant l'exécution de chacune desdites tâches, des contraintes de temps étant associées à chaque tâche de ladite pluralité de tâches, ce procédé comprenant les étapes suivantes : - affectation d'au moins une tâche distincte de ladite pluralité de tâches à chaque coeur de ladite pluralité de coeurs ; - sélection d'une tâche non affectée de ladite pluralité de tâches ; - identification d'un coeur de ladite pluralité de coeurs susceptible d'exécuter ladite tâche sélectionnée selon des contraintes de temps associées à ladite tâche sélectionnée et des contraintes de temps associées à des tâches préalablement affectées audit coeur identifié ; et - affectation de ladite tâche sélectionnée audit coeur identifié.

Le procédé selon l'invention permet ainsi d'affecter des tâches à des coeurs selon des contraintes de temps, notamment des tâches d'applications multitâches et temps réel. Selon un mode de réalisation particulier, lesdites étapes de sélection d'une tâche, d'identification d'un coeur et d'affectation d'une tâche sélectionnée à un coeur identifié sont répétées pour affecter un ensemble de tâches de ladite pluralité de tâches à au moins un coeur de ladite pluralité de coeurs. Le procédé selon l'invention peut ainsi affecter automatiquement un ensemble de tâches à un ensemble de coeurs selon des contraintes de temps.

Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape d'assignation d'une priorité à chaque tâche affectée à un coeur, ladite priorité étant déterminée en fonction de l'ordre d'assignation des tâches audit coeur. Le procédé selon l'invention peut ainsi contrôler le respect de contraintes de temps.

Lesdites contraintes de temps comprennent, par exemple, au moins un pire temps d'exécution de la tâche associée, un temps de réponse imparti à la tâche associée et une période d'exécution de la tâche associée. Selon un mode de réalisation particulier, le procédé comprend en outre une étape préalable d'ordonnancement des tâches de ladite pluralité de tâches selon au moins une contrainte de temps. Le procédé selon l'invention peut ainsi contrôler le respect de contraintes de temps. Toujours selon un mode de réalisation particulier, ledit ordonnancement est effectué selon une période d'exécution de la tâche associée.

Toujours selon un mode de réalisation particulier, ladite étape d'identification d'un coeur comprend les étapes suivantes : - sélection d'un coeur de ladite pluralité de coeurs ; - évaluation de la capacité dudit coeur sélectionné à exécuter ladite tâche sélectionnée selon des contraintes de temps associées à ladite tâche sélectionnée et les contraintes de temps associées aux tâches préalablement affectées audit coeur sélectionné ; et - si ledit coeur sélectionné n'est pas capable d'exécuter ladite tâche sélectionnée selon des contraintes de temps associées à ladite tâche sélectionnée et des contraintes de temps associées aux tâches préalablement affectées audit coeur sélectionné, répétition des étapes de sélection d'un coeur et d'évaluation. Le procédé selon l'invention permet ainsi de sélectionner des coeurs auxquels doivent être affectées des tâches, selon des contraintes de temps. Ladite pluralité de coeurs forme par exemple une liste ordonnée de coeurs, un coeur étant sélectionné de façon incrémentale dans ladite liste ordonnée de coeurs. 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 ainsi qu'un dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit précédemment. Les avantages procurés par ce programme d'ordinateur et ce dispositif 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, 20 au regard des dessins annexés dans lesquels : - la figure 1 illustre une représentation du temps d'exécution d'une tâche, de son pire temps d'exécution, du temps de réponse imparti à cette tâche et de sa période ; - la figure 2 illustre un exemple d'algorithme de placement de 25 tâches d'une application multitâche et temps réel exécutée dans un système multi-coeurs, conformément à un mode de réalisation de l'invention ; - la figure 3 illustre un exemple de placement de trois tâches sur un coeur, conformément à l'algorithme décrit en référence à la figure 2 ; et - la figure 4 illustre un exemple d'architecture matérielle adaptée à 30 mettre en oeuvre certaines étapes du procédé selon un mode de réalisation de l'invention.

De façon générale, l'invention a pour objet le placement de tâches dans un système multi-coeurs, permettant notamment de certifier le comportement d'une application multitâche et temps réel en calculant le placement de ses tâches sur une machine multi-coeurs en fonction de contraintes de temps de chacune des tâches. Un tel placement est ici effectué avant l'exécution des tâches, de façon prédéterminée. En d'autres termes, le placement des tâches sur des coeurs est statique. De telles contraintes de temps peuvent notamment être exprimées par les paramètres suivants, pour chaque tâche de l'application visée : - le pire temps d'exécution de la tâche, aussi appelé WCET (sigle de Worst Case Execution Time en terminologie anglo-saxonne) ; - le temps de réponse imparti à la tâche, aussi appelé deadline et noté DL, qui doit être respecté chaque fois que la tâche est exécutée ; et - la période d'exécution de la tâche, ou intervalle de temps minimum entre deux exécutions consécutives de la tâche, aussi nommée période pour une tâche réellement périodique ou pseudo-période si seul l'intervalle de temps minimum entre deux exécutions consécutives de la tâche est considéré.

La période est une valeur héritée du domaine fonctionnel, elle correspond à un besoin applicatif, par exemple une fréquence d'échantillonnage sur un capteur. La pseudo-période exprime, elle aussi, un besoin fonctionnel. Cependant, elle correspond à un intervalle de temps minimum entre deux exécutions consécutives de la tâche. Une pseudo-période est ici assimilée à une période, ces deux notions étant gérées de façon identique dans un mode de réalisation particulier de l'invention. Les tâches non périodiques ont une période fixée ici à zéro. Le pire temps d'exécution d'une tâche (WCET) correspond au temps d'exécution, au pire, de la tâche, quel que soit le traitement qu'elle doit effectuer et en considérant qu'elle n'est pas interrompue. Ce temps dépend notamment de la puissance de calcul du coeur exécutant cette tâche ainsi que de la nature et la quantité de données traitées par la tâche.

Le pire temps d'exécution d'une tâche peut-être obtenue, de façon empirique, en exécutant la tâche avec le jeu de données produisant la plus longue durée de traitement et en mesurant le temps de traitement. Cette mesure peut être effectuée par mesure directe ou à l'aide d'un simulateur ou d'un émulateur. La valeur de ce paramètre est, de préférence, fournie par le concepteur ou le développeur de l'application ou de la tâche. Elle peut également être obtenue, pour un système de traitement de données particulier, par extrapolation, par exemple par extrapolation linéaire, à partir d'une valeur de référence connue liée à un autre système de traitement de données particulier. Le temps de réponse imparti à une tâche (deadline), pour effectuer un traitement, correspond également à un besoin applicatif. Il s'agit typiquement d'une contrainte forte qui, si elle n'est pas respectée, peut compromettre le bon fonctionnement de l'application temps réel visée. Il est typiquement défini par l'instant auquel une autre tâche a besoin d'un résultat produit par la tâche considérée. La figure 1 illustre un exemple de représentation du temps d'exécution d'une tâche 7-1, de son pire temps d'exécution, noté WCET(Ti), du temps de réponse imparti à cette tâche, noté DL(Ti), et de sa période, notée 20 «T1). La tâche 7-1, mise en oeuvre par un coeur donné, est ici exécutée de façon périodique au temps to, puis au temps t1 suivant le temps to, après une durée «T1). S(T1) définit ainsi la période d'exécution de la tâche 7-1 (ti = t0 + (5'(7-/)). La nIème exécution de la tâche 7-1 se produit au temps t,1 (t_ = to + (n - 25 1). (5'(7-/)). Comme représenté, si le pire temps d'exécution de la tâche T1 (WCET(Ti)), ainsi que le temps de réponse imparti de cette tâche (DL(Ti)) sont constants, le temps d'exécution réel de la tâche, noté EXEC(Ti), ne l'est pas car il dépend de plusieurs facteurs, notamment, par exemple, des données à 30 traiter. Ainsi, en d'autres termes, si les variables t'1, t", et t'", sont définies de la façon suivante : t',= t1+ EXEC(Td t", = t, + WC ET (Td t"1 = t1+ DL(T1) alors (t", - t,) = (t", - ti) et (t"1- t,) = (t"'l - ti) mais (t',- t,) = (t - ti) ou (t',- t,) (ri - ti) où les indices i et j représentent des indices sur des cycles d'exécution. Selon un mode de réalisation particulier de l'invention, d'autres paramètres supplémentaires, non temporels et optionnels, peuvent être utilisés pour le placement de tâches dans un système mufti-coeurs. Ainsi, par exemple il est possible de prendre en compte l'ordre exécution de tâches et l'appel d'une tâche par une autre. Il est observé ici que l'ordre d'exécution de tâches permet notamment de simplifier le calcul de placement si, du point de vue applicatif, des tâches de même période s'enchaînent. Dans ce cas, l'exécution de la n'ème tâche à exécuter est lancée suite à une durée égale à la somme des temps de réponse impartis à chacune des (n - 1) tâches précédentes. La somme des temps de réponse impartis aux tâches qui s'enchaînent doit être inférieure à la période commune de ces tâches. Un appel de tâches consiste, pour une tâche donnée, à appeler une autre tâche, de façon explicite, et à en attendre un résultat. Un tel appel peut être bloquant ou non. Dans le cas d'un appel non bloquant, seule une resynchronisation explicite de tâches est effectuée. Qu'ils soient bloquants ou non, il convient de vérifier que les conditions suivantes sont vérifiées : WCET( Tappelante) DL(Tappeiée) < DL(Tappelante) où, à nouveau, WCET(Tappelante) représente le pire temps d'exécution de la tâche appelante et DL(Tappeiée) et DL(Tappelante) représentent les temps de réponse impartis aux tâches appelées et appelantes, respectivement. Il est observé que, dans ce cas, la tâche appelée n'est pas traitée comme périodique car elle est explicitement déclenchée par la tâche appelante.

Conformément à un mode de réalisation particulier de l'invention, des tâches dont les paramètres temporels sont compatibles entre eux sont placés sur un même coeur. En d'autres termes, toutes les tâches placées sur un même coeur peuvent s'exécuter entièrement dans le respect de leur temps de réponse, quelles que soient les tâches qui viennent les interrompre. Ainsi, de façon générale, l'invention a notamment pour objet, selon un mode de réalisation particulier, de calculer formellement, en fonction de leurs caractéristiques temps réel, quelles tâches d'une application peuvent cohabiter au sein d'un même coeur d'un système multi-coeurs donné. A ces fins, il est admis que les coeurs dédiés à l'exécution de tâches de l'application considérée sont exempts de perturbations. Ainsi, tous les processus non applicatifs tels que des processus du système d'exploitation utilisé ainsi que des processus de traitement des interruptions sont avantageusement migrés sur d'autres coeurs dédiés, notamment, à l'exécution du système d'exploitation du système multi-coeurs. Par ailleurs, il convient de prendre en compte le temps nécessaire au système d'exploitation utilisé pour commuter de l'exécution d'une tâche à celle d'une autre. À ces fins, un temps de commutation prenant en compte un surcoût de temps ajouté par la plate-forme matérielle utilisée est ajouté au temps d'exécution de chaque tâche. Un tel temps de commutation peut être mesuré ou estimé. Dans ce dernier cas, il convient d'effectuer une majoration raisonnable.

Pour permettre le placement, les tâches sont ici triées en fonction de leurs caractéristiques, notamment en fonction de leur période ou pseudopériode d'exécution, de leur pire temps d'exécution (WCET) et/ou du temps de réponse qui leur est imparti (deadline). Leur tri peut également être basé, de façon optionnelle, sur l'ordre d'exécution des tâches et des appels entre tâches.

La figure 2 illustre un exemple d'algorithme de placement de tâches Tk d'une application multitâche et temps réel devant être exécutée dans un système multi-coeurs, comprenant ici n coeurs, conformément à un mode de réalisation de l'invention. Selon cet exemple, il convient de placer m tâches sur n coeurs.

Une première étape (étape 200) a pour objet de trier les m tâches Tk (k variant de 1 à m). Ce tri est ici effectué par période décroissante (selon la période associée à chaque tâche), puis pour des tâches ayant des périodes identiques, par pire temps de réponse décroissant et, pour des tâches ayant des périodes et des pires temps de réponse identiques, par temps de réponse imparti décroissant. Ainsi, par exemple, une tâche T, est placée avant une tâche Ti si S(T1) 5 > g(T) ou, s i S(T1) = S(T), si DL(Td > DL(T). Au cours d'une étape suivante (étape 205), les n premières tâches Tk (k = 1 à n) sont placées sur les n coeurs du système mufti-coeurs mettant en oeuvre l'application considérée. Chacune de ces n premières tâches est placée sur un coeur distinct. Ainsi, en considérant que les coeurs sont notés Cp (p = 1 à 10 n), la tâche Tk est placée sur le coeur Cp, k et p variant simultanément de 1 à n. La valeur d'un index p, représentant un index sur les coeurs du système (variant de 1 à n), est alors mise à un et celle de l'index k à la valeur n + 1. Un test est ensuite effectué (étape 210) pour déterminer s'il existe au 15 moins une tâche de la liste des tâches ordonnées qui n'a pas été placée sur un coeur, c'est-à-dire s'il existe une tâche Tk. Dans la négative, l'algorithme prend fin, chacune des tâches de l'application considérée ayant été placée avec succès sur un coeur. Au contraire, s'il existe au moins une tâche Tk de la liste des tâches 20 ordonnées qui n'a pas été placée sur un coeur, la première tâche non placée de la liste des tâches ordonnées est sélectionnée (étape 215). Un autre test est alors effectué pour déterminer s'il existe au moins un coeur qui n'a pas encore été sélectionné pour tenter d'y placer la tâche Tk sélectionnée (étape 220), c'est-à-dire pour déterminer si le coeur Cp a déjà été 25 sélectionné pour tenter d'y placer la tâche Tk. Dans la négative, s'il a été tenté de placer la tâche Tk sur chacun des coeurs du système mufti-coeurs, l'algorithme prend fin. Le placement des tâches est alors un échec. Dans ce cas, une solution consiste par exemple à ajouter au moins un coeur au système mufti-coeurs et à ré-exécuter l'algorithme décrit ici. 30 Au contraire, si le coeur Cp n'a pas encore été sélectionné pour tenter d'y placer la tâche Tk sélectionnée, un test est effectué pour déterminer si la tâche Tk sélectionnée peut être placée sur le coeur Cp sélectionné (étape 225). 2 99 7774 10 Si la tâche Tk sélectionnée ne peut être placée sur le coeur Cp sélectionné, la valeur de l'index p est incrémentée de un, modulo n, c'est-à-dire modulo le nombre de coeurs du système mufti-coeurs pouvant être utilisés pour placer des tâches de l'application considérée (étape 230). L'algorithme reboucle alors à l'étape 220 pour déterminer si la tâche Tk peut être placée sur le coeur suivant (coeur Cp). Si, au contraire, la tâche Tk sélectionnée peut être placée sur le coeur Cp sélectionné, elle l'est (étape 235). La valeur de l'index k est alors incrémentée de un et celle de l'index p est également incrémentée de un, modulo n (étape 240). L'algorithme reboucle ensuite à l'étape 210 pour déterminer s'il reste au moins une tâche Tk à placer sur un coeur. Pour déterminer si une tâche périodique ou pseudo-périodique Tk peut être placée sur un coeur Cp, il convient, de préférence, de prendre en compte la fréquence de cette tâche à placer par rapport à celles des tâches déjà placées sur le même coeur, ainsi que leurs pires temps d'exécution et leurs temps de réponse impartis. À ces fins, des règles peuvent être utilisées. Ainsi, par exemple, il peut être décidé qu'une tâche Tr ne peut être placée sur un coeur Cp sur lequel ont été préalablement placées un ensemble de tâches Ts (s variant de 1 à (r - 1)) que si, et seulement si, pour tout k appartenant à l'intervalle [1, il, WCETREEL(Ti) < DL(Tk) i=k avec DL(Tk) WCETREEL(Ti)= CEIL( WCET(Ti)) 8(Ti) où la fonction CEIL(x) est une fonction qui retourne l'entier immédiatement supérieur à la valeur de la variable x. De telles règles permettent de prendre en compte l'exécution d'une tâche de plus faible période et de calculer son impact réel sur des tâches déjà placées sur le même coeur. Naturellement il est possible d'utiliser d'autres règles.

Lorsqu'une tâche est placée sur un coeur, une priorité d'exécution est ici associée à la tâche. Cette priorité correspond, par exemple, à son rang d'assignation sur le coeur. Ainsi, la première tâche placée sur un coeur a une priorité égale à 1, la seconde tâche placée sur ce coeur a une priorité égale à 2 et ainsi de suite. Selon un mode de réalisation particulier, lorsqu'une tâche est placée sur un coeur, elle ne peut être déplacée ultérieurement pour y placer d'autres tâches. Lorsqu'un ensemble de tâches a été placé avec succès sur un ensemble de coeurs d'un système mufti-coeurs, une liste de tâches est obtenue pour chaque coeur du système. Les tâches des listes obtenues sont classées, par liste, de la tâche ayant la plus grande période à la tâche ayant la plus petite période, c'est-à-dire de la tâche ayant la plus faible priorité à la tâche ayant la plus haute priorité. En d'autres termes, la priorité d'une tâche est ici déterminée par sa position dans la liste de tâches affectées au coeur considéré. Lorsque toutes les tâches d'une application ont été placées sur un ensemble de coeurs d'un système mufti-coeurs, le comportement temps réel de l'application correspondante est vérifié car chaque tâche a le temps de s'exécuter avant d'atteindre la fin de son temps de réponse imparti malgré des interruptions de tâches plus prioritaires situées sur le même coeur. La figure 3 illustre un exemple de placement de trois tâches sur un coeur, conformément à l'algorithme décrit en référence à la figure 2. Un rectangle blanc représente ici un temps de réponse imparti à une tâche tandis qu'un rectangle noir représente le temps de traitement effectivement alloué par le noeud à la tâche. L'algorithme décrit en référence à la figure 2 peut être utilisé à différentes fins. Comme décrit précédemment, il peut être utilisé pour une certification formelle. L'algorithme détermine alors un placement qui garantit le comportement d'une application multitâche sur une plate-forme informatique donnée. Il peut également être utilisé pour déterminer le dimensionnement minimum d'une plate-forme devant être mise en oeuvre. A ces fins, l'algorithme est lancé de façon successive en réduisant ou en augmentant, à chaque exécution, le nombre de coeurs pouvant être utilisés, jusqu'à obtenir le nombre de coeurs optimal. L'algorithme permet également de valider un placement effectué de façon manuelle. À ces fins, la liste des tâches et de leur affectation aux différents coeurs est fournie à l'algorithme qui n'effectue pas, dans ce cas, l'étape de tri (étape 200). Si la validation réussit sans modifier l'ordre des tâches, le placement manuel était, au sens de l'algorithme, optimal. Si la validation modifie l'ordre des tâches, une solution plus adaptée est trouvée. Au contraire, si la validation échoue, le placement manuel était incorrect. L'algorithme peut aussi être utilisé pour la certification d'une application répartie. Cet algorithme est utilisable pour calculer le placement des tâches sur un cluster de machines reliées entre elles par un réseau haut débit et dans lequel les horloges sont synchronisées. Cela permet notamment de mettre en oeuvre des applications temps réel réparties de grande taille. A ces fins, il convient de dédier à l'application un certain nombre de coeurs, isolés de toute perturbation, par machine physique. Il convient également de prendre en compte, dans le temps de commutation, les aspects communication réseau entre machines.

La figure 4 illustre un exemple d'architecture matérielle d'un dispositif 400 adapté à mettre en oeuvre certaines étapes de l'invention, en particulier les étapes décrites en référence à la figure 2. Le dispositif 400 est, par exemple, un ordinateur ou une station de travail. Il comporte ici un bus de communication 405 auquel sont reliés : - une ou plusieurs unités centrales de traitement ou microprocesseurs 410 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - une mémoire morte 415 (ROM, acronyme de Read Only Memory en terminologie anglo-saxonne) pouvant comporter des programmes (prog, prog1 et prog2) nécessaires à la mise en oeuvre de l'invention ; - une mémoire vive ou mémoire cache 420 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des 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 450 adaptée à transmettre et à recevoir des données.

Le dispositif 400 dispose également, de préférence, d'un disque dur 435 pouvant comporter les programmes précités ainsi que des informations traitées ou à traiter selon l'invention et d'un lecteur de cartes mémoires 440 adapté à recevoir une carte mémoire 445 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 400 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 400 directement ou par l'intermédiaire d'un autre élément du dispositif 400. 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 435 ou en mémoire morte 415. Selon une variante, la carte mémoire 445 peut contenir des informations, notamment des informations à traiter selon l'invention, ainsi que le code exécutable des programmes précités qui, une fois lu par le dispositif 400, est stocké dans le disque dur 435. Selon une autre variante, le code exécutable des programmes et les informations à traiter selon l'invention pourront être reçus, au moins partiellement, par l'intermédiaire de l'interface 450, pour être stocké de façon identique à celle décrite précédemment. De manière plus générale, le ou les programmes ainsi que les informations à traiter selon l'invention pourront être chargés dans un des moyens de stockage du dispositif 400 avant d'être exécutés.

L'unité centrale 410 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 435 ou dans la mémoire morte 415 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 435 ou la mémoire morte 415, sont transférés dans la mémoire vive 420 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.

Claims (10)

1. REVENDICATIONS1. Procédé pour ordinateur de placement d'une pluralité de tâches dans un système comprenant une pluralité de coeurs, avant l'exécution de chacune desdites tâches, des contraintes de temps étant associées à chaque tâche de ladite pluralité de tâches, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes : - affectation (205) d'au moins une tâche distincte de ladite pluralité de tâches à chaque coeur de ladite pluralité de coeurs ; - sélection (220) d'une tâche non affectée de ladite pluralité de tâches ; - identification (225) d'un coeur de ladite pluralité de coeurs susceptible d'exécuter ladite tâche sélectionnée selon des contraintes de temps associées à ladite tâche sélectionnée et des contraintes de temps associées à des tâches préalablement affectées audit coeur identifié ; et - affectation (235) de ladite tâche sélectionnée audit coeur identifié.
2. 2. Procédé selon la revendication 1 selon lequel lesdites étapes de sélection d'une tâche, d'identification d'un coeur et d'affectation d'une tâche sélectionnée à un coeur identifié sont répétées pour affecter un ensemble de tâches de ladite pluralité de tâches à au moins un coeur de ladite pluralité de coeurs.
3. 3. Procédé selon la revendication 1 ou la revendication 2 comprenant en outre une étape d'assignation d'une priorité à chaque tâche affectée à un coeur, ladite priorité étant déterminée en fonction de l'ordre d'assignation des tâches audit coeur.
4. 4. Procédé selon l'une quelconque des revendications 1 à 3 selon lequel lesdites contraintes de temps comprennent au moins un pire temps d'exécution de la tâche associée, un temps de réponse imparti à la tâche associée et une période d'exécution de la tâche associée.
5. 5. Procédé selon l'une quelconque des revendications 1 à 4 comprenant en outre une étape préalable d'ordonnancement (200) des tâches de ladite pluralité de tâches selon au moins une contrainte de temps.
6. 6. Procédé selon la revendication 5, dépendante de la revendication 4, selon lequel ledit ordonnancement est effectué selon une période d'exécution de la tâche associée.
7. 7. Procédé selon l'une quelconque des revendications 1 à 6 selon lequel ladite étape d'identification d'un coeur comprend les étapes suivantes : - sélection d'un coeur de ladite pluralité de coeurs ; - évaluation de la capacité dudit coeur sélectionné à exécuter ladite tâche sélectionnée selon des contraintes de temps associées à ladite tâche sélectionnée et les contraintes de temps associées aux tâches préalablement affectées audit coeur sélectionné ; et - si ledit coeur sélectionné n'est pas capable d'exécuter ladite tâche sélectionnée selon des contraintes de temps associées à ladite tâche sélectionnée et des contraintes de temps associées aux tâches préalablement affectées audit coeur sélectionné, répétition des étapes de sélection d'un coeur et d'évaluation.
8. 8. Procédé selon la revendication 7 selon lequel ladite pluralité de coeurs forme une liste ordonnée de coeurs, un coeur étant sélectionné de façon incrémentale dans ladite liste ordonnée de coeurs.
9. 9. 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 1 à 8 lorsque ledit programme est exécuté sur un ordinateur.
10. 10. Dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 8.