FR 3164813 A1 20260123 FR 2407771 A 20240716 La description concerne un procédé et un système informatique à processeur multicœurs configuré pour activer des tâches définies statiquement comportant au moins une tâche initiatrice pour initier un ou plusieurs traitements asynchrones, et au moins un jeu de deux tâches réalisatrices identiques qui réalisent le ou les mêmes traitements asynchrones et qui sont allouées chacune à un cœur différent du processeur multicœur. La tâche initiatrice active les tâches réalisatrices d’un jeu donné lorsqu’un traitement asynchrone donné doit être initié, et la tâche réalisatrice du jeu donné qui est prête la première réalise le traitement asynchrone donné, tandis que la ou les autres tâches réalisatrices du jeu donné ignorent le traitement asynchrone donné. Cela permet d’optimiser l’usage des cœurs, de réaliser une sélection dynamique à l’exécution, du cœur chargé d’exécuter un traitement asynchrone donné et donc de réduire le délai d’attente au minimum. Figure pour l’abrégé : Figure 6 Système informatique à processeur multicœurs configuré pour activer des tâches définies statiquement, et procédé de gestion d’un tel processeur multicœurs. La présente description concerne un système informatique à processeur multicœurs configuré pour activer des tâches définies statiquement. De tels processeurs sont par exemple utilisés dans les systèmes temps réel embarqués, par exemple dans le domaine de l’automobile. Arrière-plan technique Les systèmes temps réel doivent répondre à des événements ou exécuter des tâches dans des délais prévisibles et strictement définis. Un dépassement de ces délais peut entraîner des échecs critiques. Ces contraintes sont particulièrement importantes dans les systèmes embarqués tels que l’automobile. Dans le domaine de l’automobile, les systèmes d’exploitation utilisés suivent la norme OSEK (de l’allemand « Offene Systeme und deren Schnittstellen für die Elektronik in Kraftfahrzeugen »). La norme OSEK spécifie une architecture de système d'exploitation, notamment une structure de gestion des tâches logicielles. En particulier, elle impose une définition statique des tâches, ce qui signifie que les tâches doivent être définies à l'avance, au moment de la configuration du système, et ne peuvent pas être créées dynamiquement pendant l'exécution. En pratique, toutes les tâches ainsi que leurs propriétés doivent être spécifiées dans un fichier de configuration statique avant le déploiement du système. Les propriétés d’une tâche comportent notamment une priorité assignée à la tâche de façon fixe, un état initial de la tâche parmi plusieurs états possibles, des ressources matérielles et logicielles nécessaires à l’exécution de la tâche. Compte-tenu de la complexité des systèmes embarqués, la plupart de ces systèmes utilisent des microcontrôleurs à processeur multicœurs, c’est-à-dire possédant plusieurs unités de traitement pouvant être utilisées simultanément. Différentes stratégies peuvent être mises en œuvre pour répartir les traitements des tâches sur les différents cœurs d’un processeur multicœurs. Il existe un besoin d’optimiser ces stratégies pour d’une part améliorer les performances globales du système informatique, en utilisant au mieux l’ensemble des cœurs disponibles, et d’autre part réduire les temps d’attente des tâches avant leur exécution. Résumé Un premier aspect de la présente description concerne un système informatique à processeur multicœurs configuré pour activer des tâches définies statiquement. Dans le système informatique décrit ici, lesdites tâches comportent : au moins une tâche initiatrice, configurée pour initier un ou plusieurs traitements, dont un ou plusieurs traitements asynchrones, et au moins un jeu de tâches réalisatrices, comportant au moins deux tâches réalisatrices configurées pour réaliser le ou les mêmes traitements asynchrones, et allouées chacune à un cœur différent du processeur multicœur. La tâche initiatrice est configurée pour activer les tâches réalisatrices d’un jeu donné de tâches réalisatrices, lorsqu’un traitement asynchrone donné doit être initié, et les tâches réalisatrices sont configurées de telle sorte que celle des tâches réalisatrices du jeu donné de tâches réalisatrices qui est prête la première réalise le traitement asynchrone donné, tandis que la ou les autres tâches réalisatrices du jeu donné de tâches réalisatrices ignorent le traitement asynchrone donné. Dans un mode de réalisation, chacune des tâches initiatrice et réalisatrices est allouée à un cœur différent du processeur multicœurs. Dans un mode de réalisation, la tâche initiatrice est configurée pour générer une requête d’initiation du traitement asynchrone donné, et les tâches réalisatrices sont configurées pour vérifier, avant de réaliser le traitement asynchrone donné, qu’il existe une requête d’initiation du traitement asynchrone donné en attente d’exécution. Dans un mode de réalisation, les tâches initiatrice et réalisatrices sont configurées pour gérer une information représentative d’un nombre de requêtes d’initiation en attente d’exécution pour chaque traitement asynchrone, ladite information étant mise à jour d’une part, par la tâche initiatrice lorsqu’elle initie un traitement asynchrone donné pour incrémenter le nombre de requêtes d’initiation en attente d’exécution pour le traitement asynchrone donné, et d’autre part, par les tâches réalisatrices lorsqu’elles réalisent le traitement asynchrone donné pour décrémenter le nombre de requêtes d’initiation en attente d’exécution pour le traitement asynchrone donné. Dans un mode de réalisation, le système informatique comporte un unique jeu de tâches réalisatrices, configuré pour réaliser l’ensemble du ou des traitements asynchrones associés à ladite au moins une tâche initiatrice. Dans un mode de réalisation alternatif, le système informatique comporte plusieurs jeux de tâches réalisatrices, configurés pour, ensemble, réaliser l’ensemble du ou des traitements asynchrones associés à ladite au moins une tâche initiatrice. Par exemple, chaque tâche réalisatrice d’un même jeu est associée à un même niveau d’intégrité de sécurité automobile, différent d’au moins un autre niveau d’intégrité de sécurité automobile associé aux tâches réalisatrices d’au moins un autre jeu de tâches réalisatrices. Par exemple, le système informatique comporte un premier et un second jeux de tâches réalisatrices, les tâches réalisatrices du premier jeu de tâches réalisatrices étant configurées pour réaliser au moins un traitement asynchrone associé à un premier niveau d’intégrité de sécurité automobile, et les tâches réalisatrices du second jeu de tâches réalisatrices étant configurées pour réaliser au moins un traitement asynchrone associé à un second niveau d’intégrité de sécurité automobile différent du premier niveau. Un deuxième aspect de la présente description concerne un procédé de gestion d’un processeur multicœurs configuré pour exécuter des tâches définies statiquement. Dans le procédé décrit ici, lesdites tâches comportent au moins une tâche initiatrice configurée pour initier un ou plusieurs traitements, dont un ou plusieurs traitements asynchrones, et au moins un jeu de tâches réalisatrices comportant au moins deux tâches réalisatrices configurées pour réaliser le ou les mêmes traitements asynchrones, et allouées chacune à un cœur différent du processeur multicœurs. Le procédé comporte les étapes suivantes : lorsqu’un traitement asynchrone donné doit être réalisé, chacune des tâches réalisatrices d’un jeu donné de tâches réalisatrices est activé par la tâche initiatrice ; et le traitement asynchrone donné est réalisé par celle des tâches réalisatrices du jeu donné de tâches réalisatrices qui est prête la première à le réaliser, les autres tâches réalisatrices ignorant le traitement asynchrone donné. Dans un mode de réalisation, chacune des tâches initiatrice et réalisatrices est allouée à un cœur différent du processeur multicœurs. Dans un mode de réalisation, le procédé de gestion d’un processeur multicœurs comporte une génération, par la tâche initiatrice, d’une requête d’initiation du traitement asynchrone donné, et une vérification, par les tâches réalisatrices, avant de réaliser un traitement asynchrone donné, qu’il existe une requête d’initiation du traitement asynchrone donné en attente d’exécution. Dans un mode de réalisation, le procédé de gestion d’un processeur multicœurs comporte, lorsque la tâche initiatrice initie un traitement asynchrone donné, une mise à jour par la tâche initiatrice d’une information représentative d’un nombre de requêtes d’initiation en attente d’exécution pour chaque traitement asynchrone, pour incrémenter le nombre de requêtes d’initiation en attente d’exécution pour le traitement asynchrone donné ; et lorsqu’une tâche réalisatrice donnée réalise le traitement asynchrone donné, une mise à jour de ladite information par la tâche réalisatrice donnée, pour décrémenter le nombre de requêtes d’initiation en attente d’exécution pour le traitement asynchrone donné. Dans un mode de réalisation du procédé de gestion d’un processeur multicœurs, un unique jeu de tâches réalisatrices est configuré pour réaliser l’ensemble du ou des traitements asynchrones associés à ladite au moins une tâche initiatrice. Dans un mode de réalisation alternatif, plusieurs jeux de tâches réalisatrices sont configurés pour, ensemble, réaliser l’ensemble du ou des traitements asynchrones associés à ladite au moins une tâche initiatrice. Autrement dit, les tâches réalisatrices du ou des jeux de tâches réalisatrices sont configurés pour, ensemble, réaliser l’ensemble du ou des traitements asynchrones associés à ladite au moins une tâche initiatrice. Par exemple, chaque tâche réalisatrice d’un même jeu est associée à un même niveau d’intégrité de sécurité automobile, différent d’au moins un autre niveau d’intégrité de sécurité automobile associé aux tâches réalisatrices d’au moins un autre jeu de tâches réalisatrices. Par exemple, un premier et un second jeux de tâches réalisatrices sont configurés, les tâches réalisatrices du premier jeu de tâches réalisatrices étant configurées pour réaliser au moins un traitement asynchrone associé à un premier niveau d’intégrité de sécurité automobile, et les tâches réalisatrices du second jeu de tâches réalisatrices étant configurées pour réaliser au moins un traitement asynchrone associé à un second niveau d’intégrité de sécurité automobile différent du premier niveau. Un troisième aspect de la présente description concerne un programme d’ordinateur comportant des instructions pour la mise en œuvre d’un procédé de gestion d’un processeur multicœurs tel que décrit ci-dessus, lorsqu’il est exécuté par un processeur. Un quatrième aspect de la présente description concerne un véhicule automobile comportant un système informatique à processeur multicœurs tel que décrit ci-dessus. Dans la stratégie d’ordonnancement décrite ici, des tâches principales sont réalisées par un premier cœur, tandis que d’autres tâches, qui ne nécessitent pas d’être synchronisées avec ces tâches principales, sont confiées à un ou plusieurs autres cœurs, optimisant ainsi l’usage des différents cœurs du processeur. Par exemple, cela permet de décharger les cœurs fortement chargés, et/ou d’utiliser des cœurs peu ou pas exploités. Lorsqu’une nouvelle tâche est activée, elle commence à s’exécuter après un certain délai, dit délai d’attente, qui dépend des autres tâches en cours ou en attente d’exécution sur le même cœur et de leur priorité par rapport à celle de la nouvelle tâche. Le système et le procédé décrits ici comportent plusieurs tâches réalisatrices, allouées à des cœurs différents et configurées pour réaliser un même traitement asynchrone. Lorsque le traitement asynchrone est initié par une tâche initiatrice, toutes les tâches réalisatrices correspondantes sont activées. Et le traitement asynchrone est réalisé par celles des tâches réalisatrices qui est prête la première. La solution décrite permet de réaliser une sélection dynamique à l’exécution, du cœur chargé d’exécuter un traitement asynchrone donné, et ce bien que les tâches soient définies statiquement. Cela permet de réduire le délai d’attente au minimum. La tâche initiatrice qui est configurée pour initier le traitement asynchrone peut être associée à un seul ou a plusieurs jeux de tâches réalisatrices. Lorsqu’un seul jeu est utilisé, les tâches de ce jeu sont configurées pour réaliser tous les traitements asynchrones associés à la tâche initiatrice. Lorsque plusieurs jeux sont utilisés, les jeux pris dans leur ensemble doivent permettre de réaliser tous les traitements asynchrones associés à la tâche initiatrice. Mais il est possible que les tâches réalisatrices d’un jeu pris isolément ne puissent réaliser que certains des traitements asynchrones liés à la tâche initiatrice. L’utilisation de plusieurs jeux permet par exemple de gérer des besoins spécifiques liés à certains traitements asynchrones. Par exemple, dans le domaine de l’automobile, les traitements asynchrones liés aux fonctions sécurité d’un véhicule peuvent nécessiter d’être exécutés par des tâches dédiées ayant des propriétés spécifiques. Dans ce cas, on utilise avantageusement un jeu de tâches réalisatrices dédié à la fonction sécurité, et un autre jeu de tâches réalisatrices dédié aux autres fonctions. Brève description des Figures D'autres caractéristiques et avantages apparaîtront au cours de la lecture de la description détaillée qui va suivre pour la compréhension de laquelle on se reportera aux dessins annexés parmi lesquels : FIG. 1 - la FIG. 1 représente un diagramme d’états d’une tâche d’un système informatique tel que décrit ici. FIG. 2 - la FIG. 2 est un schéma représentant le fonctionnement d’une tâche dans un système informatique tel que décrit ici. FIG. 3 - la FIG. 3 est un organigramme représentant un exemple d’étapes mises en œuvre par les tâches initiatrices. FIG. 4 – la FIG. 4 est un organigramme représentant un exemple d’étapes mises en œuvre par les tâches réalisatrices. FIG. 5 – la FIG. 5 est un diagramme représentant un premier exemple de réalisation, avec un seul jeu de tâches réalisatrices. FIG. 6 – la FIG. 6 est un diagramme représentant un deuxième exemple de réalisation, avec deux jeux de tâches réalisatrices. Description détaillée Dans la description qui va suivre, des éléments identiques, similaires ou analogues seront désignés par les mêmes signes de référence. La présente description concerne un système informatique à processeur multicœurs et propose une stratégie d’ordonnancement des tâches permettant de faire exécuter un traitement asynchrone par un cœur différent du cœur qui exécute la tâche initiatrice du traitement asynchrone. Sans que cela soit limitatif, elle s’applique par exemple dans le domaine de l’automobile. Par exemple, un système de contrôle d’un véhicule est configuré pour acquérir des données d’entrée du véhicule, par exemple via des capteurs, et pour réaliser des traitements sur les données acquises afin de définir une réaction du véhicule (freiner, modifier la trajectoire etc.). Ces traitements s’effectuent en général selon une séquence à respecter. On parle alors de traitements synchrones. Le véhicule réalise également des traitements qui peuvent être exécutés indépendamment sans nécessiter un ordre d'exécution strict ou une attente bloquante. C’est par exemple le cas des traitements qui visent à diagnostiquer l’état du véhicule. On parle alors de traitements asynchrones. La présente description s’applique à un système informatique à processeur multicœurs, dans lequel les tâches sont définies statiquement, c’est-à-dire au moment de la configuration du système. Les tâches sont configurées pour appeler des exécutables stockés en mémoire non volatile et qui permettent de réaliser des traitements lorsqu’ils sont exécutés par un cœur du processeur multicœurs. Les tâches ont des propriétés qui sont fixées dans un fichier de configuration statique avant le déploiement du système. Les propriétés d’une tâche comportent notamment une priorité assignée à la tâche de façon fixe, un état initial de la tâche parmi plusieurs états possibles, des ressources matérielles et logicielles nécessaires à l’exécution de la tâche. De façon classique, le système garantit l’ordre d’exécution des tâches en utilisant un mécanisme d’arbitrage à priorité fixe. Comme représenté sur la FIG. 1 , une tâche peut avoir plusieurs états notamment : « suspendu », « prêt », ou « en cours ». Lorsqu’une tâche est activée (étape 100), elle passe de l’état « suspendu » 110 à l’état « prêt » 120. Toutefois, la tâche n’est pas exécutée immédiatement : elle doit attendre que les tâches de plus haute priorité soient terminées. La tâche est ensuite démarrée (étape 130) et passe à l’état « en cours » 140, état pendant lequel elle est exécutée. Lorsque l’exécution est terminée, la tâche repasse à l’état « suspendu » 110 (étape 150). Dans certains systèmes, une tâche de plus haute priorité peut interrompre une tâche de plus faible priorité, selon un mécanisme appelé préemption et représenté sur la FIG. 1 par une flèche 180 allant de l’état « en cours » 140 à l’état « prêt » 120. Comme illustré sur la FIG. 2 , une tâche à l’état « suspendu 110 », passe à l’état « prêt » 120 à la suite d’une activation 100. Elle attend ensuite pendant un délai 210, appelé temps d’attente, avant de passer à l’état « en cours » 140. Le temps 220 qui s’écoule entre l’activation 100 et la fin de l’exécution 150 est appelé temps de réponse. La contrainte de temps à respecter pour l’exécution de la tâche est appelée échéance, et est référencée 240 sur la FIG. 2 . Dans un système temps réel, le temps de réponse 220 doit être inférieur à l’échéance 240 pour respecter les contraintes temps réel. Le temps d’attente 210 avant le début d’exécution de la tâche dépend de plusieurs paramètres, notamment : du temps d’exécution de la tâche en cours, de la stratégie d’ordonnancement utilisée (par exemple, de l’utilisation de mécanismes de préemption par les tâches les plus prioritaires), des éventuelles autres tâches de plus haute priorité déjà activées qui sont dans l’état « prêt », de stimuli extérieurs. Le temps de réponse 220 de la tâche est donc directement dépendant des autres tâches prêtes ou en cours d’exécution sur le même cœur. Cela peut conduire au non-respect de l’échéance et donc au non-respect des contraintes temps-réel du système. Il est donc important de réduire au minimum le temps d’attente 210 de la tâche réalisatrice qui va réaliser un traitement asynchrone. Dans le système et le procédé décrits ici, on définit au moins une tâche initiatrice pour initier un ou plusieurs traitements, dont un ou plusieurs traitements asynchrones, et au moins un jeu de plusieurs tâches réalisatrices configurées pour réaliser le ou les mêmes traitements asynchrones, chacune desdites tâches réalisatrices d’un même jeu étant allouée à un cœur différent du processeur multicœur. La tâche initiatrice est configurée pour activer toutes les tâches réalisatrices d’un jeu donné, lorsqu’un traitement asynchrone donné doit être initié, et les tâches réalisatrices sont configurées de telle sorte que celle des tâches réalisatrices du jeu donné qui est prête la première réalise le traitement asynchrone donné, tandis que la ou les autres tâches réalisatrices du jeu donné ignorent le traitement asynchrone donné. Bien que les tâches soient définies statiquement, le cœur qui offre le temps d’attente le plus court peut ainsi être sélectionné dynamiquement au moment de l’exécution. Pour une tâche initiatrice donnée, les tâches réalisatrices sont dites identiques car elles appellent le ou les mêmes exécutables qui sont stockés en mémoire non-volatile et qui sont exécutés par le cœur sur lequel est lancée la tâche réalisatrice (un ou plusieurs exécutables par traitement asynchrone associé à la tâche initiatrice). Avantageusement, la tâche initiatrice est allouée à un cœur différent des cœurs alloués aux tâches réalisatrices qui lui sont associées. Lorsqu’un seul jeu est configuré, chaque tâche réalisatrice du jeu est configurée pour réaliser tous les traitements asynchrones associés à la ou aux tâches initiatrices susceptibles de l’activer. Lorsque plusieurs jeux sont configurés, les jeux pris dans leur ensemble doivent pouvoir réaliser tous les traitements asynchrones associés à la ou aux tâches initiatrices. Par exemple les tâches réalisatrices peuvent être réparties en deux groupes selon un critère donné (par exemple le type de traitement). Un premier jeu peut être configuré pour réaliser les traitements du premier groupe et un second jeu peut être configuré pour réaliser les traitements du second groupe. Par exemple, dans le domaine automobile, le critère peut être le niveau d’intégrité de sécurité automobile (connu sous l'acronyme ASIL de l’anglais Automotive Safety Integrity Level, il s’agit d’une classification définie par la norme ISO 26262 qui détermine le niveau de risque associé à une défaillance de sécurité dans les systèmes automobiles). Comme indiqué plus haut, la tâche initiatrice est configurée pour activer toutes les tâches réalisatrices d’un jeu donné, lorsqu’un traitement asynchrone donné doit être initié, et les tâches réalisatrices sont configurées de telle sorte que celle des tâches réalisatrices du jeu donné qui est prête la première réalise le traitement asynchrone donné, tandis que la ou les autres tâches réalisatrices du jeu donné ignorent le traitement asynchrone donné. Par exemple, la tâche initiatrice est configurée pour générer une requête d’initiation du traitement asynchrone donné, et les tâches réalisatrices sont configurées pour vérifier, avant de réaliser le traitement asynchrone donné, qu’il existe une requête d’initiation du traitement asynchrone donné en attente d’exécution. Les tâches initiatrice et réalisatrices sont alors par exemple configurées pour gérer une information représentative d’un nombre de requêtes d’initiation en attente d’exécution pour chaque traitement asynchrone. L’information de nombre de requêtes est mise à jour par la tâche initiatrice lorsqu’elle initie un traitement asynchrone donné pour incrémenter le nombre de requêtes d’initiation en attente d’exécution pour le traitement asynchrone donné. Et elle est mise à jour par les tâches réalisatrices lorsqu’elles réalisent le traitement asynchrone donné pour décrémenter le nombre de requêtes d’initiation en attente d’exécution pour le traitement asynchrone donné. Dans un premier mode de réalisation, l’information de nombre de requêtes est constituée par un drapeau et permet donc d’indiquer de façon binaire si une requête d’initiation est en attente d’exécution pour un traitement asynchrone donné. Dans un second mode de réalisation, l’information de nombre de requêtes est constituée par un compteur et permet alors de gérer une pluralité de requêtes d’initiation en attente d’exécution pour un même traitement asynchrone donné. Dans un troisième mode de réalisation, l’information de nombre de requêtes est constituée par une table, et permet ainsi de gérer une pluralité de requêtes d’initiation en attente d’exécution pour une pluralité de traitements asynchrones donnés. En effet une tâche initiatrice peut générer une seconde requête d’initiation d’un même traitement asynchrone alors que la première requête n’est encore exécutée. Ou une tâche initiatrice peut générer une requête d’initiation d’un traitement asynchrone alors qu’une requête d’initiation a déjà été générée par une autre tâche initiatrice pour le même traitement asynchrone. Ou une ou plusieurs tâches initiatrices peuvent générer une requête d’initiation pour différents traitement asynchrones sans que les précédents soient terminés. Sur la FIG. 3 , on a représenté les étapes mises en œuvre par toute tâche initiatrice, c’est-à-dire toute tâche susceptible de demander l’exécution d’un traitement asynchrone. A l’étape 310, la tâche initiatrice incrémente l’information de nombre de requêtes (c’est-à-dire le drapeau, le compteur ou la table dans l’exemple décrit ci-dessus) pour demander une nouvelle exécution du traitement asynchrone. A l’étape 320, elle active toutes les tâches réalisatrices d’un jeu donné de tâches réalisatrices. Sur la FIG. 4 , on a représenté les étapes mises en œuvre dans toute tâche réalisatrice, c’est-à-dire toute tâche susceptible de réaliser le traitement asynchrone demandé. A l’étape 410, la tâche réalisatrice est dans l’état « en cours ». Elle lit l’information de nombre de requêtes pour vérifier qu’il existe une requête d’initiation de traitement asynchrone en attente d’exécution. S’il en existe une (drapeau actif, compteur positif, valeur positive dans une cellule de la table dans l’exemple décrit ci-dessus), à l’étape 420, la tâche réalisatrice se positionne pour exécuter cette requête en décrémentant l’information de nombre de requêtes correspondante. Puis à l’étape 430, la tâche réalisatrice exécute ensuite le traitement asynchrone. Si au contraire, il n’y a aucune requête d’initiation en attente d’exécution, la tâche réalisatrice se termine sans rien faire. Le FIG. 5 est un diagramme décrivant un premier exemple de réalisation avec deux tâches initiatrices 501 et 502 associées à un seul jeu de trois tâches réalisatrices 511, 512 et 513. La tâche initiatrice 501 est configurée pour initier un traitement asynchrone T1. La tâche initiatrice 502 est configurée pour initier un traitement asynchrone T2. Les trois tâches réalisatrices 511, 512 et 513 appellent le même exécutable ER qui est capable de réaliser les deux traitements asynchrones T1 et T2. Les exécutables qui réalisent les traitements de la première et de la second tâche initiatrice 501 et 502 sont référencés EI1 et EI2 respectivement. La première et la seconde tâche initiatrice 501 et 502 sont allouées respectivement à un premier et à un second cœur 521 et 522 du processeur multicœurs. Les trois tâches réalisatrices 511, 512 et 513 sont allouées respectivement à un troisième, un quatrième et un cinquième cœur du processeur multicœurs, référencés 523, 524 et 525. Comme illustré sur la FIG. 5 , à l’étape 540, la tâche initiatrice 501 appelle l’exécutable EI1 pour initier le traitement asynchrone T1. Une instance 541 de l’exécutable EI1 incrémente l’information de nombre de requêtes relative au traitement asynchrone T1, et active le jeu de tâches réalisatrices 511, 512 et 513. Dans l’exemple décrit sur la FIG. 5 , la tâche réalisatrice 511 est prête la première. Elle appelle donc l’exécutable ER. Une instance 542 de l’exécutable ER vérifie l’information de nombre de requêtes, constate que le traitement asynchrone T1 est en attente d’exécution, décrémente l’information de nombre de requêtes correspondant au traitement T1, et exécute le traitement T1. Lorsque les tâches réalisatrices 512 et 513 sont prêtes à leur tour, elles appellent l’exécutable ER. Deux nouvelles instances de l’exécutable ER, référencées 543 et 544 respectivement, vérifient l’information de nombre de requêtes, constatent qu’aucun traitement asynchrone n’est en attente d’exécution et se terminent. A l’étape 550, la tâche initiatrice 502 appelle l’exécutable EI2 pour initier le traitement asynchrone T2. Une instance 551 de l’exécutable EI1 incrémente l’information de nombre de requêtes relative au traitement asynchrone T2, et active le jeu de tâches réalisatrices 511, 512 et 513. La tâche réalisatrice 512 est prête la première. Elle appelle donc l’exécutable ER. Une instance 553 de l’exécutable ER vérifie l’information de nombre de requêtes, constate que le traitement asynchrone T2 est en attente d’exécution, décrémente l’information de nombre de requêtes correspondant au traitement T2, et exécute le traitement T2. Lorsque les tâches réalisatrices 511 et 513 sont prêtes à leur tour, elles appellent l’exécutable ER. Deux nouvelles instances de l’exécutable ER, référencées 552 et 554 respectivement, vérifient l’information de nombre de requêtes, constatent qu’aucun traitement asynchrone n’est en attente d’exécution (le traitement T1 a été exécuté par le tâche réalisatrice 511 et le traitement T2 a été exécuté ou est en cours d’exécution par la tâche réalisatrice 512) et se terminent. A l’étape 560, la tâche initiatrice 501 appelle de nouveau l’exécutable EI1 pour initier le traitement asynchrone T1. Une instance 561 de l’exécutable EI1 incrémente l’information de nombre de requêtes relative au traitement asynchrone T1, et active le jeu de tâches réalisatrices 511, 512 et 513. La tâche réalisatrice 513 est prête la première. Elle appelle donc l’exécutable ER. Une instance 564 de l’exécutable ER vérifie l’information de nombre de requêtes, constate que le traitement asynchrone T1 est en attente d’exécution, décrémente l’information de nombre de requêtes correspondant au traitement T1, et exécute le traitement T1. Lorsque les tâches réalisatrices 511 et 512 sont prêtes à leur tour, elles appellent l’exécutable ER. Deux nouvelles instances de l’exécutable ER, référencées 562 et 563 respectivement, vérifient l’information de nombre de requêtes, constatent qu’aucun traitement asynchrone n’est en attente d’exécution et se terminent. Dans l’exemple de la FIG. 5 , l’information de nombre de requêtes est une table [n1 ; n2], où n1 est le nombre de requêtes en cours pour le traitement asynchrone T1 et n2 est le nombre de requêtes en cours pour le traitement asynchrone T2. L’exécutable EI1 incrémente la valeur de n1, l’exécutable EI2 incrémente la valeur de n2, et l’exécutable ER décrémente la valeur de n1 avant d’exécuter le traitement T1 et la valeur de n2 avant d’exécuter le traitement T2. Le FIG. 6 est un diagramme décrivant un deuxième exemple de réalisation avec deux tâches initiatrices 601 et 602. La tâche initiatrice 601 est configurée pour initier un traitement asynchrone T1 et elle est associée à un premier jeu 606 de trois tâches réalisatrices 611, 612 et 613. La tâche initiatrice 602 est configurée pour initier un traitement asynchrone T2 et elle est associée à un deuxième jeu 608 de deux tâches réalisatrices 614 et 615. Les trois tâches réalisatrices 611, 612 et 613 appellent un même exécutable ER1 qui est capable de réaliser le traitement asynchrone T1. Les deux tâches réalisatrices 614 et 615 appellent un même exécutable ER2 qui est capable de réaliser le traitement asynchrone T2. Les exécutables qui réalisent les traitements de la première et de la second tâche initiatrice 601 et 602 sont référencés EI1 et EI2 respectivement sur la FIG. 6 . La première et la seconde tâche initiatrice 601 et 602 sont allouées respectivement à un premier et à un second cœur 621 et 622 du processeur multicœurs. La tâche réalisatrice 611 est allouée à un troisième cœur 623 du processeur multicœurs. Les deux tâches réalisatrices 612 et 614 sont allouées à un quatrième cœur 624 du processeur multicœurs. Et les deux tâches réalisatrices 613 et 615 sont allouées à un cinquième cœur 625 du processeur multicœurs. Comme illustré sur la FIG. 6 , à l’étape 640, la tâche initiatrice 601 appelle l’exécutable EI1 pour initier le traitement asynchrone T1. Une instance 641 de l’exécutable EI1 incrémente l’information de nombre de requêtes relative au traitement asynchrone T1, et active les tâches réalisatrices 611, 612 et 613 du premier jeu de tâches réalisatrices 606. Dans l’exemple décrit sur la FIG. 6 , la tâche réalisatrice 611 est prête la première. Elle appelle donc l’exécutable ER1. Une instance 642 de l’exécutable ER1 vérifie l’information de nombre de requêtes, constate que le traitement asynchrone T1 est en attente d’exécution, décrémente l’information de nombre de requêtes correspondant au traitement T1, et exécute le traitement T1. Lorsque les tâches réalisatrices 612 et 613 sont prêtes à leur tour, elles appellent l’exécutable ER1. Deux nouvelles instances de l’exécutable ER1, référencées 643 et 644 respectivement, vérifient l’information de nombre de requêtes, constatent qu’aucun traitement asynchrone n’est en attente d’exécution et se terminent. A l’étape 650, la tâche initiatrice 602 appelle l’exécutable EI2 pour initier le traitement asynchrone T2. Une instance 651 de l’exécutable EI2 incrémente l’information de nombre de requêtes relative au traitement asynchrone T2, et active les tâches réalisatrices 614 et 615 du deuxième jeu de tâches réalisatrices 608. La tâche réalisatrice 614 est prête la première. Elle appelle donc l’exécutable ER2. Une instance 652 de l’exécutable ER2 vérifie l’information de nombre de requêtes, constate que le traitement asynchrone T2 est en attente d’exécution, décrémente l’information de nombre de requêtes correspondant au traitement T2, et exécute le traitement T2. Lorsque la tâche réalisatrice 615 est prête à son tour, elle appelle l’exécutable ER2. Une nouvelle instance 653 de l’exécutable ER2, vérifie l’information de nombre de requêtes, constate qu’aucun traitement asynchrone n’est en attente d’exécution (le traitement T1 a été exécuté par le tâche réalisatrice 611 et le traitement T2 a été exécuté ou est en cours d’exécution par la tâche réalisatrice 614) et se terminent. Dans l’exemple de la FIG. 6 , l’information de nombre de requêtes est une table [n1 ; n2], où n1 est le nombre de requêtes en cours pour le traitement asynchrone T1 et n2 est le nombre de requêtes en cours pour le traitement asynchrone T2. L’exécutable EI1 incrémente la valeur de n1, l’exécutable EI2 incrémente la valeur de n2, l’exécutable ER1 décrémente la valeur de n1 avant d’exécuter le traitement T1 et l’exécutable ER2 décrémente la valeur de n2 avant d’exécuter le traitement T2. Les schémas fonctionnels présentés ici représentent des vues conceptuelles données à titre d’exemple non limitatif pour illustrer les principes de la présente divulgation. Ces principes peuvent être implémentés dans des dispositifs présentant de multiples variantes. La terminologie utilisée ici a pour seul but de décrire des modes de réalisation particuliers et n'est pas limitative. Notamment, les termes "comprend", "comprenant", "inclut" et/ou "incluant", spécifient la présence de caractéristiques, d'étapes, d'opérations, d'éléments et/ou de composants donnés, mais n'excluent pas la présence ou l'ajout d'une ou plusieurs autres caractéristiques, étapes, opérations, éléments, composants. Système informatique à processeur multicœurs configuré pour activer des tâches définies statiquement, lesdites tâches comportant : - au moins une tâche initiatrice (501, 601, 602) configurée pour initier un ou plusieurs traitements, dont un ou plusieurs traitements asynchrones, et - au moins un jeu de tâches réalisatrices (511, 512, 513, 611, 612, 613, 614, 615), comportant au moins deux tâches réalisatrices configurées pour réaliser le ou les mêmes traitements asynchrones, et allouées chacune à un cœur différent du processeur multicœur, la tâche initiatrice étant configurée pour activer les tâches réalisatrices d’un jeu donné de tâches réalisatrices, lorsqu’un traitement asynchrone donné doit être initié (310, 320), et les tâches réalisatrices étant configurées de telle sorte que celle des tâches réalisatrices du jeu donné de tâches réalisatrices qui est prête la première réalise le traitement asynchrone donné, tandis que la ou les autres tâches réalisatrices du jeu donné de tâches réalisatrices ignorent le traitement asynchrone donné (410, 420, 430, 440). Système informatique à processeur multicœurs selon la revendication 1, caractérisé en ce que chacune des tâches initiatrice (501, 601, 602) et réalisatrices (511, 512, 513, 611, 612, 613, 614, 615) est allouée à un cœur différent du processeur multicœurs. Système informatique à processeur multicœurs selon l’une des revendications 1 ou 2, caractérisé en ce qu’il comporte un unique jeu de tâches réalisatrices (511, 512, 513), configuré pour réaliser l’ensemble du ou des traitements asynchrones associés à ladite au moins une tâche initiatrice. Système informatique à processeur multicœurs selon l’une des revendications 1 ou 2, caractérisé en ce qu’il comporte plusieurs jeux de tâches réalisatrices (611, 612, 613, et 614, 615), configurés pour, ensemble, réaliser l’ensemble du ou des traitements asynchrones associés à ladite au moins une tâche initiatrice (601, 602). Système informatique à processeur multicœurs selon la revendication 4, caractérisé en ce que chaque tâche réalisatrice (611, 612, 613, et 614, 615) d’un même jeu est associée à un même niveau d’intégrité de sécurité automobile, différent d’au moins un autre niveau d’intégrité de sécurité automobile associé aux tâches réalisatrices (614, 615 et 611, 612, 613) d’au moins un autre jeu de tâches réalisatrices. Système informatique à processeur multicœurs selon la revendication 5, caractérisé en ce qu’il comporte un premier (611, 612, 613) et un second (614, 615) jeux de tâches réalisatrices, les tâches réalisatrices du premier jeu de tâches réalisatrices (611, 612, 613) étant configurées pour réaliser au moins un traitement asynchrone associé à un premier niveau d’intégrité de sécurité automobile, et les tâches réalisatrices du second jeu de tâches réalisatrices (614, 615) étant configurées pour réaliser au moins un traitement asynchrone associé à un second niveau d’intégrité de sécurité automobile différent du premier niveau. Système informatique à processeur multicœurs selon l’une des revendications 1 à 6, caractérisé en ce que la tâche initiatrice (501, 601, 602) est configurée pour générer une requête d’initiation du traitement asynchrone donné, et les tâches réalisatrices sont configurées pour vérifier, avant de réaliser le traitement asynchrone donné, qu’il existe une requête d’initiation du traitement asynchrone donné en attente d’exécution (410). Système informatique à processeur multicœurs selon l’une des revendications 1 à 7, caractérisé en ce que les tâches initiatrice (501, 601, 602) et réalisatrices (611, 612, 613, et 614, 615) sont configurées pour gérer une information représentative d’un nombre de requêtes d’initiation en attente d’exécution pour chaque traitement asynchrone, ladite information étant mise à jour d’une part, par la tâche initiatrice lorsqu’elle initie un traitement asynchrone donné pour incrémenter le nombre de requêtes d’initiation en attente d’exécution pour le traitement asynchrone donné (310), et d’autre part, par les tâches réalisatrices lorsqu’elles réalisent le traitement asynchrone donné pour décrémenter le nombre de requêtes d’initiation en attente d’exécution pour le traitement asynchrone donné (420). Procédé de gestion d’un processeur multicœurs configuré pour exécuter des tâches définies statiquement, lesdites tâches comportant au moins une tâche initiatrice (501, 601, 602) configurée pour initier un ou plusieurs traitements, dont un ou plusieurs traitements asynchrones, et au moins un jeu de tâches réalisatrices (611, 612, 613, et 614, 615) comportant au moins deux tâches réalisatrices configurées pour réaliser le ou les mêmes traitements asynchrones, et allouées chacune à un cœur différent du processeur multicœurs, ledit procédé comportant les étapes suivantes : lorsqu’un traitement asynchrone donné doit être réalisé, une activation (320) de chacune des tâches réalisatrices d’un jeu donné de tâches réalisatrices par la tâche initiatrice, une réalisation (430) du traitement asynchrone donné par celle des tâches réalisatrices du jeu donné de tâches réalisatrices qui est prête la première à le réaliser, les autres tâches réalisatrices ignorant le traitement asynchrone donné. Procédé selon la revendication 9, caractérisé en ce que chacune des tâches initiatrice (501, 601, 602) et réalisatrices (611, 612, 613, et 614, 615) est allouée à un cœur différent du processeur multicœurs. Procédé selon l’une des revendications 9 ou 10, dans lequel les tâches réalisatrices (611, 612, 613, et 614, 615) du ou des jeux de tâches réalisatrices sont configurés pour, ensemble, réaliser l’ensemble du ou des traitements asynchrones associés à ladite au moins une tâche initiatrice. Procédé selon l’une des revendications 9 à 11, caractérisé en ce qu’il comporte une génération, par la tâche initiatrice (501, 601, 602), d’une requête d’initiation du traitement asynchrone donné, et une vérification, par les tâches réalisatrices (611, 612, 613, et 614, 615), avant de réaliser un traitement asynchrone donné, qu’il existe une requête d’initiation du traitement asynchrone donné en attente d’exécution. Procédé selon l’une des revendications 9 à 12 caractérisé en ce qu’il comporte : lorsque la tâche initiatrice initie un traitement asynchrone donné, une mise à jour par la tâche initiatrice d’une information représentative d’un nombre de requêtes d’initiation en attente d’exécution pour chaque traitement asynchrone, pour incrémenter le nombre de requêtes d’initiation en attente d’exécution pour le traitement asynchrone donné (310), lorsqu’une tâche réalisatrice donnée réalise le traitement asynchrone donné, une mise à jour de ladite information par la tâche réalisatrice donnée, pour décrémenter le nombre de requêtes d’initiation en attente d’exécution pour le traitement asynchrone donné (420). Programme d’ordinateur comportant des instructions pour la mise en œuvre d’un procédé selon les revendications 9 à 13 lorsqu’il est exécuté par un processeur. Véhicule automobile comportant un système informatique à processeur multicœurs selon l’une des revendications 1 à 8.