FR 3061327 A1 20180629 FR 1601859 A 20161226 1 PROCEDE DE CONTROLE D'UN PROCESSEUR MULTI-COEURS ET CALCULATEUR ASSOCIE L'invention vise le domaine des calculateurs à processeur multi-coeurs comprenant plusieurs coeurs physiquement distincts partageant des ressources matérielles communes. Chaque coeur d'un processeur multi-coeurs est une unité de calcul physiquement distincte des autres coeurs. La présence de plusieurs coeurs permet l'exécution en parallèle de plusieurs applications logicielles, afin d'offrir de meilleures performances globales. Pour l'exécution des applications logicielles, les coeurs utilisent des ressources matérielles communes. Ces ressources communes sont par exemple des mémoires, notamment une mémoire principale, un réseau d'interconnexion, des interfaces entrée/sortie (ou interface I/O) du calculateur (Bus rapide PCIe ou Réseau Ethernet par exemple) ou encore une interface d'interconnexion entre les coeurs et ces différentes ressources matérielles communes. Les coeurs peuvent exécuter simultanément plusieurs applications logicielles de manière concurrente, chaque coeur exécutant une ou plusieurs applications logicielles. Cette concurrence entraîne une incertitude dans le temps de traitement des données par le processeur multi-coeurs. Par exemple, lorsqu'une mémoire principale doit répondre à plusieurs transactions émises par les applications logicielles en même temps, il est courant que les transactions soient traitées séquentiellement, ce qui entraîne des retards dans l'exécution de certaines applications logicielles. De tels conflits sont nommés « interférences ». Du point de vue de l'application logicielle, les interférences ralentissent le temps de réponse des ressources matérielles communes, ce qui entraine à son tour des retards dans l'exécution de l'application logicielle. Ces retards peuvent constituer la majorité du temps d'exécution de l'application logicielle. Or, la plupart des systèmes électroniques embarqués tels que ceux utilisés dans le domaine avionique, le domaine spatial ou le domaine ferroviaire, ont besoin de déterminisme dans la durée des traitements pour satisfaire des contraintes de certification. Un autre problème rencontré dans l'industrie est celui du processus d'intégration du calculateur et des applications logicielles prévues pour être exécutées par le calculateur, qui est généralement itératif. Des interférences peuvent apparaitre au cours du processus d'intégration itératif, entraînant une dégradation subite des performances à 3061327 2 une étape du processus d'intégration, remettant en cause les étapes précédentes du processus d'intégration. Un des buts de l'invention est de proposer un procédé de contrôle d'un processeur multi-coeurs implémentant un procédé de contrôle efficace, permettant une bonne 5 utilisation des ressources matérielles communes tout en assurant un bon niveau de déterminisme dans la durée de traitement des données. A cet effet, l'invention propose un procédé de contrôle d'un processeur multicoeurs comprenant plusieurs coeurs physiquement distincts partageant au moins une ressource matérielle commune selon une politique de partage basée sur des fenêtres 10 temporelle distinctes, chaque fenêtre temporelle étant allouée à un ou plusieurs coeurs pour l'accès à une ressource matérielle commune, le procédé de contrôle comprenant : - l'anticipation d'une requête devant être émise par une application logicielle exécutée par un coeur et nécessitant une transaction entre ce coeur et la ressource commune, avant l'émission effective de cette requête par l'application logicielle ; 15 - la planification de la transaction dans une fenêtre temporelle à venir allouée audit coeur pour l'accès à la ressource commune ; - la réalisation de la transaction planifiée dans la fenêtre temporelle et le chargement des données dans une mémoire cache privée dudit coeur ; et - la restitution des données à l'application logicielle à partir de la mémoire cache 20 privée à l'émission effective de la requête par l'application logicielle. Le procédé de contrôle peut comprend en option une ou plusieurs des caractéristiques optionnelles suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles : - le coeur poursuit l'exécution de l'application logicielle à partir de la mémoire 25 cache privée entre la planification de la transaction et la réalisation de la transaction ; - le déclenchement des étapes d'anticipation et de planification à l'émission d'un appel système par l'application logicielle ; - le déclenchement des étapes d'anticipation et de planification au déclenchement d'un défaut de page provoqué par l'émission d'une requête émise nécessitant une 30 transaction entre ledit coeur et la ressource commune pour servir la requête émise, la requête anticipée étant distincte de la requête émise ; - la requête anticipée est planifiée après la requête émise ; - le déclenchement d'une exception provoqué par une requête émise par l'application logicielle ; 3061327 3 - les étapes d'anticipation et de planification sont réalisées par un contrôleur d'accès logiciel configuré pour la mise en oeuvre de la politique de partage des ressources communes ; et - la requête anticipée est déterminée en détectant une séquence de requêtes 5 précédentes ayant nécessité une transaction, et en comparant la séquence de requêtes détectée aux séquences de requêtes caractéristiques prédéfinies, chacune associée à une requête anticipée prédéfinie. L'invention concerne également un calculateur comprenant un processeur multicoeurs possédant plusieurs coeurs physiquement distincts et au moins une ressource 10 matérielle commune partagée par les coeurs et accessible aux coeurs selon une politique de partage basée sur des fenêtres temporelles distinctes, chaque fenêtre temporelle étant allouée à un ou plusieurs coeurs pour l'accès à la ressource matérielle commune, dans lequel au moins un contrôleur d'accès logiciel pour le contrôle des transactions entre un coeur et la ressource matérielle commune et/ou un application logicielle implémentés sur 15 le coeur sont configurés pour la mise en oeuvre d'un procédé de contrôle tel que défini ci- dessus. L'invention et ses avantages seront mieux compris à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple, et faite en référence aux dessins annexés, sur lesquels : 20 - la Figure 1 est une vue schématique d'un calculateur d'un système avionique embarqué, le calculateur comprenant un processeur multi-coeurs possédant plusieurs coeurs partageant des ressources communes ; - les Figures 2 à 4 sont des frises temporelles illustrant des partitions temporelles de partage des ressources communes. 25 Sur la Figure 1, un système avionique 2 embarqué dans un aéronef 4 possède un calculateur 6 possédant un processeur 8 multi-coeurs comprenant plusieurs coeurs 10, des ressources communes 12 partagées par les coeurs 10, et une interconnexion 14 électronique par l'intermédiaire de laquelle les coeurs 10 accèdent aux ressources communes 12. 30 Les coeurs 10 sont physiquement distincts. Chaque coeur 10 est une unité de calcul individuelle comprenant ses propres composants électroniques, distincts de ceux des autres coeurs 10. Les ressources communes 12 sont des ressources matérielles partagées par les coeurs 10. Les ressources communes 12 sont par exemple des mémoires, telles qu'une 35 mémoire principale, une mémoire cache partagée (par exemple une mémoire de niveau 2 dite Cache L2 ou de niveau 3 dite Cache L3), ou des interfaces entrée/sortie (ou interface 3061327 4 I/O). Une interface entrée/sortie permet d'émettre ou de recevoir des signaux sur un bus de communication (non représenté), par exemple un bus de communication du système avionique pour une communication entre plusieurs calculateurs ou entre les calculateurs et des sondes de mesure ou des actuateurs. 5 L'interconnexion 14 est par exemple un bus d'interconnexion. De préférence, tous les coeurs 10 du processeur 8 sont reliés aux ressources communes 12 par l'intermédiaire du même et unique moyen formé par l'interconnexion 14. Chaque coeur 10 est apte à exécuter une ou plusieurs applications logicielles utiles, de préférence sous le contrôle d'un système d'exploitation informatique (ou « OS » 10 pour « Operating System » en anglais), qui est une application logicielle particulière exécutée par le coeur 10 et qui contrôle l'utilisation des ressources logicielles ou matérielles accessibles à ce coeur 10 (y compris les ressources communes 12) par les applications logicielles utiles. Dans la suite, le terme « application logicielle AP » désigne les applications logicielles utiles ou le système d'exploitation informatique exécuté(e)s par 15 un cceur 10. Lors de son exécution, une application logicielle AP exécutée par un coeur 10 excite le coeur 10 qui génère des requêtes qui sont traitées par le coeur 10. Une requête correspond généralement à une demande de lecture ou d'écriture à une adresse déterminée de l'espace mémoire adressable. 20 Chaque coeur 10 possède une mémoire cache privée 16, qui est utilisée exclusivement par ce coeur 10, et qui est physiquement intégrée au coeur 10. La mémoire cache privée 16 est utilisée pour le stockage de données chargée à partir des ressources communes 12 et susceptibles d'être requises par les applications logicielles AP exécutées par le coeur 10. 25 Si les données correspondant à une requête émise par une application logicielle AP sont présentes dans la mémoire cache privée 16, la requête peut être traitée au niveau du coeur 10 sans générer d'accès à la ressource commune 12. Si les données correspondant à une requête émise par une application logicielle AP ne sont pas présentes dans la mémoire cache privée 16, il convient que le coeur 10 30 réalise une transaction avec une ressource commune 12 pour charger les données et en stocker une copie dans la mémoire cache privée 16. Dans la suite, une « transaction » désigne un échange de données entre un coeur 10 déterminé et une ressource commune 12 déterminée. Dans un mode de réalisation, chaque coeur 10 comprend un contrôleur d'accès 18 35 logiciel pour contrôler l'accès de ce coeur 10 aux ressources communes 12. 3061327 5 Le contrôleur d'accès 18 est une couche logicielle interposée entre les applications exécutées par le coeur 10 (y compris un système d'exploitation exécuté par le coeur 10) et le coeur 10 lui-même. Le contrôleur d'accès 18 est un programme informatique qui comprend des instructions de codes propres à ce programme. Le contrôleur d'accès 18 5 est par exemple intégré dans un hyperviseur. Le coeur 10 exécute son propre contrôleur d'accès 18 localement, sans faire appel aux ressources communes 12. Le contrôleur d'accès 18 comprend des instructions de code qui sont entièrement stockées dans la mémoire cache privée 16 du coeur 10 et exécutables en utilisant uniquement la mémoire cache privée 16 de ce coeur 10. 10 La mémoire cache privée 16 du coeur 10 possède une capacité suffisante pour l'exécution du contrôleur d'accès 18. L'exécution du contrôleur d'accès 18 par le coeur 10 ne nécessite donc pas l'émission de transactions vers la ressource commune 12, susceptibles d'interférer avec l'activité des autres coeurs 10 dans les ressources communes 12. 15 Le contrôleur d'accès 18 de chaque coeur 10 est configuré pour intercepter chaque requête adressée au coeur 10 par l'application logicielle AP exécutée par ce coeur 10 et nécessitant une transaction correspondante par le coeur 10 vers la ressource commune 12, et pour planifier la transaction. Dans un mode de réalisation, les données stockées dans la mémoire cache privée 20 16 sont organisées en pages de données, et le coeur 10 est configuré pour déclencher un défaut de page en cas d'absence de données associées à une requête dans la mémoire cache privée 16. Le contrôleur d'accès 18 est alors par exemple configuré pour s'exécuter lors d'un défaut de page déclenché par l'émission d'une requête d'une application logicielle AP 25 exécutée par le coeur 10 visant des données non présentes dans la mémoire cache privée 16 du coeur 10. Lors de l'exécution des applications logicielles AP par les coeurs 10, les coeurs 10 sont en concurrence pour l'utilisation des ressources communes 12. Or, chaque transaction entre un coeur 10 déterminé et une ressource commune 12 déterminée doit 30 être effectuée avec un coût temporel borné. Le partage de ressources communes 12 par plusieurs coeurs 10 nécessite donc de définir une politique de partage de ressources communes 12, c'est-à-dire un ensemble de règles restreignant l'activité concurrente des différents coeurs 10 dans les ressources communes 12. 3061327 6 Le contrôleur d'accès 18 de chaque coeur 10 est configuré pour réaliser les transactions nécessaires en mettant en oeuvre la politique de partage des ressources communes 12. Le procédé de contrôle met en oeuvre une politique de partage d'au moins une 5 ressource commune 12 basée sur des fenêtres temporelles F distinctes, chaque fenêtre temporelle F étant allouée à un ou plusieurs coeurs 10 spécifiques pour l'accès à la ressource commune 12. Seuls les coeurs 10 auxquels est allouée une fenêtre temporelle F sont autorisés à accéder à la ressource commune 12 pendant cette fenêtre temporelle F. 10 Dans un mode de réalisation, chaque fenêtre temporelle F est allouée exclusivement à un seul coeur 10. Ainsi, les requêtes émises par les coeurs aux ressources communes 12 seront isolées temporellement. Cette politique de partage des ressources matérielles est du type accès multiple à partition temporelle (ou TDMA pour Time Division Multiple Access). En variante, au moins une fenêtre temporelle F est 15 allouée à plusieurs coeurs 10. La Figure 2 illustre un procédé de contrôle selon l'art antérieur. Des fenêtres temporelles F sont allouées à un coeur 10 pour l'accès à une ressource commune 12. Les périodes hachurées correspondent à l'exécution de l'application logicielle AP 20 par le coeur 10 à partir de la mémoire cache privée 16, et les périodes blanches intermédiaires correspondent à des interruptions de l'exécution de l'application logicielle AP, lorsqu'une donnée n'est pas disponible dans la mémoire cache privée 16. Une application logicielle AP est exécutée par défaut à partir de la mémoire cache privée 16 du coeur 10 (première période hachurée sur la Figure 2). L'application logicielle 25 AP émet en cours de fonctionnement des requêtes qui sont servies à partir de la mémoire cache privée 16. A un instant T, l'application logicielle AP émet une requête d'accès à des données qui ne sont pas disponibles dans la mémoire cache privée 16 et qui nécessite donc une transaction entre le coeur 10 et la ressource commune 12 pour charger ces données dans 30 la mémoire cache privée 16 et restituer ces données à l'application logicielle AP. La requête est émise à un instant T situé hors d'une fenêtre temporelle F allouée au coeur 10 pour l'accès à la ressource commune 12. Le coeur 10 doit alors analyser la requête, attendre la prochaine fenêtre temporelle F allouée au coeur 10 pour l'accès à la ressource commune 12 pour réaliser la transaction avec la ressource commune 12, et 35 récupérer les données correspondant à la requête de l'application logicielle AP (périodes blanches sur la Figure 2). 3061327 7 Une fois les données récupérées et chargées dans la mémoire cache privée 16, l'exécution de l'application logicielle AP à partir de la mémoire cache privée 16 reprend (deuxième période hachurée sur la Figure 2). L'exécution de l'application logicielle AP est interrompue pendant l'analyse de la requête, l'attente de la prochaine fenêtre temporelle F et la réalisation de la transaction. La durée entre l'émission de la requête par l'application logicielle AP et la restitution des données à l'application logicielle AP comprend la durée d'analyse de la requête, la durée d'attente de la prochaine fenêtre temporelle F allouée au coeur 10 pour l'accès à la ressource commune 12 et la durée de la transaction. La durée d'attente d'une fenêtre 10 temporelle F peut constituer la majorité du temps d'exécution d'une application logicielle. Le procédé de contrôle décrit ici est déterministe, mais inefficace. Le procédé de contrôle selon l'invention, illustré sur la Figure 3, vise à optimiser le temps d'accès à au moins une ressource commune 12. Il permet l'utilisation de certaines fenêtres temporelles F en avance de phase - et sans durée d'attente - par rapport à 15 l'exécution de l'application logicielle EP. Le procédé de contrôle comprend : - l'anticipation d'une requête devant être émise par une application logicielle AP exécutée par le coeur 10 et nécessitant une transaction avec la ressource commune 12, avant l'émission effective de cette requête par l'application logicielle ; 20 - la planification de la transaction dans une fenêtre temporelle F allouée au coeur 10 pour l'accès à la ressource commune 12 et dans laquelle aucune transaction n'est planifiée ; - la réalisation de la transaction planifiée dans la fenêtre temporelle F et le chargement des données dans la mémoire cache privée 16 du coeur 10 ; et 25 - la restitution des données à l'application logicielle AP à partir de la mémoire cache privée 16 à l'émission effective de la requête par l'application logicielle AP. De préférence, la transaction est planifiée dans une fenêtre temporelle F libre, dans laquelle aucune transaction n'a encore été planifiée. Il est souhaitable que la transaction soit planifiée dans une fenêtre temporelle F 30 qui soit antérieure à l'émission effective de la requête par l'application logicielle AP. De préférence, la transaction est planifiée dans la prochaine fenêtre temporelle libre dans laquelle aucune transaction n'a encore été planifiée. Comme illustré sur la Figure 3, l'anticipation de la requête à un instant TA situé avant une fenêtre temporelle F inutilisée par le coeur 10 pour accéder à la ressource 35 commune 12 permet de charger les données dans la mémoire cache privée 16 pendant une fenêtre temporelle F qui serait restée inutilisée par le coeur 10, et la restitution des 3061327 8 données pour l'exécution de l'application logicielle à l'émission effective de la requête par l'application logicielle AP, à l'instant T d'émission de la requête. En outre, comme illustré sur la Figure 3, la transaction est planifiée lorsque l'émission de la requête est anticipée, et l'exécution de l'application logicielle AP par le 5 coeur 10 à partir de la mémoire cache privée 16 est poursuivie entre la planification et la fenêtre temporelle F pendant laquelle la transaction est planifiée. Etant donné que la transaction est anticipée et n'est pas encore nécessaire pour l'exécution de l'application logicielle AP, l'exécution de l'application logicielle AP peut être poursuivie. Les données sont alors disponibles dès l'émission effective de la requête par 10 l'application logicielle AP. Il en résulte que la durée d'exécution de l'application logicielle AP est fortement réduite. Ainsi, comme illustré sur la Figure 3, la restitution des données est effectuée immédiatement après l'émission de la requête par l'application logicielle. En option, comme illustré sur la Figure 4, le procédé de contrôle comprend l'éviction des données de la mémoire cache privée 16 pendant la fenêtre temporelle 15 pendant laquelle est réalisée la transaction anticipée. L'éviction de données est une transaction d'écriture des données évincées de la mémoire cache privée 16 dans la ressource commune 12. Ces données évincées ont éventuellement été modifiées entretemps par l'application logicielle AP. Ceci permet d'exploiter au mieux la fenêtre temporelle qui serait restée inutilisée 20 par le coeur 10 pour accéder à la ressource commune en évitant d'attendre une fenêtre F lors de l'émission de la requête par l'application logicielle AP. Dans un mode de réalisation, le coeur 10 comprend un contrôleur d'accès 18 logiciel pour contrôler l'accès de ce coeur 10 à la ressource commune 12. Le contrôleur d'accès 18 est une couche logicielle interposée entre les applications exécutées par le 25 coeur 10 (y compris un système d'exploitation exécuté par le coeur 10) et le coeur 10 lui- même. Le contrôleur d'accès 18 est un programme informatique qui comprend des instructions de codes propres à ce programme. Le contrôleur d'accès 18 est par exemple un hyperviseur. Le coeur 10 exécute son propre contrôleur d'accès 18 localement, sans faire appel 30 à la ressource commune 12. Le contrôleur d'accès 18 comprend des instructions de code qui sont entièrement stockées dans la mémoire cache privée 16 du coeur 10 et exécutables en utilisant uniquement la mémoire cache privée 16 de ce coeur 10. La mémoire cache privée 16 du coeur 10 possède une capacité suffisante pour l'exécution du contrôleur d'accès 18. L'exécution du contrôleur d'accès 18 par le coeur 10 35 ne nécessite donc pas l'émission de transactions vers la ressource commune 12, 3061327 9 susceptibles d'interférer avec l'activité des autres coeurs 10 dans les ressources communes 12. Le contrôleur d'accès 18 de chaque coeur 10 est configuré pour intercepter chaque requête adressée au coeur 10 par l'application logicielle AP exécutée par ce coeur 10 conduisant à l'émission éventuelle d'une transaction correspondante par le coeur 10 vers la ressource commune 12, et, le cas échéant, pour commander l'émission de la transaction dans une fenêtre temporelle F allouée au coeur 10 pour l'accès à la ressource commune 12. Le contrôleur d'accès 18 du coeur 10 est configuré pour mettre en oeuvre la 10 politique de partage des ressources communes 12. Pour la mise en oeuvre du procédé de contrôle, il convient, d'une part de déclencher les étapes d'anticipation et de planification au moment approprié au cours de l'exécution de l'application logicielle AP, et, d'autre part de déterminer une requête anticipée et de planifier la transaction dans une fenêtre allouée libre. 15 Dans un mode de mise en oeuvre, l'application logicielle AP est configurée pour émettre un appel système (en anglais « hypercall ») pour déclencher les étapes d'anticipation et de planification, à une étape déterminée de l'exécution de l'application logicielle AP. Le code de l'application logicielle AP est modifié pour intégrer un appel système permettant de déclencher les étapes d'anticipation et de planification. 20 L'émission de l'appel système interrompt l'exécution de l'application logicielle AP et déclenche l'exécution du contrôleur d'accès 18. Le contrôleur d'accès 18 est configuré pour déterminer une requête anticipée susceptible d'être émise prochainement par l'application logicielle AP et nécessitant une transaction avec la ressource commune 12, et pour planifier la transaction dans une 25 fenêtre temporelle F libre. Ce mode de réalisation permet de programmer chaque application logicielle AP spécifiquement pour le déclenchement des étapes d'anticipation et de planification, à un moment de l'exécution de l'application logicielle AP qui est particulièrement approprié pour cette application logicielle AP. 30 Dans une variante, les étapes d'anticipation et de planification sont déclenchées lors du déclenchement d'un défaut de page provoqué par une première requête émise par l'application logicielle AP. En effet, en cas de défaut de page, le coeur 10 interrompt l'exécution de l'application logicielle AP et le contrôleur d'accès 18 s'active pour réaliser la transaction 35 de chargement des données de la première requête ayant déclenché le défaut de page. 3061327 10 Le contrôleur d'accès 18 est configuré pour déterminer une deuxième requête anticipée susceptible d'être émise prochainement par l'application logicielle AP et nécessitant une transaction avec la ressource commune 12, et pour planifier la transaction de la deuxième requête dans une fenêtre temporelle F libre. La deuxième 5 requête anticipée est bien entendu différente de la première requête émise qui a déclenché le défaut de page. Dans ce mode de réalisation, la transaction de la première requête émise ayant déclenché le défaut de page sera réalisée dans la prochaine fenêtre temporelle F libre, et la transaction de la deuxième requête anticipée sera planifiée dans une autre fenêtre 10 temporelle F libre postérieure pour ne pas retarder la transaction liée à la première requête émise et ayant déclenché le défaut de page. Ce mode de mise en oeuvre permet d'éviter de modifier le code des applications logicielles exécutées par le coeur 10, et est applicable à toute application logicielle exécutée par le coeur 10. 15 En option, l'étape d'anticipation est déclenchée par une « exception » demandée par l'application logicielle AP au cours de son exécution. Une exception est une situation exceptionnelle résultant de l'exécution de l'application logicielle AP et nécessitant une interruption de l'exécution de l'application logicielle AP. La prise en compte des exceptions déclenchées par l'exécution de l'application 20 logicielle AP permet de déclencher l'étape d'anticipation plus fréquemment pour améliorer les performances du processeur multi-coeurs en anticipant des requêtes à venir nécessitant une transaction. Dans les différents modes de réalisation, le contrôleur d'accès 18 est configuré pour la détermination d'une requête anticipée susceptible d'être émise ultérieurement par 25 l'application logicielle AP. Pour ce faire, le contrôleur d'accès 18 est par exemple configuré pour enregistrer des traces des transactions réalisées pour l'application logicielle AP, et pour déterminer une requête anticipée en fonction des transactions réalisées préalablement pour l'application logicielle AP. 30 Le contrôleur d'accès 18 comprend par exemple un automate logiciel configuré pour déterminer une requête anticipée en fonction des transactions réalisées préalablement pour l'application logicielle AP. Pour la prédiction d'une requête, il est possible de réaliser un profilage des requêtes de l'application logicielle AP. 35 Un tel profilage permet par exemple de déterminer des tables de requêtes 20 associant des séquences de requêtes caractéristiques à des requêtes probables 3061327 11 associées. Ainsi, en cas de détection d'une séquence de requêtes caractéristique, la requête anticipée est déterminée comme étant la requête probable associée à la séquence de requêtes caractéristique. Le profilage des requêtes d'une application logicielle AP est effectué au cours d'une ou plusieurs exécutions de l'application logicielle AP, par simulation du fonctionnement de l'application logicielle AP et/ou par analyse statique de l'application logicielle AP. Le procédé de contrôle est mis en oeuvre sur un ou plusieurs coeurs 10 et pour le partage d'une ou plusieurs ressources communes 12. Chaque coeur 10 mettant en oeuvre 10 le procédé de contrôle peut être configuré indépendamment pour la réalisation des étapes d"anticipation et de planification. Dans le cas de plusieurs ressources communes 12, il est envisageable de déterminer une politique de partage des ressources communes 12 selon laquelle chaque fenêtre temporelle F est allouée à un seul coeur 10 pour l'accès à l'ensemble des 15 ressources communes 12. En variante, il est envisageable de déterminer une politique de partage des ressources communes 12 selon laquelle au moins une même fenêtre temporelle F est allouée à un premier coeur 10 pour une première ressource commune 12 et à un deuxième coeur 10 distinct du premier coeur 10 pour une deuxième ressource commune 20 12 distincte de la première ressource commune 12. Ceci est possible si les premier et deuxième coeurs 10 ne sont pas en concurrence pour les première et deuxième ressources communes 12. Le procédé de contrôle selon l'invention permet donc de diminuer le temps d'exécution d'applications logicielles sur un processeur multi-coeurs embarquant un 25 contrôleur d'accès 18, en réalisant des transactions en avance de phase, par prédiction ou anticipation de requêtes nécessitant une transaction et réalisation de la transaction en avance, avant l'émission effective de la requête par l'application logicielle. Le procédé de contrôle est applicable en particulier à un calculateur d'un système avionique comme décrit précédemment. Il est applicable plus généralement à tout 30 calculateur, en particulier un calculateur nécessitant un traitement des requêtes des applications logicielles dans un temps borné. Il est applicable notamment à un calculateur embarqué d'un système avionique, d'un système spatial ou d'un système ferroviaire. REVENDICATIONS1.- Procédé de contrôle d'un processeur multi-coeurs comprenant plusieurs coeurs (10) physiquement distincts partageant au moins une ressource matérielle commune (12) selon une politique de partage basée sur des fenêtres temporelles (F) distinctes, chaque fenêtre temporelle (F) étant allouée à un ou plusieurs coeurs (10) pour l'accès à une ressource matérielle commune (12), le procédé de contrôle comprenant : - l'anticipation d'une requête devant être émise par une application logicielle (AP) exécutée par un coeur (10) et nécessitant une transaction entre ce coeur (10) et la ressource commune (12), avant l'émission effective de cette requête par l'application logicielle (AP) ; - la planification de la transaction dans une fenêtre temporelle (F) à venir allouée audit coeur (10) pour l'accès à la ressource commune (12) ; - la réalisation de la transaction planifiée dans la fenêtre temporelle (F) et le chargement des données dans une mémoire cache privée (16) dudit coeur (10) ; et - la restitution des données à l'application logicielle (AP) à partir de la mémoire cache privée (16) à l'émission effective de la requête par l'application logicielle (AP). 2.- Procédé de contrôle selon la revendication 1, dans lequel le coeur (10) poursuit l'exécution de l'application logicielle (AP) à partir de la mémoire cache privée (16) entre la planification de la transaction et la réalisation de la transaction. 3.- Procédé de contrôle selon la revendication 1 ou 2, comprenant le déclenchement des étapes d'anticipation et de planification à l'émission d'un appel système par l'application logicielle (AP). 4.- Procédé de contrôle selon l'une quelconque des revendications précédentes, comprenant le déclenchement des étapes d'anticipation et de planification au déclenchement d'un défaut de page provoqué par l'émission d'une requête émise nécessitant une transaction entre ledit coeur (10) et la ressource commune (12) pour servir la requête émise, la requête anticipée étant distincte de la requête émise. 5.- Procédé de contrôle selon la revendication 1, dans lequel la requête anticipée est planifiée après la requête émise. 6.- Procédé de contrôle selon l'une quelconque des revendications précédentes, comprenant le déclenchement d'une exception provoqué par une requête émise par l'application logicielle (AP). 7.- Procédé de contrôle selon l'une quelconque des revendications précédentes, dans lequel les étapes d'anticipation et de planification sont réalisées par un contrôleur 3061327 13 d'accès (18) logiciel configuré pour la mise en oeuvre de la politique de partage des ressources communes (12). 8.- Procédé de contrôle selon l'une quelconque des revendications précédentes, dans lequel la requête anticipée est déterminée en détectant une séquence de requêtes 5 précédentes ayant nécessité une transaction, et en comparant la séquence de requêtes détectée aux séquences de requêtes caractéristiques prédéfinies, chacune associée à une requête anticipée prédéfinie. 9.- Calculateur comprenant un processeur multi-coeurs possédant plusieurs coeurs (10) physiquement distincts et au moins une ressource matérielle commune (12) partagée 10 par les coeurs (10) et accessible aux coeurs (10) selon une politique de partage basée sur des fenêtres temporelles distinctes, chaque fenêtre temporelle étant allouée à un ou plusieurs coeurs (10) pour l'accès à la ressource matérielle commune (12), dans lequel au moins un contrôleur d'accès (18) logiciel pour le contrôle des transactions entre un coeur (10) et la ressource matérielle commune (12) et/ou un application logicielle (AP) 15 implémentés sur le coeur (10) sont configurés pour la mise en oeuvre d'un procédé de contrôle selon l'une quelconque des revendications précédentes.