WO2019122588A1 - Procédé de gestion d'une pluralité de tâches par un calculateur automobile multicoeur - Google Patents

Procédé de gestion d'une pluralité de tâches par un calculateur automobile multicoeur Download PDF

Info

Publication number
WO2019122588A1
WO2019122588A1 PCT/FR2018/053179 FR2018053179W WO2019122588A1 WO 2019122588 A1 WO2019122588 A1 WO 2019122588A1 FR 2018053179 W FR2018053179 W FR 2018053179W WO 2019122588 A1 WO2019122588 A1 WO 2019122588A1
Authority
WO
WIPO (PCT)
Prior art keywords
task
tasks
cores
singular
identifier
Prior art date
Application number
PCT/FR2018/053179
Other languages
English (en)
Inventor
Franck DELPECH
Stéphane Eloy
Original Assignee
Continental Automotive France
Continental Automotive Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Continental Automotive France, Continental Automotive Gmbh filed Critical Continental Automotive France
Priority to US16/954,978 priority Critical patent/US20200310870A1/en
Priority to CN201880081854.3A priority patent/CN111480144B/zh
Publication of WO2019122588A1 publication Critical patent/WO2019122588A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/461—Saving or restoring of program or task context
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals

Definitions

  • FIG. 1 shows the treatment of three regular functions F1, F2, F3 respectively by three cores C1, C2, C3 interrupted at a time ti by the implementation of a singular function FS d.
  • the division of tasks T1, T2, T3, T4, T5, T6, T7, T8, T9 is predetermined so that the first core C1 processes the tasks T1, T4 and T7, the second core C2 processes the tasks T2, T5 and T8 and that the third heart C3 processes the tasks T3, T6 and T9.
  • the selection step is performed by a management function common to all the cores.
  • the common management function uses for each task a binary variable (or "flag") to indicate the state of support of said task by one of the cores.
  • the common management function uses an atomic function (that is to say non-interruptible) to manage the update of the binary variable associated with each task.
  • each core executes this common management function.
  • the first heart that executes the atomic function associated with the first task locks the associated binary (flag) variable (for example by passing from the binary value 0 to the binary value 1) and thus renders this first task inaccessible to the other cores.
  • the second heart reads the binary variable associated with the first task and finds that it has the value 1, it then tests the binary variable associated with the second task. If no other core has yet supported the second task, then the second heart locks the associated binary variable and thus makes this second task inaccessible to other cores. And so on for the other hearts and the treatments of the other tasks that make up the singular function.
  • the computer is able to control the execution, by each heart, of a predetermined task of the predetermined ordered list.
  • an initialization of the microcontroller may be necessary when the software starts or restarts, for example in the event of a runtime error or an electromagnetic disturbance.
  • a transition function is necessary during a change of state of the ignition key or when the engine is started or stopped.
  • an ordered and predetermined list of identifiers of the tasks is stored in the memory zone 100 for each singular function, each core C1, C2, C3 of the microcontroller 10 being then configured, following the detection of a singular event requiring the triggering of a particular singular function and whenever said heart C1, C2, C3 is available, for selecting, in the ordered list of identifiers of the tasks relating to the particular singular function, the identifier of the first task that has not yet been processed by another heart C1, C2, C3 and to process said selected task.
  • each heart C1, C2, C3 implements a regular function F 1, F 2, F 3 (or is inactive in the absence of a function to be implemented).
  • the singular function FS may also include so-called "fixed" tasks (not shown) TF1, TF2 and TF3, possibly empty (that is to say not requiring any processing) which must imperatively be executed on a particular core C1, C2, C3 (for example for reasons of memory protection between the cores) before the implementation of the dynamic tasks T1, T2, T3, T4, T5, T6, T7, T8, T9 .
  • the task TF1 can thus represent the fixed task of the singular function FS associated with the first core C1, the task TF2 the fixed task of the singular function FS associated with the second core C2 and the task TF3 the fixed task of the singular function FS associated with the third heart C3.
  • the first core C1 selects from the ordered list of identifiers of the tasks relating to the singular function associated with the first identifier, and begins to execute the corresponding task T1 at a time t10.
  • the second core C2 selects from the ordered list of identifiers of the tasks relating to the singular function associated with the second identifier, and begins to execute the corresponding task T2 at the instant tio.
  • the third core C3 selects from the ordered list of identifiers of the tasks relating to the associated singular function the third identifier, and begins to execute the corresponding task T3 at time t10.
  • each core C1, C2, C3 will execute the same common task, called the common management task TG (FIG. 6), which is configured to traverse the ordered list and select the first identifier T1, T2 , T3, T4, T5, T6, T7, T8, T9 whose task has not yet been supported by one of the cores C1, C2, C3.
  • an indicator for example a binary variable ("flag" in English) associated with each task (named flag_ti where i is in all natural between 1 and 9 in this example), can be advantageously used to signify that an identifier has already been selected by one of the hearts.
  • TEST_SET a atomic function (that is to say, not breakable, uninterruptible) called TEST_SET, and mentioned TS in the chart of Figure 6, which tests the value of this flag, sets it to 1 if it is 0, and returns the value of this flag.
  • the indicator (or flag; fg) associated with the identifier of each of the tasks T1, T2 and T3 is changed from 0 to 1 when each of the three cores respectively selects the identifiers of said tasks T1, T2, T3.
  • the method comprises an initialization of the indicators associated with each task, for example at the value 0, carried out prior to the implementation of the singular function FS.
  • the second heart C2 having completed the task T2 at a time ti 2 while the third heart C3 is performing the task T4 and the first heart C1 is still executing the task T1, said second heart C2 then selects the identifier of the next task in the list that has not yet been assigned by choosing the first identifier of the list whose associated indicator is 0, in this case the identifier of the task T5 , and implements said task T5.
  • the second heart C2 having completed the task T5 at a time ti 4 while the third heart C3 is performing the task T4 and the first heart C1 is still executing the task T6, said second heart C2 then selects the identifier of the next task of the list which has not yet been assigned by choosing the first identifier of the list whose associated indicator is 0, in this case the identifier of the task T7 , and implements said task T7.
  • the first heart C1 having completed the task T6 at a time ti 6 while the second heart C2 is executing the task T7 and the third heart C3 is performing the task T8, said first heart C1 then selects the identifier of the next task in the list that has not yet been assigned by choosing the first identifier of the list whose associated indicator is 0, in this case the remaining identifier of the task T9 , and implements said task T9.
  • step E6 The detection (step E6) of the end of the processing of all the tasks entails the resumption of the regular functions F1, F2, F3 (step E7).
  • the implementation of the regular functions F1, F2, F3, previously suspended at time t10 then resumes at a time t 20 (step E7) when each of the cores C1, C2, C3 has finished processing the task that it handles and that there are more identifiers of tasks to be treated in the ordered list (ie all the tasks were treated and all the indicators called flags are at 1).
  • step E6 When the first core C1 has finished executing the task T9 and finds that there is no longer any identifier to be selected from the ordered list (step E6), the implementation of the regular functions F1, F2, F3, suspended previously at time tio, then resumes (step E7) at a time t 20 respectively on each of the three cores C1, C2, C3.
  • the heart C1, C2, C3 which, the first one, has finished performing its fixed task TF1, TF2, TF3, can start the task of Common TG management and select the first T1 task from the list before the other cores each select the next available task from the list.
  • the method according to the invention thus advantageously makes it possible to dynamically manage the distribution of tasks between the different cores so as to optimize the processing time of a singular function by the computer and thus make the system more reactive to the resumption of processing. regular functions.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

