FR3087982A1 - Procede et circuit de multiplexage temporel d'acces concurrents a une ressource informatique - Google Patents

Procede et circuit de multiplexage temporel d'acces concurrents a une ressource informatique Download PDF

Info

Publication number
FR3087982A1
FR3087982A1 FR1860117A FR1860117A FR3087982A1 FR 3087982 A1 FR3087982 A1 FR 3087982A1 FR 1860117 A FR1860117 A FR 1860117A FR 1860117 A FR1860117 A FR 1860117A FR 3087982 A1 FR3087982 A1 FR 3087982A1
Authority
FR
France
Prior art keywords
processing
time
request
critical program
program
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
FR1860117A
Other languages
English (en)
Other versions
FR3087982B1 (fr
Inventor
Farouk Hebbache
Mathieu Jan
Florian Brandner
Laurent Pautet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Institut Mines Telecom IMT
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Original Assignee
Commissariat a lEnergie Atomique CEA
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
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 Commissariat a lEnergie Atomique CEA, Commissariat a lEnergie Atomique et aux Energies Alternatives CEA filed Critical Commissariat a lEnergie Atomique CEA
Priority to FR1860117A priority Critical patent/FR3087982B1/fr
Priority to PCT/FR2019/052513 priority patent/WO2020089542A1/fr
Priority to US17/289,270 priority patent/US20210397488A1/en
Priority to EP19813627.7A priority patent/EP3850486A1/fr
Publication of FR3087982A1 publication Critical patent/FR3087982A1/fr
Application granted granted Critical
Publication of FR3087982B1 publication Critical patent/FR3087982B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • 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
    • 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/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G06F9/526—Mutual exclusion algorithms

Abstract

L'invention porte sur un procédé mis en œuvre par ordinateur d'arbitrage entre des programmes informatiques cherchant à accéder concurremment à une ressource partagée en émettant chacun une requête d'accès. Le procédé réalise un accès multiple à répartition dans le temps selon lequel le temps est divisé en créneaux temporels chacun alloué à un programme critique pour un accès à la ressource partagée, chaque créneau temporel comprenant une pluralité d'unités de temps. Le procédé exploite une marge de traitement associée à chaque programme critique pour retarder une échéance de traitement d'une requête d'accès émise par le programme critique. Le procédé comprend, à chaque unité de temps, une étape de sélection d'une requête d'accès en attente et une étape de détermination d'une autorisation de traitement immédiat de la requête d'accès sélectionnée. Cette détermination comprend pour une unité de temps ne correspondant pas au début d'un créneau temporel, lorsque le programme critique auquel le prochain créneau temporel est alloué n'a pas émis la requête sélectionnée, l'autorisation du traitement immédiat de la requête sélectionnée si la marge de traitement du programme critique auquel le prochain créneau temporel est alloué est supérieure à un seuil.

Description

PROCÉDÉ ET CIRCUIT DE MULTIPLEXAGE TEMPOREL D'ACCÈS CONCURRENTS À UNE RESSOURCE INFORMATIQUE DESCRIPTION DOMAINE TECHNIQUE Le domaine de l'invention est celui des systèmes informatiques temps-réel pour lesquels le temps d'exécution des tâches, et notamment le temps d'exécution dans le pire des cas (dit WCET pour « Worst Case Execution Time »), doit être connu pour en assurer la validation et en garantir la sûreté.
L'invention vise plus particulièrement à améliorer le taux d'utilisation d'une ressource partagée par des programmes informatiques s'exécutant en parallèle tout en garantissant l'estimation du WCET de ces programmes au moyen d'une politique d'arbitrage à multiplexage temporel pour l'accès à la ressource partagée.
ÉTAT DE LA TECHNIQUE ANTÉRIEURE Les systèmes temps-réel doivent réagir de manière fiable, ce qui implique à la fois d'être certain du résultat produit par leurs programmes mais aussi de connaître le temps qu'ils prennent pour s'exécuter.
Les temps d'exécution pire-cas sont ainsi des données fondamentales pour la validation et la sûreté de tels systèmes temps-réel, et encore plus dans le contexte des systèmes temps-réels autonomes (robotique, voiture autonome, GPS) pour lesquels la sûreté de fonctionnement est primordiale.
Cependant calculer un WCET, à la fois garanti (majorant strict) et pas trop pessimiste afin de réduire les coûts et la complexité de tels systèmes temps-réels, est un problème difficile à résoudre sur des architecture matérielles multi-coeurs en raison de la concurrence entre les différents programmes s'exécutant en parallèle pour l'accès aux ressources partagées, typiquement une mémoire partagée.
Pour chaque requête d'accès à une telle ressource partagée émise par un programme, il faut en effet systématiquement considérer la situation la plus défavorable induite par la politique d'arbitrage utilisée pour gérer l'accès à cette ressource partagée.
Ceci induit un 2 pessimisme important dans la valeur du WCET obtenue et donc un faible taux d'utilisation de cette ressource partagée lors de l'exécution des programmes.
Ce problème de sous-utilisation de la ressource partagée est amplifié avec la multiplication de programmes non-soumis à des contraintes temporelles (dits programmes non-critiques) qui s'exécutent en parallèle des programmes temps-réel (dits programmes critiques).
Les requêtes d'accès générées par ces programmes non-critiques impactent la situation la plus défavorable qui doit être considérée pour les requêtes d'accès émises par les programmes critiques et accentuent donc le pessimisme des WCET calculés et la sous-utilisation de la ressource partagée.
10 Il est possible d'éliminer par construction toute concurrence entre les requêtes d'accès émises par les différentes programmes en ayant recours à une politique d'arbitrage à multiplexage temporel (en anglais « Time-Division Multiplexing », TDM).
Selon cette politique, le temps est divisé en créneaux temporels chacun alloué à un programme prédéfini pour un accès exclusif à la ressource partagée.
Le temps d'accès à la 15 ressource partagée par un programme peut alors être facilement borné (il correspond au délai maximal jusqu'à parvenir au prochain créneau temporel alloué au programme), la bande passante offerte à un programme est indépendante des autres programmes et les WCET des programmes peuvent ainsi être déterminés.
Toutefois, le temps d'accès à la ressource partagée par un programme dépend de 20 l'ordonnancement des créneaux temporels qui lui sont affectés.
Or cet ordonnancement est généralement statique car réalisé lors de la conception du système, avant l'exécution des programmes.
Il comprend généralement l'affectation d'une séquence de créneaux temporels à différents programmes, cette séquence se répétant périodiquement (on parle de période TDM).
Mais les créneaux temporels d'une période TDM ne sont utilisés 25 par les programmes que s'ils ont une requête d'accès à la ressource partagée à émettre.
Lorsque cela n'est pas le cas, ces créneaux temporels sont donc inutilisés.
Une politique d'arbitrage TDM basique est donc dite oisive car ces créneaux temporels ne sont pas récupérés par les autres programmes afin de diminuer leur temps d'accès à la ressource partagée.
3 Par ailleurs, il est admis que pour les programmes temps-réel, il peut exister en moyenne un facteur 10 entre le temps d'exécution d'une instance du programme et son WCET.
L'oisiveté de la politique d'arbitrage TDM associée à cette caractéristique des programmes temps réel génère un faible taux d'utilisation de la ressource partagée.
Ce problème est amplifié lorsque le nombre de programmes augmente car dans ce cas la longueur d'une période TDM est également augmentée.
Un autre facteur d'amplification de ce phénomène est la présence au sein des systèmes considérés d'un nombre croissant de programmes non-critiques pour lesquels l'affectation de créneaux augmente la latence des requêtes des programmes critiques ainsi que la latence des requêtes de ces 10 programmes non-critiques, en contradiction avec leur objectif d'avoir les meilleurs performances d'exécution en moyenne.
La publication de Farouk Hebbache, Mathieu Jan, Florian Brandner et Laurent Pautet, intitulée « Dynamic Arbitration of Memory Requests with TDM-like Guarantees", Proceedings of the CRTS 2017 workshop, présente une amélioration à une telle politique 15 d'arbitrage TDM qui permet d'en réduire l'oisiveté.
Selon cette amélioration, dite TMDds (« dynamic TDM with slack counters »), une échéance de traitement est associée à chaque requête d'accès d'un programme critique qui correspond à l'instant auquel le traitement de cette requête doit être terminé au plus tard, ce qui permet de rendre possible la détermination des WCET.
Cette échéance correspond tout simplement à la fin 20 du prochain créneau temporel alloué au programme critique qui suit l'émission de la requête d'accès.
L'arbitrage peut alors être rendu dynamique, tant que les échéances de traitement sont respectées.
Pour ce faire, un compteur de marge de traitement (« slack counter » en anglais) est associé à chaque programme critique.
Ce compteur indique le nombre de 25 créneaux temporels séparant la terminaison effective du traitement d'une requête d'accès de son échéance de traitement.
Ce compteur est utilisé pour retarder le cas échéant l'échéance de traitement de la prochaine requête d'accès du programme critique.
L'arbitrage réalisé à chaque début de créneau temporel consiste alors à sélectionner la requête d'accès pendante ayant l'échéance de traitement la plus proche, indépendamment du programme critique à qui ce créneau temporel est alloué.
4 Si cette politique d'arbitrage TDMds permet d'améliorer l'utilisation de la ressource partagée, elle reste néanmoins perfectible.
En effet, pour les systèmes considérés, la longueur des créneaux temporels doit être supérieure ou égale au temps maximum mis par une requête, émise de manière isolée, pour être traitée par la ressource partagée.
Or si par exemple la ressource partagée est une mémoire, le temps d'accès d'une requête en écriture est inférieur au temps d'accès d'une requête en lecture, puisque dans ce second cas la mémoire doit émettre les données demandées à destination du programme requérant.
Par ailleurs, le temps d'accès à une mémoire peut dépendre de l'historique des requêtes émises par les autres programmes.
Une borne supérieure de traitement des 10 requêtes doit donc être identifiée pour déterminer la longueur des créneaux temporels.
Toutefois, le traitement de la plupart des requêtes va par définition se terminer avant cette borne, de sorte que la politique d'arbitrage TDMds demeure oisive.
EXPOSÉ DE L'INVENTION L'invention a pour objectif de proposer une politique d'arbitrage améliorée qui 15 permette d'optimiser l'utilisation de la ressource partagée tout en garantissant la prédictibilité temporelle du traitement des requêtes d'accès à la ressource partagée issues de programmes critiques.
A cet effet, l'invention propose un procédé mis en oeuvre par ordinateur d'arbitrage entre des programmes informatiques cherchant à accéder concurremment à une 20 ressource partagée en émettant chacun une requête d'accès.
Le procédé réalise un accès multiple à répartition dans le temps selon lequel le temps est divisé en créneaux temporels chacun alloué à un programme critique pour un accès à la ressource partagée, chaque créneau temporel comprenant une pluralité d'unités de temps.
Une marge de traitement est associée à chaque programme critique pour retarder une échéance de 25 traitement d'une requête d'accès émise par le programme critique.
Le procédé comprend, à chaque unité de temps, une étape de sélection d'une requête d'accès parmi une ou plusieurs requêtes d'accès en attente et une étape de détermination d'une autorisation de traitement immédiat de la requête d'accès sélectionnée.
L'étape de détermination comprend pour une unité de temps ne correspondant pas au début d'un 5 créneau temporel, lorsque le programme critique auquel le prochain créneau temporel est alloué n'a pas émis la requête sélectionnée, l'autorisation du traitement immédiat de la requête sélectionnée si la marge de traitement du programme critique auquel le prochain créneau temporel est alloué est supérieure à un seuil.
Certains aspects préférés mais non limitatifs de ce procédé sont les suivants : - l'étape de détermination comprend, pour une unité de temps ne correspondant pas au début d'un créneau temporel, lorsque le programme critique auquel le prochain créneau temporel est alloué n'a pas émis la requête sélectionnée et lorsque la marge de traitement du programme critique auquel le prochain créneau temporel est alloué 10 est inférieure au seuil, la mise en attente de la requête sélectionnée ; - le seuil correspond à l'écart temporel entre l'unité de temps à laquelle l'étape de détermination est réalisée et l'unité de temps correspondant au début du prochain créneau temporel ; - l'étape de détermination comprend pour une unité de temps ne correspondant 15 pas au début d'un créneau temporel, lorsque le programme critique auquel le prochain créneau temporel est alloué a émis la requête sélectionnée, l'autorisation du traitement immédiat de la requête sélectionnée ; - l'étape de détermination comprend, pour une unité de temps correspondant au début d'un créneau temporel, l'autorisation du traitement immédiat de la requête 20 sélectionnée ; - l'étape de sélection comprend, en présence d'une requête d'accès en attente d'un programme critique et d'une requête d'accès en attente d'un programme non-critique, la sélection de la requête d'accès du programme non-critique si l'échéance de traitement de la requête d'accès du programme critique est postérieure à la fin du 25 prochain créneau temporel ; - la marge de traitement d'un programme critique est mise à jour à chaque terminaison d'un traitement d'une requête d'accès du programme critique pour correspondre au nombre d'unités de temps séparant la terminaison du traitement de la requête d'accès et l'échéance de traitement de la requête d'accès ; 6 - l'échéance de traitement d'une requête d'accès d'un programme critique correspond à la fin d'un créneau temporel alloué au programme critique qui est le premier à débuter après une date correspondant à une date d'émission de la requête d'accès retardée par ajout de la marge de traitement du programme critique ; - il comprend en outre la préemption au profit d'un programme critique d'un premier programme ayant émis une requête d'accès à la ressource partagée en attente de traitement, ladite préemption comprenant le calcul d'une échéance de traitement de ladite requête correspondant à la fin d'un créneau temporel alloué au programme critique.
10 BRÈVE DESCRIPTION DES DESSINS D'autres aspects, buts, avantages et caractéristiques de l'invention apparaîtront mieux à la lecture de la description détaillée suivante de formes de réalisation préférées de celle-ci, donnée à titre d'exemple non limitatif, et faite en référence aux dessins annexés sur lesquels : 15 - les figures la et lb sont des schémas illustrant le principe de l'arbitrage réalisé dans l'invention pour autoriser ou non un accès immédiat à la ressource partagée ; - la figure 2 est une machine d'états représentant un enchaînement d'étapes du procédé selon l'invention ; 20 - la figure 3 est un chronogramme représentant un exemple d'arbitrage opéré par le procédé selon l'invention ; - la figure 4 est un schéma d'un circuit configuré pour mettre en oeuvre le procédé selon l'invention.
EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS 25 L'invention porte sur un procédé mis en oeuvre par ordinateur d'arbitrage entre des programmes informatiques cherchant à accéder concurremment à une ressource partagée en émettant chacun une requête d'accès.
En référence à la figure 4 qui sera décrite plus en détail ultérieurement, ce procédé est typiquement mis en oeuvre sur une 7 architecture matérielle multi-coeurs où chaque coeur CO, Cl, Cm est configuré pour exécuter un programme susceptible de requérir des accès à la ressource partagée lors de son exécution.
Chaque coeur peut disposer d'une mémoire cache privée et la ressource partagée est par exemple une mémoire partagée MM.
Une implémentation matérielle configurée pour mettre en oeuvre ce procédé prend la forme d'un circuit de multiplexage temporel CMT interposé entre les coeurs et la ressource partagée.
Comme pour l'arbitrage TDMds décrit dans la publication précitée, le procédé selon l'invention réalise un accès multiple à répartition dans le temps selon lequel le temps est divisé en créneaux temporels (s/ots en anglais) chacun alloué à un programme critique 10 pour un accès à la ressource partagée, chaque créneau temporel comprenant une pluralité d'unités de temps (une unité de temps est par exemple un cycle d'horloge).
On a représenté sur les figures la, lb et 3 un exemple d'une telle division temporelle en créneaux de tailles identiques alternativement alloué à un premier programme critique A (les créneaux portant un numéro impair) et à un deuxième programme critique B (les 15 créneaux portant un numéros pair).
Un programme critique est par exemple un programme soumis à des contraintes temporelles et pour lequel on souhaite pouvoir borner le temps d'exécution dans le pire des cas (WCET).
Ainsi, comme pour l'arbitrage TDMds, le procédé selon l'invention associe une échéance de traitement à chaque requête d'accès émise par un programme 20 critique.
Cette échéance correspond à l'instant auquel le traitement de la requête du programme critique doit être terminé au plus tard et doit être respectée.
Le procédé porte également sur des requêtes d'accès émises par des programmes non soumis à des contraintes temporelles, i.e. des programmes non-critiques, et pour lesquelles aucune notion d'échéance de traitement n'est nécessaire.
25 Et le procédé selon l'invention exploite lui aussi une marge de traitement associée à chaque programme critique, cette marge de traitement étant utilisée pour éventuellement retarder une échéance de traitement d'une requête d'accès émise par le programme critique, notamment lorsque le programme critique a accumulé une marge de traitement suffisante.
De telle manière, une requête d'accès à la ressource émise par 8 un programme peut être traitée sur un créneau qui n'est pas alloué par construction à ce programme.
Selon TDMds, les décisions d'arbitrage sont prises au début de chaque créneau temporel et ne sont basées que sur les requêtes en attente de traitement.
Il est alors possible de retarder une requête d'un programme critique, en fonction de l'échéance de traitement de cette requête.
La marge de traitement n'est pas exploitée lors des décisions d'arbitrage et n'a qu'un effet sur le calcul des échéances de traitement des requêtes.
L'invention est basée sur le fait de reconnaitre qu'une marge de traitement est 10 également valide lorsqu'un programme critique n'a pas (encore) émis une requête d'accès à la ressource.
En particulier, il est possible de déterminer une borne inférieure de l'échéance de traitement associée à n'importe quelle requête émise par le programme critique auquel le prochain créneau temporel est alloué (même lorsque le programme n'a pas encore émis une requête).
La ressource partagée peut alors démarrer le traitement 15 de n'importe laquelle des requêtes en attente si cette borne inférieure est postérieure à la fin du prochain créneau temporel.
Cela garantit que la mémoire peut traiter partiellement la requête dans le créneau temporel actuel, tout en complétant ce traitement dans le créneau suivant sans violer le comportement dans le pire des cas.
L'invention propose ainsi d'exploiter les marges de traitement, non pas à chaque 20 début de créneau temporel, mais à chaque unité de temps.
La marge de traitement associée au programme critique auquel le prochain créneau temporel est alloué est consultée pour déterminer si une requête peut immédiatement être traitée par la ressource partagée.
Cette consultation a pour objectif de vérifier si un débordement du temps de traitement de la requête sur le prochain créneau temporel ne remet pas en 25 cause le respect de l'échéance de traitement associée à une éventuelle requête qui serait émise par le programme critique auquel ce prochain créneau temporel est alloué.
Ainsi dans le cadre de l'invention, la marge de traitement d'un programme critique est mise à jour à chaque terminaison d'un traitement d'une requête d'accès du programme critique pour correspondre au nombre d'unités de temps séparant la 30 terminaison du traitement de la requête d'accès et l'échéance de traitement de la 9 requête d'accès.
Et l'échéance de traitement d'une requête d'accès d'un programme critique correspond à la fin du créneau temporel alloué au programme critique qui est le premier à débuter après une date correspondant à une date d'émission de la requête d'accès retardée par ajout de la marge de traitement du programme critique.
On a représenté sur les figures la et lb un exemple dans lequel à une unité de temps correspondant au temps t, l'accès à la ressource est libéré et il est vérifié si une requête en attente peut être traitée.
Cette unité de temps t ne correspond pas au début du créneau temporel alloué au programme critique B qui débute à to.
Le créneau suivant, alloué au programme critique A, débute à t1.
10 Sur la figure la, la marge de traitement MA1 du programme critique A auquel le prochain créneau temporel est alloué (créneau n°3) est suffisamment importante pour permettre de retarder l'échéance de traitement d'une requête qui serait émise par le programme A entre t et t1.
Au lieu que cette échéance corresponde à la fin 11 du prochain créneau temporel alloué au programme A, elle est retardée pour correspondre à la fin El 15 du créneau temporel n°5 alloué au programme A qui suit une date correspondant à une date d'émission de la requête d'accès retardée par ajout de la marge de traitement du programme critique MAl.
Cela revient à déterminer que la marge de traitement MA1 est supérieure au nombre d'unités de temps séparant t et t1.
Sur la figure lb, la marge de traitement MA2 du programme critique A auquel le 20 prochain créneau temporel est alloué n'est pas suffisamment importante pour permettre de retarder l'échéance de traitement d'une requête qui serait émise par le programme A entre t et t1.
Son échéance de traitement correspond donc à la fin E2 du prochain créneau temporel (n°3) associé au programme A.
Cela revient à déterminer que la marge de traitement MA2 est inférieure au nombre d'unités de temps séparant t et t1.
Dans un tel 25 cas de figure, la requête en attente ne peut pas être traitée car son traitement pourrait déborder sur le prochain créneau temporel n°3 en empêchant le traitement d'une requête que formulerait le programme critique A et donc compromettre le respect de l'échéance de traitement du programme critique A.
10 On a représenté sur la figure 2, une machine d'états représentative d'un mode de réalisation du procédé selon l'invention.
Sur cette figure, la référence « Rac » désigne l'émission d'une requête d'accès à la ressource partagée.
Si cette émission est réalisée par un programme critique « Cr », il est procédé lors d'une opération « DC » au calcul de l'échéance de traitement de la requête émise par le programme critique.
Ce calcul exploite la marge de traitement accumulé par le programme critique lors du traitement de sa précédente requête d'accès à la ressource pour venir éventuellement retarder l'échéance de traitement au-delà de la fin du prochain créneau temporel alloué à ce programme critique (i.e. à la fin d'un créneau 10 temporel alloué au programme critique postérieur au prochain créneau temporel alloué au programme critique).
Si cette émission est réalisée par un programme non-critique « NCr » et qu'il existe une ou plusieurs autres requêtes non-critiques pendantes, il est procédé à un arbitrage « NC-AR » des requêtes non-critiques selon une politique d'arbitrage quelconque (par 15 exemple priorité fixe ou premier arrivé-premier servi) pour venir en sélectionner une.
A chaque unité de temps, il est vérifié si l'accès mémoire est possible.
Dans la négative (idle), les requêtes pendantes sont mises en attente.
Dans l'affirmative (idle), il est procédé à la sélection d'une requête (Select) et à la détermination d'une autorisation de traitement immédiat de la requête d'accès sélectionnée.
20 La sélection comprend le choix, parmi les requêtes de programmes critiques, de la requête présentant l'échéance de traitement la plus proche.
Le résultat de la sélection est donc soit la requête critique présentant l'échéance de traitement la plus proche, soit la requête non critique résultant de l'arbitrage « NC-AR ».
Par exemple, en présence d'une requête d'accès en attente d'un programme critique et d'une requête d'accès en attente 25 d'un programme non-critique, il est procédé à la sélection de la requête d'accès du programme non-critique si l'échéance de traitement du programme critique est postérieure à la date de fin du prochain créneau temporel.
La détermination d'une autorisation de traitement immédiat de la requête d'accès sélectionnée comprend, pour une unité de temps ne correspondant pas au début d'un 30 créneau temporel (t# t0), lorsque le programme critique auquel le prochain créneau 11 temporel est alloué n'a pas émis la requête sélectionnée (« Next=Rs » et « N »), l'autorisation du traitement immédiat de la requête sélectionnée (« RS ») si la marge de traitement du programme critique auquel le prochain créneau temporel est alloué est supérieure à un seuil (« t+MTnext>ti » et «O »).
Si la marge de traitement est inférieure au seuil, la requête sélectionnée est mise en attente (« Att »).
Le seuil peut correspondre comme on l'a vu précédemment à l'écart temporel entre l'unité de temps t à laquelle l'étape de détermination est réalisée et l'unité de temps t1 correspondant au début du prochain créneau temporel.
Alternativement, le seuil peut correspondre à la taille d'un créneau temporel.
10 La détermination d'une autorisation de traitement immédiat de la requête d'accès sélectionnée comprend par ailleurs, pour une unité de temps ne correspondant pas au début d'un créneau temporel (t# to), lorsque le programme critique auquel le prochain créneau temporel est alloué a émis la requête sélectionnée (« Next=Rs » et « O»), l'autorisation du traitement immédiat de la requête sélectionnée (« Rs »).
15 Et la détermination d'une autorisation de traitement immédiat de la requête d'accès sélectionnée comprend par ailleurs, pour une unité de temps correspondant au début d'un créneau temporel (t=t0), l'autorisation du traitement immédiat de la requête sélectionnée (« Rs »).
Une fois la requête sélectionnée traitée, il est procédé, lorsque cette requête est 20 issue d'un programme critique (« Rs-Cr »), à la mise à jour « MAJ MTs » de la marge de traitement de ce programme critique.
De telle manière, la marge de traitement d'un programme critique est mise à jour à chaque terminaison d'un traitement d'une requête d'accès du programme critique pour correspondre au nombre d'unités de temps séparant la terminaison du traitement de la requête d'accès et l'échéance de traitement de la 25 requête d'accès.
On a représenté sur la figure 3 un exemple de mise en oeuvre de ce procédé avec deux programmes critiques A et B, un programme non-critique c et des créneaux ayant une taille de 8 unités de temps.
Sur cette figure, la valeur courante de la marge de traitement est indiquée en exposant de chaque requête (par exemple la requête Al du 12 programme critique A bénéficie d'une marge de traitement de 10 A, soit 10 unités de temps).
Une première requête d'accès Ao du programme critique A est tout d'abord émise au cours du créneau n°1 alloué au programme A.
La marge de traitement de A est nulle et son échéance de traitement est fixée à la fin du prochain créneau alloué à A (créneau n°3).
A ce stade, la marge de traitement de B (propriétaire du prochain créneau n°2) est nulle et il n'est pas possible de réaliser un traitement immédiat de Ao avant le début du prochain créneau n°2.
Le traitement de Ao dure six unités de temps et A a donc accumulé une marge de traitement de 10 unités de temps.
10 Une première requête d'accès Bo du programme critique B est émise au cours du créneau n°2.
Le prochain créneau n°3 est alloué au programme A qui a accumulé suffisamment de marge de traitement pour que soit autorisé le traitement immédiat de la requête Bo sans risque que le débordement du traitement de Bo sur le créneau n°3 ne vienne remettre en cause le respect de l'échéance de traitement associée à une 15 éventuelle requête émise par le programme critique A auquel le créneau n°3 est alloué.
Le programme B voit sa marge de traitement passer à 10 unités de temps.
Au cours du créneau n°4, une première requête d'accès co du programme non-critique c et une deuxième requête d'accès B1 du programme critique B sont simultanément émises.
La requête co du programme non-critique est sélectionnée car le 20 programme critique B n'est pas propriétaire du prochain créneau n°5, et est immédiatement traitée car le programme critique A propriétaire du prochain créneau n°5 a accumulé suffisamment de marge de traitement (en l'occurrence 10 unités de temps).
Puis dès la terminaison de la requête d'accès co au cours du créneau n°5, il est procédé au traitement immédiat de la requête B1 car le programme B est propriétaire du prochain 25 créneau n°6.
Au cours du traitement de la requête B1, une deuxième requête d'accès Al du programme critique A et une deuxième requête d'accès c1 du programme non-critique c sont émises.
A la terminaison du traitement de la requête B1 au cours du créneau n°6, celui-ci voit sa marge de traitement passer à 7 unités de temps.
La requête Al est 30 sélectionnée et immédiatement traitée car le programme A est propriétaire du prochain 13 créneau n°7.
Le traitement de la requête Al se termine au cours du créneau n°6, et la marge de traitement du programme A passe à 11 unités de temps.
A la terminaison du traitement de la requête Al deux requêtes sont en compétition : la deuxième requête d'accès c1 du programme non-critique c et une troisième requête d'accès B2 du programme critique B.
La deuxième requête d'accès c1 est sélectionnée car l'échéance de traitement de la requête B2 est postérieure à la fin du créneau n°7, puis immédiatement traitée car la marge de traitement du programme A propriétaire du prochain créneau n°7 est suffisante.
A la terminaison du traitement de la requête c1, la requête B2 est immédiatement traitée car le programme B est propriétaire du prochain 10 créneau n°8.
A la terminaison du traitement de la requête B2 au cours du créneau n°8, celui-ci voit sa marge de traitement passer à 5 unités de temps.
Une troisième requête d'accès A2 du programme critique A est ensuite émise qui au vu de la marge de traitement dont bénéfice alors le programme A dispose d'une échéance de traitement à la fin du créneau n°11.
Néanmoins, le programme A est propriétaire du prochain créneau n°9 et sa 15 requête A2 peut être immédiatement traitée.
On a représenté sur la figure 4 une implémentation possible d'un circuit de multiplexage temporel CMT configuré pour mettre en oeuvre le procédé selon l'invention.
Le circuit CMT est interposé entre des coeurs CO, Cl, Cm exécutant chacun un programme et une ressource partagée.
Une marge de traitement est associée à chaque coeur 20 exécutant un programme critique.
Un compteur peut pour cela être implémenté sous la forme d'un registre stockant un nombre d'unités de temps non-utilisées par le coeur.
Ce compteur fait partie du contexte d'exécution du programme critique, et sa valeur est donc sauvegardée/restaurée à chaque préemption/reprise de l'exécution du programme.
Le circuit CMT comprend une unité d'arbitrage AR et un multiplexeur MUX 25 commandé par l'unité d'arbitrage pour réaliser l'accès sélectif de l'un des coeurs à la ressource partagée.
Le circuit CMT comprend par ailleurs une unité de calcul d'échéance de traitement DCO, DC1, DCm associée à chacun des coeurs.
Cette unité est configurée pour réceptionner une requête d'accès RO, R1, Rm émise par un programme exécuté sur le coeur auquel elle est associée et pour calculer l'échéance de traitement de la requête 30 lorsque celle-ci est émise par un programme critique.
L'unité DCO, DC1, DCm peut 14 comprendre des registres dédiés pour stocker l'échéance calculée ainsi que la marge de traitement courante.
Si la requête est émise par un programme non-critique, l'unité DCO, DC1, DCm vient simplement passer la requête à une unité NC.AR en charge de réaliser un arbitrage entre requêtes non-critiques selon une politique d'arbitrage quelconque.
Elle peut venir stocker une valeur prédéfinie dans le registre dédié à l'échéance, par exemple la valeur maximale pouvant être prise par une échéance.
Le circuit d'arbitrage CA comprend par ailleurs une unité Min.extractor configurée pour recevoir des unités de calcul d'échéance de traitement DCO, DC1, DCm la valeur 10 stockée dans leur registre dédié à l'échéance, déterminer quelle est la plus petite valeur et fournir à l'unité d'arbitrage AR un identifiant de la requête ayant l'échéance la plus proche par rapport à l'instant courant.
Le circuit d'arbitrage CA comprend également une unité SL configurée pour recevoir des unités de calcul d'échéance de traitement DCO, DC1, DCm la valeur stockée dans leur 15 registre dédié à la marge et fournir à l'unité d'arbitrage AR la marge de traitement correspondant au programme critique auquel le prochain créneau temporel est alloué.
A chaque unité de temps, si une requête en attente peut être traitée, l'unité d'arbitrage AR sélectionne une requête (venant de l'unité Min.extractor ou de l'unité NC.AR) et vérifie si elle peut être traitée immédiatement.
Pour ce faire, si l'unité de temps 20 correspond au début d'un créneau temporel, la requête est traitée.
Sinon, l'unité d'arbitrage détermine si le traitement de la requête peut déborder sur le créneau temporel suivant.
Comme on l'a vu précédemment, un tel débordement sur le créneau temporel suivant est autorisé si l'une ou l'autre des deux conditions suivantes est remplie : 25 - Le créneau suivant est alloué au programme émetteur de la requête sélectionnée ; - Le programme auquel le créneau suivant est alloué a accumulé suffisamment de marge pour permettre un débordement de la requête sélectionnée sur son créneau.
À titre d'exemple, une marge suffisante correspond à la taille d'un 30 créneau.
15 A la terminaison du traitement d'une requête émise par un programme critique, l'unité d'arbitrage AR en notifie les unités de calcul d'échéance de traitement DCO, DC1, DCm via un lien Ack, ce qui déclenche la mise à jour du calcul de la marge temporelle associée au programme critique dont la requête vient d'être traitée.
Dans un mode de réalisation possible de l'invention, les coeurs peuvent réaliser du multitâche préemptif, c'est-à-dire distribuer du temps-processeur entre différents programmes.
Un programme s'exécutant sur l'un des coeurs peut ainsi être préempté au profit d'un autre programme.
Le programme en cours d'exécution est alors interrompu pour permettre à Vautre programme de s'exécuter.
10 Or un créneau temporel est en réalité associé à chaque coeur.
Ce créneau lui est alloué lorsque le coeur exécute un programme critique.
En revanche, lorsque le coeur exécute un programme non-critique, le créneau peut être exploité pour le traitement d'autres requêtes en provenance d'autres coeurs.
Dans le cas où un programme critique souhaite préempter un programme non-critique (selon l'ordonnancement du multitâche 15 préemptif) et que ce programme non-critique est en attente de traitement d'une requête d'accès à la ressource partagée, cette requête doit être traitée pour que le programme non-critique puisse effectivement être préempté.
Dans le cadre de ce mode de réalisation, afin de borner l'attente de traitement de la requête non-critique, celle-ci hérite de la criticité du programme critique.
Le coeur devient 20 alors critique et le créneau temporel qui lui est associé lui est à nouveau dédié pour le traitement de la requête.
Le calcul de l'échéance se base donc sur la prochaine occurrence du créneau temporel qui lui est à nouveau dédié.
Dans une variante possible, la valeur actuelle de la marge de traitement du programme critique préemptant le programme non-critique peut être ajoutée pour déterminer cette échéance.
25 Il est possible également qu'un programme critique vienne préempter un autre programme critique ayant une requête en attente de traitement du fait d'une marge de traitement permettant le traitement d'autres requêtes.
Un calcul similaire peut alors être réalisé afin de réduire le délai d'attente avant la réalisation de la préemption.
Le procédé selon l'invention peut ainsi comprendre une étape de préemption au 30 profit d'un programme critique d'un premier programme ayant émis une requête d'accès 16 à la ressource partagée en attente de traitement.
Cette étape de préemption comprend le calcul, éventuellement en tenant compte de la marge de traitement du programme critique, d'une échéance de traitement de ladite requête correspondant à la fin d'un créneau temporel alloué au programme critique.
Le circuit de multiplexage temporel CMT peut réaliser une telle gestion des préemptions de la manière suivante.
Le coeur réalisant la préemption en notifie l'unité de calcul d'échéance qui lui est associé.
Si un programme non-critique A est préempté au profit d'un programme critique B, la présence d'une requête issue du programme non-critique A dans l'unité NC.AR est vérifiée.
Si une telle requête existe, alors celle-ci est 10 retirée de l'unité NC.AR et est considérée comme critique dans la suite des étapes du procédé précédemment décrit en considérant potentiellement la marge de traitement du programme critique B pour le calcul de l'échéance de traitement désormais associée au programme A.
Si un programme critique A est préempté au profit d'un programme critique B, de manière similaire, la marge de traitement du programme critique B peut 15 être utilisée pour calculer la nouvelle échéance de traitement du programme A.
L'invention n'est pas limitée au procédé précédemment décrit mais s'étend également à un circuit de multiplexage temporel d'accès concurrents à une ressource partagée requis par des programmes informatiques, configuré pour mettre en oeuvre le procédé,

Claims (10)

  1. REVENDICATIONS1. Procédé mis en oeuvre par ordinateur d'arbitrage entre des programmes informatiques cherchant à accéder concurremment à une ressource partagée (MM) en émettant chacun une requête d'accès, le procédé réalisant un accès multiple à répartition dans le temps selon lequel le temps est divisé en créneaux temporels chacun alloué à un programme critique pour un accès à la ressource partagée, chaque créneau temporel comprenant une pluralité d'unités de temps, procédé dans lequel une marge de traitement (MA1, MA2) est associée à chaque programme critique pour retarder une échéance de traitement (11) d'une requête d'accès émise par le programme critique, procédé caractérisé en ce qu'il comprend, à chaque unité de temps, une étape de sélection d'une requête d'accès (Bo, ro, c1) parmi une ou plusieurs requêtes d'accès en attente et une étape de détermination d'une autorisation de traitement immédiat de la requête d'accès sélectionnée, ladite étape de détermination comprenant pour une unité de temps ne correspondant pas au début d'un créneau temporel, lorsque le programme critique (A) auquel le prochain créneau temporel est alloué n'a pas émis la requête sélectionnée, l'autorisation du traitement immédiat de la requête sélectionnée (Bo, co, si la marge de traitement du programme critique auquel le prochain créneau temporel est alloué est supérieure à un seuil.
  2. 2. Procédé selon la revendication 1, dans lequel l'étape de détermination comprend, pour une unité de temps ne correspondant pas au début d'un créneau temporel, lorsque le programme critique auquel le prochain créneau temporel est alloué (B) n'a pas émis la requête sélectionnée (A0) et lorsque la marge de traitement du programme critique auquel le prochain créneau temporel est alloué est inférieure au seuil, la mise en attente de la requête sélectionnée. 18
  3. 3. Procédé selon l'une des revendications 1 à 2, dans lequel le seuil correspond à l'écart temporel entre l'unité de temps à laquelle l'étape de détermination est réalisée et l'unité de temps correspondant au début du prochain créneau temporel. 5
  4. 4. Procédé selon l'une des revendications 1 à 3, dans lequel ladite étape de détermination comprend pour une unité de temps ne correspondant pas au début d'un créneau temporel, lorsque le programme critique (A) auquel le prochain créneau temporel est alloué a émis la requête sélectionnée, l'autorisation du traitement immédiat de la requête sélectionnée (A1). 10
  5. 5. Procédé selon l'une des revendications 1 à 4, dans lequel ladite étape de détermination comprend, pour une unité de temps correspondant au début d'un créneau temporel, l'autorisation du traitement immédiat de la requête sélectionnée (A0). 15
  6. 6. Procédé selon l'une des revendications 1 à 5, dans lequel l'étape de sélection comprend, en présence d'une requête d'accès (B1) en attente d'un programme critique et d'une requête d'accès (co) en attente d'un programme non-critique, la sélection de la requête d'accès du programme non-critique (c0) si l'échéance de traitement de la requête d'accès (B1) du programme critique est postérieure à la fin du prochain créneau temporel. 20
  7. 7. Procédé selon l'une des revendications 1 à 6, dans lequel la marge de traitement d'un programme critique est mise à jour à chaque terminaison d'un traitement d'une requête d'accès du programme critique pour correspondre au nombre d'unités de temps séparant la terminaison du traitement de la requête d'accès et 25 l'échéance de traitement de la requête d'accès.
  8. 8. Procédé selon la revendication 7, dans lequel l'échéance de traitement d'une requête d'accès d'un programme critique correspond à la fin d'un créneau temporel alloué au programme critique qui est le premier à débuter après une date correspondant à une date d'émission de la requête d'accès retardée par ajout de la marge de traitement du programme critique. 19
  9. 9. Procédé selon l'une des revendications 1 à 8, comprenant en outre la préemption au profit d'un programme critique d'un premier programme ayant émis une requête d'accès à la ressource partagée en attente de traitement, ladite préemption 5 comprenant le calcul d'une échéance de traitement de ladite requête correspondant à la fin d'un créneau temporel alloué au programme critique.
  10. 10. Circuit de multiplexage temporel (CMT) d'accès concurrents à une ressource partagée requis par des programmes informatiques, caractérisé en ce qu'il est configuré 10 pour mettre en oeuvre le procédé selon l'une des étapes 1 à 9.
FR1860117A 2018-10-31 2018-10-31 Procede et circuit de multiplexage temporel d'acces concurrents a une ressource informatique Active FR3087982B1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
FR1860117A FR3087982B1 (fr) 2018-10-31 2018-10-31 Procede et circuit de multiplexage temporel d'acces concurrents a une ressource informatique
PCT/FR2019/052513 WO2020089542A1 (fr) 2018-10-31 2019-10-22 Procédé et circuit de multiplexage temporel d'accès concurrents à une ressource informatique
US17/289,270 US20210397488A1 (en) 2018-10-31 2019-10-22 Time-division multiplexing method and circuit for concurrent access to a computer resource
EP19813627.7A EP3850486A1 (fr) 2018-10-31 2019-10-22 Procédé et circuit de multiplexage temporel d'accès concurrents à une ressource informatique

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1860117A FR3087982B1 (fr) 2018-10-31 2018-10-31 Procede et circuit de multiplexage temporel d'acces concurrents a une ressource informatique

Publications (2)

Publication Number Publication Date
FR3087982A1 true FR3087982A1 (fr) 2020-05-01
FR3087982B1 FR3087982B1 (fr) 2020-12-04

Family

ID=65861387

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1860117A Active FR3087982B1 (fr) 2018-10-31 2018-10-31 Procede et circuit de multiplexage temporel d'acces concurrents a une ressource informatique

Country Status (4)

Country Link
US (1) US20210397488A1 (fr)
EP (1) EP3850486A1 (fr)
FR (1) FR3087982B1 (fr)
WO (1) WO2020089542A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0886218A2 (fr) * 1997-06-19 1998-12-23 Advanced Micro Devices, Inc. Schéma à multiplexage temporel de résolution d'interblocage dans l'arbitrage distribué
EP1550953A1 (fr) * 2003-12-29 2005-07-06 CNX S.p.A. Méthode et dispositif implémentant le multiplexage temporel d'accès à une mémoire RAM à deux ports de plusieurs sources de données disposant d'horloges indépendantes.
US20090217280A1 (en) * 2008-02-21 2009-08-27 Honeywell International Inc. Shared-Resource Time Partitioning in a Multi-Core System
US20140223114A1 (en) * 2013-02-06 2014-08-07 Lsi Corporation Buffer for Managing Data Samples in a Read Channel

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7603503B1 (en) * 2006-09-18 2009-10-13 Nvidia Corporation Efficiency based arbiter
US8695002B2 (en) * 2009-10-20 2014-04-08 Lantiq Deutschland Gmbh Multi-threaded processors and multi-processor systems comprising shared resources
US20160283272A1 (en) * 2015-03-25 2016-09-29 Intel Corporation Shared resource access control method and apparatus
US10908955B2 (en) * 2018-03-22 2021-02-02 Honeywell International Inc. Systems and methods for variable rate limiting of shared resource access
CN110556390A (zh) * 2018-05-31 2019-12-10 松下知识产权经营株式会社 摄像装置
FR3082029B1 (fr) * 2018-06-05 2020-07-10 Thales Controleur de partage de ressources d'une plate-forme informatique et procede associe de partage des ressources

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0886218A2 (fr) * 1997-06-19 1998-12-23 Advanced Micro Devices, Inc. Schéma à multiplexage temporel de résolution d'interblocage dans l'arbitrage distribué
EP1550953A1 (fr) * 2003-12-29 2005-07-06 CNX S.p.A. Méthode et dispositif implémentant le multiplexage temporel d'accès à une mémoire RAM à deux ports de plusieurs sources de données disposant d'horloges indépendantes.
US20090217280A1 (en) * 2008-02-21 2009-08-27 Honeywell International Inc. Shared-Resource Time Partitioning in a Multi-Core System
US20140223114A1 (en) * 2013-02-06 2014-08-07 Lsi Corporation Buffer for Managing Data Samples in a Read Channel

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
FAROUK HEBBACHE; MATHIEU JAN; FLORIAN BRANDNER; LAURENT PAUTET: "Dynamic Arbitration of Memory Requests with TDM-like Guarantees", PROCEEDINGS OF THE CRTS 2017 WORKSHOP

Also Published As

Publication number Publication date
US20210397488A1 (en) 2021-12-23
WO2020089542A1 (fr) 2020-05-07
FR3087982B1 (fr) 2020-12-04
EP3850486A1 (fr) 2021-07-21

Similar Documents

Publication Publication Date Title
US10606653B2 (en) Efficient priority-aware thread scheduling
EP2987081B1 (fr) Procédé d'allocation temporelle de tâches permettant une récupération d'erreur deterministe en temps réel
US11606261B2 (en) Data service overload detection and mitigation
US11150999B2 (en) Method, device, and computer program product for scheduling backup jobs
US20170177277A1 (en) Managing data operations in a quorum-based data replication system
EP2203817A2 (fr) Procede de gestion des preemptions dans un systeme d'exploitation en temps reel
FR3019339A1 (fr) Procede de transfert de donnees entre taches temps reel utilisant un controleur memoire dma
FR3047821A1 (fr) Procede et dispositif de gestion d'un appareil de commande
EP2850520B1 (fr) Procede de gestion d'une execution de taches dans un systeme informatique
CN112887436B (zh) 一种共识方法、共识节点和流水线方式的区块链系统
EP3660677B1 (fr) Procédé et dispositif de surveillance d'application(s) logicielle(s) avec période temporelle tampon précédant une section réservée pour un ensemble de ressource(s) partagée(s), programme d'ordinateur et système avionique associés
FR3087982A1 (fr) Procede et circuit de multiplexage temporel d'acces concurrents a une ressource informatique
WO2012038000A1 (fr) Procede de gestion de taches dans un microprocesseur ou un ensemble de microprocesseurs
FR2980611A1 (fr) Circuit pour planifier le deroulement d'un traitement de donnees
WO2022190246A1 (fr) Dispositif de gestion de microservices, procédé de gestion de microservices et programme
US20230004314A1 (en) Method of managing jobs in an information system and associated system
WO2005010633A2 (fr) Procédé de gestion de l'exécution d'au moins un programme sur plusieurs calculateurs
WO2023052730A1 (fr) Procédé de supervision et superviseur du pilotage d'un traitement parallèle distribué dans un réseau de communication, dispositif de fourniture de services et programme le mettant en œuvre
EP4148569A1 (fr) Procédé d'ordonnancement d'un ensemble de taches de calcul dans un supercalculateur
FR3106223A1 (fr) Programmation optimale de requêtes en fonction des exigences de fraîcheur de données
FR3106224A1 (fr) Programmation optimale de requêtes pour l’optimisation de l’utilisation de ressources
EP2860630A1 (fr) Procédé de transfert de données dans un environnement dynamique
EP3910915A1 (fr) Procédé de mitigation de contentions pour une application opérationnelle, produit programme d'ordinateur et procédé de détermination d'une application stressante associés
WO2021156308A2 (fr) Procede de gestion de donnees echantillonnees partagees entre plusieurs unites de traitement
CN116308790A (zh) 交易请求的资源调用方法、系统、装置及电子设备

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20200501

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

TQ Partial transmission of property

Owner name: INSTITUT MINES-TELECOM, FR

Effective date: 20211119

Owner name: COMMISSARIAT A L'ENERGIE ATOMIQUE ET AUX ENERG, FR

Effective date: 20211119

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6