La présente invention a pour objet un procédé de gestion d'une pluralité de tâches d'une fonction singulière mise en œuvre par un calculateur de véhicule automobile, ledit calculateur comprenant un microcontrôleur, ledit microcontrôleur, dit « multicoeur », comprenant une pluralité de cœurs aptes chacun à traiter des fonctions régulières et des fonctions singulières, chaque fonction singulière comportant une pluralité de tâches à exécuter, identifiées chacune par un identifiant, ledit procédé étant caractérisé en ce qu'il comprend, lors du traitement des tâches d'une fonction singulière, à chaque fois qu'un cœur de la pluralité de cœurs est disponible pour traiter une tâche, une étape (E4) de sélection, par ledit cœur disponible, dans une liste ordonnée prédéterminée d'identifiants des tâches de la fonction singulière, de l'identifiant de la première tâche qui n'a pas encore été traitée par les autres cœurs et une étape (E5) de traitement de la tâche correspondant à l'identifiant sélectionné par ledit cœur disponible.

Description

Procédé de gestion d’une pluralité de tâches par un calculateur automobile
multicœur
La présente invention se rapporte au domaine des calculateurs embarqués dans les véhicules automobiles et concerne plus particulièrement un procédé de gestion d’une pluralité de tâches par un microcontrôleur multicœur embarqué dans un véhicule automobile.
De manière connue, un véhicule automobile comporte de nos jours une pluralité de calculateurs utilisés pour exécuter diverses fonctions telles que, notamment, le contrôle du moteur du véhicule. Chaque calculateur comprend au moins un processeur ou un microcontrôleur qui exécute un ou plusieurs logiciels afin de remplir les fonctions désirées.
Un logiciel définit une pluralité de fonctions qui sont exécutées dans un ordre précis ou selon les données d'entrée reçues ou les données de sortie générées.
Quand un logiciel s’exécute sur un processeur ou un microcontrôleur qui possède plusieurs cœurs, le traitement des fonctions est réalisé en parallèle sur les différents cœurs. Dans ce but, chaque fonction est divisée en une pluralité de tâches, chaque tâche étant exécutée par l’un des cœurs.
Certaines fonctions, dites « régulières », par exemple liées à la gestion de l’injection de carburant, sont exécutées de manière régulière, par exemple toutes les 10 ou 100 ms, tandis que d’autres fonctions, dites « singulières », sont exécutées de manière asynchrone lorsque des événements singuliers surviennent.
Les fonctions d’initialisation, par exemple la fonction exécutée lors du démarrage du logiciel, sont considérées comme des fonctions singulières et traitées comme telles. A titre d’exemple, il peut être nécessaire de mettre en œuvre une fonction de transition lorsque certains événements notables sont détectés, tels que le changement de la position de la clé de contact ou le démarrage ou l’arrêt du moteur du véhicule.
Lorsqu’un tel événement singulier survient, il est nécessaire de suspendre l’exécution de toutes les fonctions régulières sur l’ensemble des cœurs afin de traiter la fonction singulière d’initialisation ou de transition requise pour cet évènement. Autrement dit, tant que le traitement de la fonction singulière n’est pas terminé, les cœurs n’exécutent aucune fonction régulière.
Une fonction singulière d’initialisation ou de transition comprend une pluralité de tâches qui sont exécutées en parallèle sur les différents cœurs, chaque cœur prenant en charge certaines des tâches. La répartition de ces tâches entre les différents cœurs est prédéterminée, par exemple en usine ou à la génération du logiciel, et est stockée dans une zone mémoire du microcontrôleur. En d’autres termes, la répartition des tâches des fonctions singulières est statique et est donc toujours réalisée de manière identique pendant la durée de vie du logiciel.
A titre d’exemple, on a représenté à la figure 1 le traitement de trois fonctions régulières F1 , F2, F3 respectivement par trois coeurs C1 , C2, C3 interrompues à un instant ti par la mise en oeuvre d’une fonction singulière FS d’initialisation ou de transition comportant neuf tâches T1 , T2, T3, T4, T5, T6, T7, T8, T9. La répartition des tâches T1 , T2, T3, T4, T5, T6, T7, T8, T9 est prédéterminée de sorte que le premier cœur C1 traite les tâches T1 , T4 et T7, que le deuxième cœur C2 traite les tâches T2, T5 et T8 et que le troisième cœur C3 traite les tâches T3, T6 et T9.
La reprise des fonctions régulières ne peut alors avoir lieu que lorsque la dernière tâche aura été achevée à un instant t2 par le cœur qui la met en œuvre, en l’espèce la tâche T7 mise en œuvre par le premier cœur C1.
Afin d’optimiser la répartition statique des tâches d’une fonction singulière, il est connu de répartir préalablement les tâches de sorte que les cœurs C1 , C2, C3 terminent leur dernière tâche à des instants proches les uns des autres.
Cependant, la vitesse de traitement des cœurs pouvant varier et ce travail d’optimisation n’étant pas toujours réalisé ou n’étant pas possible faute de mesures pertinentes et représentatives, il s’avère qu’en pratique un cœur peut traiter sa dernière tâche significativement longtemps après les dernières tâches respectives des autres cœurs, ces derniers étant inactifs pendant ce temps, ce qui peut ralentir significativement le fonctionnement du logiciel et rendre le système moins réactif.
Il existe donc un besoin pour une solution optimisant en temps réel la répartition des tâches afin de réduire le temps de traitement des fonctions singulières et rendre ainsi le système le plus réactif possible.
A cette fin, l’invention a pour objet un procédé de gestion d’une pluralité de tâches d’une fonction singulière mise en œuvre par un calculateur de véhicule automobile, ledit calculateur comprenant un microcontrôleur, ledit microcontrôleur, dit « multicœur », comprenant une pluralité de cœurs aptes chacun à traiter des fonctions régulières et des fonctions singulières, chaque fonction singulière comportant une pluralité de tâches à exécuter identifiées chacune par un identifiant. Ledit procédé étant remarquable en ce qu’il comprend, lors du traitement des tâches d’une fonction singulière, à chaque fois qu’un cœur de la pluralité de cœurs est disponible pour traiter une tâche, une étape de sélection, par ledit cœur disponible, dans une liste ordonnée prédéterminée d’identifiants des tâches de la fonction singulière, de l’identifiant de la première tâche qui n’a pas encore été traitée par les autres cœurs et une étape de traitement de la tâche correspondant à l’identifiant sélectionné par ledit cœur disponible. Le procédé selon l’invention permet ainsi d’équilibrer automatiquement, lors de l’exécution du logiciel, la charge des coeurs du microcontrôleur lors des phases d’initialisation et de transition.
De préférence, la fonction singulière est une fonction d’initialisation ou de transition entre deux états du moteur du véhicule.
Selon un aspect de l’invention, le procédé comprend en outre, antérieurement à l’étape de sélection, les étapes de traitement d’une pluralité de fonctions régulières par la pluralité de coeurs du microcontrôleur, de détection d’un événement de déclenchement de la fonction singulière, et de suspension du traitement de la pluralité de fonctions régulières par la pluralité de coeurs suite à ladite détection.
Selon une caractéristique de l’invention, l’étape de sélection est réalisée par une fonction de gestion commune à tous les coeurs.
Avantageusement, la fonction de gestion commune utilise pour chaque tâche une variable binaire (ou « flag ») pour indiquer l’état de prise en charge de ladite tâche par l’un des coeurs.
De manière préférée, la fonction de gestion commune utilise une fonction atomique (c'est-à-dire non interruptible) pour gérer la mise à jour de la variable binaire associée à chaque tâche. Ainsi, au démarrage du traitement de la fonction singulière, chaque cœur exécute cette fonction de gestion commune. Le premier cœur qui exécute la fonction atomique associée à la première tâche verrouille la variable binaire (flag) associée (par exemple en passant de la valeur binaire 0 à la valeur binaire 1 ) et rend ainsi cette première tâche inaccessible aux autres cœurs. Lorsque le deuxième cœur lit la variable binaire associée à la première tâche et constate qu’elle a pour valeur 1 , il teste alors la variable binaire associée à la deuxième tâche. Si aucun autre cœur n’a encore pris en charge la deuxième tâche, alors le second cœur verrouille la variable binaire associée et rend ainsi cette deuxième tâche inaccessible aux autres cœurs. Et ainsi de suite pour les autres cœurs et les traitements des autres tâches qui composent la fonction singulière.
De manière avantageuse, le procédé comprend en outre une étape d’initialisation des variables binaires préalablement à l’exécution de la fonction singulière.
De préférence, le procédé comprend en outre, une étape de détection de la fin d’exécution de la tâche relative au dernier identifiant de la liste ordonnée prédéterminée par l’un des cœurs de la pluralité de cœurs.
De préférence encore, le procédé comprend en outre postérieurement à l’étape de détection de la fin d’exécution de la tâche relative au dernier identifiant de la liste ordonnée prédéterminée, une étape de reprise du traitement de la pluralité de fonctions régulières par la pluralité de cœurs du microcontrôleur. Selon un aspect de l’invention, le procédé comprend en outre une étape préliminaire de détermination de la liste ordonnée d’identifiants des tâches de la fonction singulière.
Avantageusement, le procédé comprend en outre une étape de stockage de la liste ordonnée prédéterminée dans une zone mémoire du calculateur.
L’invention concerne aussi un calculateur pour véhicule automobile, ledit calculateur comprenant un microcontrôleur, ledit microcontrôleur, dit « multicœur », comprenant une pluralité de coeurs aptes chacun à traiter des fonctions régulières et des fonctions singulières, chaque fonction singulière comportant une pluralité de tâches à exécuter identifiées chacune par un identifiant. Ledit calculateur est remarquable en ce que, lors du traitement des tâches d’une fonction singulière, chaque fois qu’un cœur de la pluralité de cœurs est disponible pour traiter une tâche, ledit cœur disponible est apte à sélectionner, dans une liste ordonnée prédéterminée d’identifiants des tâches de la fonction singulière, l’identifiant de la première tâche qui n’a pas encore été traitée par les autres cœurs et pour traiter ladite tâche correspondant à l’identifiant sélectionné.
Avantageusement, le calculateur comprend une zone mémoire dans laquelle est stockée la liste ordonnée prédéterminée d’identifiants des tâches de la fonction singulière.
Avantageusement encore, le calculateur est apte à commander le traitement d’une pluralité de fonctions régulières par la pluralité de cœurs du microcontrôleur, à détecter un événement de déclenchement de la fonction singulière, et à suspendre le traitement de la pluralité de fonctions régulières par la pluralité de cœurs suite à ladite détection.
De manière préférée, le calculateur est apte à commander l’exécution, par chaque cœur, d’une tâche prédéterminée de la liste ordonnée prédéterminée.
L’invention concerne enfin un véhicule automobile comprenant un calculateur tel que présenté précédemment.
- La figure 1 (déjà commentée) illustre un exemple de répartition statique des tâches selon l’art antérieur.
- La figure 2 illustre schématiquement une forme de réalisation du calculateur selon l’invention.
- La figure 3 illustre un exemple de liste ordonnée d’identifiants des tâches relatives à une fonction singulière.
- La figure 4 illustre schématiquement un mode de réalisation du procédé selon l’invention.
- La figure 5 illustre un exemple de répartition dynamique des tâches selon l’invention. - La figure 6 illustre un exemple de tâche commune de gestion.
L’invention est destinée à être mise en oeuvre par un microcontrôleur ou un processeur multicoeur d’un calculateur embarqué dans un véhicule automobile afin de gérer les tâches relatives au fonctionnement du véhicule, notamment de son ou ses moteurs.
Afin d’illustrer la présente invention, on a représenté schématiquement à la figure 2 un calculateur 1 comprenant un microcontrôleur 10. Le microcontrôleur 10 comprend trois coeurs C1 , C2, C3 et une zone mémoire 100.
On notera que l’invention pourrait tout aussi bien être mise en oeuvre par un microcontrôleur ou un processeur comportant deux ou plus de trois coeurs. De même, en variante, on notera que la zone mémoire 100 pourrait être externe au microcontrôleur et se trouver dans une autre partie du calculateur 1 , voire hors du calculateur 1.
Dans un microcontrôleur 10 multicoeur, chaque cœur C1 , C2, C3 est configuré pour traiter séquentiellement des tâches caractérisées chacune par un identifiant T1 , T2, T3, T4, T5, T6, T7, T8, T9.
On a illustré par la suite la mise en œuvre de neuf tâches par les trois cœurs C1 , C2, C3, mais il va de soi que le nombre de tâches pourrait être inférieur ou supérieur à neuf.
Ces tâches sont définies dans un logiciel (ou programme), stocké dans la zone mémoire 100, et permettent de mettre en œuvre des fonctions nécessaires au fonctionnement du véhicule.
Parmi ces fonctions, on distingue les fonctions régulières, par exemple mises en œuvre de manière périodique toutes les 10 ou 100 ms et liées au contrôle du ou des moteurs du véhicule, et les fonctions singulières, survenant de façon asynchrone et liées à des opérations d’initialisation ou de transition entre différents états.
A titre d’exemple, une initialisation du microcontrôleur peut être nécessaire lorsque le logiciel démarre ou redémarre, par exemple en cas d’erreur d’exécution ou de perturbation électromagnétique. Toujours à titre d’exemple, une fonction de transition est nécessaire lors d’un changement d’état de la clef de contact ou bien lorsque le moteur est démarré ou arrêté.
Lorsqu’un événement nécessitant l’activation d’une fonction singulière survient, il est nécessaire de suspendre le traitement des tâches associées aux fonctions régulières par tous les cœurs du microcontrôleur 10 afin de traiter les tâches de la fonction singulière requise, qui est davantage prioritaire qu’une fonction régulière.
Selon l’invention, une liste ordonnée et prédéterminée d’identifiants des tâches est stockée dans la zone mémoire 100 pour chaque fonction singulière, chaque cœur C1 , C2, C3 du microcontrôleur 10 étant alors configuré, suite à la détection d’un événement singulier nécessitant le déclenchement d’une fonction singulière déterminée et à chaque fois que ledit cœur C1 , C2, C3 est disponible, pour sélectionner, dans la liste ordonnée d’identifiants des tâches relatives à la fonction singulière déterminée, l’identifiant de la première tâche qui n’a pas encore été traitée par un autre cœur C1 , C2, C3 et pour traiter ladite tâche sélectionnée.
L’invention va maintenant être décrite dans sa mise en œuvre en référence aux figures 3 à 6.
En prérequis, on considère que la liste ordonnée des identifiants des tâches a été préalablement déterminée.
Dans une étape E0, chaque cœur C1 , C2, C3 met en œuvre une fonction régulière F 1 , F2, F3 (ou est inactif en l’absence de fonction à mettre en œuvre).
Dans une étape E1 , un événement singulier ES survient, nécessitant la mise en œuvre immédiate d’une fonction singulière associée, par exemple d’initialisation ou de transition.
Dans une étape E2, l’exécution des fonctions régulières est suspendue pour permettre l’exécution des tâches de la fonction singulière FS à mettre en œuvre suite à la détection de l’évènement singulier ES.
Dans une étape E3, les valeurs des indicateurs de chaque tâche de la liste sont initialisées, par exemple en les mettant à zéro.
Ensuite, dans une étape E4, une même tâche commune, appelée tâche de gestion TG commune (figure 6) est exécutée par les trois cœurs C1 , C2, C3 afin que chaque cœur C1 , C2, C3 sélectionne dans la liste ordonnée d’identifiants des tâches relatives à la fonction singulière associée, illustrée à la figure 3, un identifiant de la prochaine tâche de la liste qui n’a pas encore été sélectionnée par un autre cœur C1 , C2, C3 comme cela sera décrit ci-après.
On notera que, de manière optionnelle, la fonction singulière FS peut comporter également des tâches dites « fixes » (non représentée) TF1 , TF2 et TF3, éventuellement vides (c’est-à-dire ne nécessitant pas de traitement) qui doivent impérativement être exécutées sur un cœur C1 , C2, C3 particulier (par exemple pour des raisons de protection de mémoire entre les cœurs) avant la mise en œuvre des tâches dynamiques T1 , T2, T3, T4, T5, T6, T7, T8, T9. La tâche TF1 peut ainsi représenter la tâche fixe de la fonction singulière FS associée au premier cœur C1 , la tâche TF2 la tâche fixe de la fonction singulière FS associée au deuxième cœur C2 et la tâche TF3 la tâche fixe de la fonction singulière FS associée au troisième cœur C3. Ces tâches fixes TF1 , TF2, TF3, c'est-à-dire liées à un cœur C1 , C2, C3, n’apparaissent pas dans la liste des identifiants des tâches et ne sont donc pas gérées par la fonction de gestion commune. Cependant, elles seront réalisées avant que la fonction de gestion commune ne débute. Dans le cas où la fonction singulière FS comporte des tâches fixes TF1 , TF2, TF3, l’initialisation (étape E3) des indicateurs associés aux tâches T1 , T2, T3, T4, T5, T6, T7, T8, T9 est réalisée avant l’exécution de la plus rapide des tâches fixes TF1 , TF2 ou TF3. De plus, dans ce cas, la fonction de gestion commune pourra être activée par le cœur C1 , C2, C3 qui a achevé en premier la mise en œuvre de sa tâche fixe de manière à optimiser la mise en œuvre et la gestion des tâches T 1 , T2, T3, T4, T5, T6, T7, T8, T9.
Dans l’exemple de la figure 5, au début, le premier cœur C1 sélectionne dans la liste ordonnée d’identifiants des tâches relatives à la fonction singulière associée le premier identifiant, et commence à exécuter la tâche T1 correspondante à un instant tio. Simultanément, le deuxième cœur C2 sélectionne dans la liste ordonnée d’identifiants des tâches relatives à la fonction singulière associée le deuxième identifiant, et commence à exécuter la tâche T2 correspondante à l’instant tio. Simultanément, le troisième cœur C3 sélectionne dans la liste ordonnée d’identifiants des tâches relatives à la fonction singulière associée le troisième identifiant, et commence à exécuter la tâche T3 correspondante à l’instant tio. Il va de soi que tout autre schéma d’allocation initiale des tâches aux cœurs C1 , C2, C3 pourrait être utilisé (par exemple, le troisième cœur C3 pourrait traiter la tâche T1 en premier tandis que le deuxième cœur C2 traiterait la tâche T3 et que le premier cœur C1 traiterait la tâche T2). Ensuite, le cœur C1 , C2, C3 qui termine d’exécuter la tâche T1 , T2, T3 en premier va sélectionner (étape E4) et exécuter (étape E5) la tâche dont l’identifiant suivant est stocké dans la liste ordonnée après les identifiants des tâches préalablement sélectionnées et donc des tâches qui ont été ou sont traitées.
En pratique, comme mentionné ci-avant, chaque cœur C1 , C2, C3 va exécuter une même tâche commune, appelée tâche de gestion TG commune (figure 6), qui est configurée pour parcourir la liste ordonnée et sélectionner le premier identifiant T1 , T2, T3, T4, T5, T6, T7, T8, T9 dont la tâche n’a pas encore été prise en charge par l’un des cœurs C1 , C2, C3. Pour ce faire, un indicateur, par exemple une variable binaire (« flag » en langue anglaise) associée à chaque tâche (nommé flag_ti où i est en entier naturel compris entre 1 et 9 dans cet exemple), peut être avantageusement utilisé pour signifier qu’un identifiant a déjà été sélectionné par l’un des cœurs. Par exemple, chaque identifiant de la liste peut être associé à un indicateur prenant pour valeur 0 lorsque l’identifiant n’a pas été sélectionné (i.e. lorsque la tâche correspondante n’a pas encore été prise en charge par l’un des cœurs C1 , C2, C3) et pour valeur 1 lorsque l’identifiant a déjà été sélectionné par l’un des cœurs C1 , C2, C3.
Pour s’assurer qu’une tâche repérée par son identifiant T1 , T2, T3, T4, T5, T6, T7, T8, T9 n’est traitée que par un seul cœur, l’indicateur qui lui est associé est géré par une fonction atomique (c’est-à-dire non sécable, non interruptible) appelée TEST_SET, et mentionnée TS dans l’algorigramme de la figure 6, qui teste la valeur de ce flag, le positionne à la valeur 1 si celui-ci est à 0, et retourne la valeur de ce flag. Ainsi, si deux coeurs exécutent simultanément cette fonction atomique TEST_SET(flag_ti) mentionnée à la figure 6 TS (fg_ti), dès que le tout premier cœur l’exécute, le flag_ti associé à la tâche Ti passe à 1 , le second cœur voit ce flag à 1 et passe donc au test du prochain flag, comme illustré à la figure 6. Dans l’exemple de la figure 5, l’indicateur (ou flag ; fg) associé à l’identifiant de chacune des tâches T1 , T2 et T3 est modifié de 0 à 1 lorsque chacun des trois cœurs sélectionne respectivement les identifiants desdites tâches T1 , T2, T3. De préférence, le procédé comprend une initialisation des indicateurs associés à chaque tâche, par exemple à la valeur 0, réalisée préalablement à la mise en œuvre de la fonction singulière FS.
Toujours dans l’exemple de la figure 5, le troisième cœur C3 termine la tâche T3 à un instant tu avant que le premier cœur C1 n’ait terminé d’exécuter la tâche T1 et que le deuxième cœur C2 n’ait terminé d’exécuter la tâche T2. Le troisième cœur C3 sélectionne alors l’identifiant de la tâche suivante de la liste qui n’a pas encore été attribuée en choisissant le premier identifiant de la liste dont l’indicateur associé est à 0, en l’occurrence l’identifiant de la tâche T4 et met en œuvre ladite tâche T4.
Ensuite, le deuxième cœur C2 ayant terminé la tâche T2 à un instant ti2 alors que le troisième cœur C3 est en train d’exécuter la tâche T4 et que le premier cœur C1 est toujours en train d’exécuter la tâche T1 , ledit deuxième cœur C2 sélectionne alors l’identifiant de la tâche suivante de la liste qui n’a pas encore été attribuée en choisissant le premier identifiant de la liste dont l’indicateur associé est à 0, en l’occurrence l’identifiant de la tâche T5, et met en œuvre ladite tâche T5.
Ensuite, le premier cœur C1 ayant terminé la tâche T1 à un instant ti3 alors que le deuxième cœur C2 est en train d’exécuter la tâche T5 et que le troisième cœur C3 est en train d’exécuter la tâche T4, ledit premier cœur C1 sélectionne alors l’identifiant de la tâche suivante de la liste qui n’a pas encore été attribuée en choisissant le premier identifiant de la liste dont l’indicateur associé est à 0, en l’occurrence l’identifiant de la tâche T6 et met en œuvre ladite tâche T6.
Ensuite, le deuxième cœur C2 ayant terminé la tâche T5 à un instant ti4 alors que le troisième cœur C3 est en train d’exécuter la tâche T4 et que le premier cœur C1 est toujours en train d’exécuter la tâche T6, ledit deuxième cœur C2 sélectionne alors l’identifiant de la tâche suivante de la liste qui n’a pas encore été attribuée en choisissant le premier identifiant de la liste dont l’indicateur associé est à 0, en l’occurrence l’identifiant de la tâche T7, et met en œuvre ladite tâche T7.
Ensuite, le troisième cœur C3 ayant terminé la tâche T4 à un instant ti5 alors que le premier cœur C1 est en train d’exécuter la tâche T6 et que le deuxième cœur C2 est toujours en train d’exécuter la tâche T7, ledit troisième cœur C3 sélectionne alors l’identifiant de la tâche suivante de la liste qui n’a pas encore été attribuée en choisissant le premier identifiant de la liste dont l’indicateur associé est à 0, en l’occurrence l’identifiant de la tâche T8, et met en œuvre ladite tâche T8.
Ensuite, le premier cœur C1 ayant terminé la tâche T6 à un instant ti6 alors que le deuxième cœur C2 est en train d’exécuter la tâche T7 et que le troisième cœur C3 est en train d’exécuter la tâche T8, ledit premier cœur C1 sélectionne alors l’identifiant de la tâche suivante de la liste qui n’a pas encore été attribuée en choisissant le premier identifiant de la liste dont l’indicateur associé est à 0, en l’occurrence l’identifiant restant de la tâche T9, et met en œuvre ladite tâche T9.
Le procédé est ainsi mis en œuvre tant que toutes les tâches n’ont pas été sélectionnées pour être mises en œuvre. La détection (étape E6) de la fin du traitement de toutes les tâches entraîne la reprise des fonctions régulières F1 , F2, F3 (étape E7). Autrement dit, la mise en œuvre des fonctions régulières F1 , F2, F3, suspendue précédemment à l’instant tio, reprend ensuite à un instant t20 (étape E7) lorsque chacun des cœurs C1 , C2, C3 a terminé de traiter la tâche qu’il traitait et qu’il n’y a plus d’identifiants de tâches à traiter dans la liste ordonnée (i.e. toutes les tâches ont été traitées et tous les indicateurs dits flags sont à 1).
Dans l’exemple de la figure 5, lorsque le troisième cœur C3 a terminé d’exécuter la tâche T8 et constate qu’il n’y a plus d’identifiant à sélectionner dans la liste ordonnée (tous les flags sont à 1 ), il devient inactif et attend que les autres cœurs aient terminé d’exécuter leurs tâches. De même, lorsque le deuxième cœur C2 a terminé d’exécuter la tâche T7 et constate qu’il n’y a plus d’identifiant à sélectionner dans la liste ordonnée, il devient inactif et attend que les autres cœurs aient terminé d’exécuter leurs tâches. Lorsque le premier cœur C1 a terminé d’exécuter la tâche T9 et constate qu’il n’y a plus d’identifiant à sélectionner dans la liste ordonnée (étape E6), la mise en œuvre des fonctions régulières F1 , F2, F3, suspendue précédemment à l’instant tio, reprend ensuite (étape E7) à un instant t20 respectivement sur chacun des trois cœurs C1 , C2, C3.
On constate ainsi entre la figure 1 d’art antérieur et la figure 5 selon l’invention une réduction du temps de traitement (t2o - tio) < (t2 - ti) pour le même ensemble de tâches T1 , T2, T3, T4, T5, T6, T7, T8, T9.
On notera que, lorsque la fonction singulière FS comprend des tâches fixes TF1 , TF2, TF3, le cœur C1 , C2, C3 qui, le premier, a terminé d’exécuter sa tâche fixe TF1 , TF2, TF3, peut lancer la tâche de gestion TG commune et sélectionner la première tâche T1 de la liste avant que les autres cœurs ne sélectionnent chacun à leur tour la tâche suivante disponible de la liste. Le procédé selon l’invention permet ainsi avantageusement de gérer de manière dynamique la répartition des tâches entre les différents coeurs de manière à optimiser le temps de traitement d’une fonction singulière par le calculateur et rendre ainsi le système plus réactif à la reprise des traitements des fonctions régulières.

Claims

REVENDICATIONS
1. Procédé de gestion d’une pluralité de tâches d’une fonction singulière mise en oeuvre par un calculateur (1 ) de véhicule automobile, ledit calculateur (1 ) comprenant un microcontrôleur (10), ledit microcontrôleur (10), dit « multicœur », comprenant une pluralité de coeurs (C1 , C2, C3) aptes chacun à traiter des fonctions régulières et des fonctions singulières (FS), chaque fonction singulière (FS) comportant une pluralité de tâches à exécuter identifiées chacune par un identifiant (T1 , T2, T3, T4, T5, T6, T7, T8, T9), ledit procédé étant caractérisé en ce qu’il comprend, lors du traitement des tâches d’une fonction singulière, à chaque fois qu’un cœur (C1 , C2, C3) de la pluralité de coeurs (C1 , C2, C3) est disponible pour traiter une tâche, une étape (E4) de sélection, par ledit cœur disponible (C1 , C2, C3), dans une liste ordonnée prédéterminée d’identifiants (T 1 , T2, T3, T4, T5, T6, T7, T8, T9) des tâches de la fonction singulière (FS), de l’identifiant (T1 , T2, T3, T4, T5, T6, T7, T8, T9) de la première tâche qui n’a pas encore été traitée par les autres cœurs (C1 , C2, C3) et une étape (E5) de traitement de la tâche correspondant à l’identifiant sélectionné par ledit cœur (C1 , C2, C3) disponible.
2. Procédé selon la revendication 1 , comprenant en outre, antérieurement à l’étape de sélection, les étapes de :
traitement (E0) d’une pluralité de fonctions régulières par la pluralité de cœurs (C1 , C2, C3) du microcontrôleur (10),
détection (E1 ) d’un événement de déclenchement de la fonction singulière (FS), suspension (E2) du traitement de la pluralité de fonctions régulières par la pluralité de cœurs (C1 , C2, C3) suite à ladite détection.
3. Procédé selon l’une des revendications précédentes, dans lequel l’étape (E4) de sélection est réalisée par une fonction de gestion commune à tous les cœurs (C1 , C2, C3).
4. Procédé selon la revendication précédente, dans lequel la fonction de gestion commune utilise pour chaque tâche une variable binaire pour indiquer l’état de prise en charge de ladite tâche par l’un des cœurs (C1 , C2, C3).
5. Procédé selon la revendication précédente, dans lequel la fonction de gestion commune utilise une fonction atomique pour gérer la mise à jour de la variable binaire associée à chaque tâche.
6. Procédé selon l’une des revendications 4 et 5, comprenant en outre une étape d’initialisation des variables binaires préalablement à l’exécution de la fonction singulière (FS).
7. Procédé selon l’une des revendications précédentes, comprenant en outre une étape (E6) de détection de la fin d’exécution de la tâche relative au dernier identifiant de la liste ordonnée prédéterminée par l’un des coeurs de la pluralité de coeurs (C1 , C2, C3).
8. Procédé selon la revendication précédente, comprenant en outre postérieurement à l’étape (E6) de détection de la fin d’exécution de la tâche relative au dernier identifiant de la liste ordonnée prédéterminée une étape (E7) de reprise du traitement de la pluralité de fonctions régulières par la pluralité de coeurs du microcontrôleur (10).
9. Calculateur (1 ) pour véhicule automobile, ledit calculateur (1 ) comprenant un microcontrôleur (10), ledit microcontrôleur (10), dit « multicœur », comprenant une pluralité de coeurs (C1 , C2, C3) aptes chacun à traiter des fonctions régulières et des fonctions singulières, chaque fonction singulière comportant une pluralité de tâches à exécuter, identifiées chacune par un identifiant (T1 , T2, T3, T4, T5, T6, T7, T8, T9), ledit calculateur (1 ) étant caractérisé en ce que, lors du traitement des tâches d’une fonction singulière, chaque fois qu’un cœur de la pluralité de cœurs est disponible pour traiter une tâche, ledit cœur disponible est apte à sélectionner, dans une liste ordonnée prédéterminée d’identifiants (T1 , T2, T3, T4, T5, T6, T7, T8, T9), des tâches de la fonction singulière, l’identifiant (T1 , T2, T3, T4, T5, T6, T7, T8, T9) de la première tâche qui n’a pas encore été traitée par les autres cœurs (C1 , C2, C3) et pour traiter ladite tâche correspondant à l’identifiant (T1 , T2, T3, T4, T5, T6, T7, T8, T9) sélectionné.
10. Véhicule automobile comprenant un calculateur (1 ) selon la revendication précédente.
PCT/FR2018/053179 2017-12-19 2018-12-11 Procédé de gestion d'une pluralité de tâches par un calculateur automobile multicoeur WO2019122588A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US16/954,978 US20200310870A1 (en) 2017-12-19 2018-12-11 Method for managing a plurality of tasks by a multicore motor vehicle processor
CN201880081854.3A CN111480144B (zh) 2017-12-19 2018-12-11 多核机动车计算机管理多个任务的方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1762449A FR3075414B1 (fr) 2017-12-19 2017-12-19 Procede de gestion d'une pluralite de taches par un calculateur automobile multicœur
FR1762449 2017-12-19

Publications (1)

Publication Number Publication Date
WO2019122588A1 true WO2019122588A1 (fr) 2019-06-27

Family

ID=61187535

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2018/053179 WO2019122588A1 (fr) 2017-12-19 2018-12-11 Procédé de gestion d'une pluralité de tâches par un calculateur automobile multicoeur

Country Status (4)

Country Link
US (1) US20200310870A1 (fr)
CN (1) CN111480144B (fr)
FR (1) FR3075414B1 (fr)
WO (1) WO2019122588A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112415862B (zh) * 2020-11-20 2021-09-10 长江存储科技有限责任公司 一种数据处理系统及方法
FR3142578A1 (fr) * 2022-11-28 2024-05-31 Vitesco Technologies Procédé et système avec un microcontrôleur multi-cœurs avec tâche chaînée et logique de délestage

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8397235B2 (en) * 2008-10-07 2013-03-12 Futurewei Technologies, Inc. User tolerance based scheduling method for aperiodic real-time tasks
US8381218B2 (en) * 2010-11-30 2013-02-19 Microsoft Corporation Managing groups of computing entities
US8943505B2 (en) * 2012-08-24 2015-01-27 National Instruments Corporation Hardware assisted real-time scheduler using memory monitoring
FR2997774B1 (fr) * 2012-11-08 2021-10-29 Bull Sas Procede, dispositif et programme d'ordinateur de placement de taches dans un systeme multi-cœurs
US10802876B2 (en) * 2013-05-22 2020-10-13 Massachusetts Institute Of Technology Multiprocessor scheduling policy with deadline constraint for determining multi-agent schedule for a plurality of agents
CN103885826B (zh) * 2014-03-11 2017-04-12 武汉科技大学 一种多核嵌入式系统实时任务调度实现方法
CN107463391B (zh) * 2016-06-03 2020-11-10 阿里巴巴集团控股有限公司 任务处理方法、装置及设备
US20180039514A1 (en) * 2016-08-05 2018-02-08 General Electric Company Methods and apparatus to facilitate efficient scheduling of digital tasks in a system

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
ANTONINO TUMEO ET AL: "A dual-priority real-time multiprocessor system on FPGA for automotive applications", 2008 DESIGN, AUTOMATION AND TEST IN EUROPE : MUNICH, GERMANY, 10 - 14 MARCH 2008, PISCATAWAY, NJ : IEEE SERVICE CENTER, US, 10 March 2008 (2008-03-10), pages 1039 - 1044, XP058288814, ISBN: 978-3-9810801-3-1, DOI: 10.1145/1403375.1403625 *
BANUS J M ET AL: "Dual priority algorithm to schedule real-time tasks in a shared memory multiprocessor", PARALLEL AND DISTRIBUTED PROCESSING SYMPOSIUM, 2003. PROCEEDINGS. INTE RNATIONAL APRIL 22-26, 2003, PISCATAWAY, NJ, USA,IEEE, 22 April 2003 (2003-04-22), pages 112 - 119, XP010645652, ISBN: 978-0-7695-1926-5 *
GIANNOPOULOU GEORGIA ET AL: "Scheduling of mixed-criticality applications on resource-sharing multicore systems", 2013 PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON EMBEDDED SOFTWARE (EMSOFT), IEEE, 29 September 2013 (2013-09-29), pages 1 - 15, XP032524797, DOI: 10.1109/EMSOFT.2013.6658595 *

Also Published As

Publication number Publication date
FR3075414A1 (fr) 2019-06-21
CN111480144B (zh) 2023-10-17
FR3075414B1 (fr) 2019-11-08
US20200310870A1 (en) 2020-10-01
CN111480144A (zh) 2020-07-31

Similar Documents

Publication Publication Date Title
EP1043658B1 (fr) Procédé d&#39;amélioration des performances d&#39;un système multiprocesseur comprenant une file d&#39;attente de travaux et architecture de système pour la mise en oeuvre du procédé
EP2987081B1 (fr) Procédé d&#39;allocation temporelle de tâches permettant une récupération d&#39;erreur deterministe en temps réel
EP3238056B1 (fr) Methode d&#39;ordonnancement de taches au niveau des noeuds d&#39;un cluster informatique, ordonnanceur de taches et cluster associes
EP0637798B1 (fr) Procédé d&#39;analyse d&#39;interblocage dans un système d&#39;exploitation
FR3075414B1 (fr) Procede de gestion d&#39;une pluralite de taches par un calculateur automobile multicœur
EP3374866A1 (fr) Procede de controle commande par un microprocesseur multicoeur
EP2850520B1 (fr) Procede de gestion d&#39;une execution de taches dans un systeme informatique
FR2775370A1 (fr) Procede de gestion d&#39;interruptions dans un microprocesseur
EP3674997A1 (fr) Procédé de compilation d&#39;un circuit quantique sur un processeur quantique à ions piégés
EP2342636A1 (fr) Procédé de réalisation d&#39;un appel d&#39;une instance d&#39;une fonction, dispositif, et programme d&#39;ordinateur correspondant
EP2081114A1 (fr) Dispositif informatique à mémoire réservée pour des applications prioritaires
WO2020120690A1 (fr) Procédé de commande d&#39;une unité de contrôle moteur à processeur multicoeur
FR3038086A1 (fr) Procede d&#39;execution d&#39;un programme d&#39;ordinateur comportant une fonction parametree
FR3071334B1 (fr) Procede pour assurer la stabilite des donnees d’un processeur multicoeur d’un vehicule automobile
EP2667302A1 (fr) Procédé de gestion du démarrage d&#39;instances d&#39;applications sur des machines virtuelles d&#39;un réseau distribué
EP2545449B1 (fr) Procédé de configuration d&#39;un système informatique, programme d&#39;ordinateur et système informatique correspondants
EP2530586B1 (fr) Procédé de génération d&#39;un logiciel
FR3082338A1 (fr) Procede de gestion d’une pluralite de taches par un calculateur automobile multicœur
FR2965077A1 (fr) Procede de gestion de taches dans un microprocesseur ou un ensemble de microprocesseurs
US20210124600A1 (en) Rescheduling jit compilation based on jobs of parallel distributed computing framework
EP2959382B1 (fr) Systeme de compilation dynamique d&#39;au moins un flot d&#39;instructions
EP3674995A1 (fr) Procédé de compilation d&#39;un circuit quantique sur un processeur quantique à ions piégés
EP3598315B1 (fr) Accès direct en mémoire
EP3131005A1 (fr) Equipement électronique ferroviaire comprenant un programme de démarrage comportant une ou plusieurs partitions de démarrage, véhicule ferroviaire et système ferroviaire associés
FR2858074A1 (fr) Procede de gestion de l&#39;execution d&#39;au moins un programme sur plusieurs calculateurs

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18839683

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18839683

Country of ref document: EP

Kind code of ref document: A1