EP3850486A1 - Procédé et circuit de multiplexage temporel d'accès concurrents à une ressource informatique - Google Patents

Procédé et circuit de multiplexage temporel d'accès concurrents à une ressource informatique

Info

Publication number
EP3850486A1
EP3850486A1 EP19813627.7A EP19813627A EP3850486A1 EP 3850486 A1 EP3850486 A1 EP 3850486A1 EP 19813627 A EP19813627 A EP 19813627A EP 3850486 A1 EP3850486 A1 EP 3850486A1
Authority
EP
European Patent Office
Prior art keywords
processing
request
time
critical program
access
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.)
Pending
Application number
EP19813627.7A
Other languages
German (de)
English (en)
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
Publication of EP3850486A1 publication Critical patent/EP3850486A1/fr
Pending legal-status Critical Current

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

Definitions

  • the field of the invention is that of real-time computer systems for which the execution time of tasks, and in particular the execution time in the worst case (called WCET for "Worst Case Execution Time”), must be known to ensure validation and guarantee safety.
  • the invention more particularly aims to improve the rate of use of a resource shared by computer programs executing in parallel while guaranteeing the estimation of the WCET of these programs by means of a time-division multiplex arbitration policy. for access to the shared resource.
  • Real-time systems must react reliably, which implies both being certain of the result produced by their programs but also knowing the time they take to execute.
  • the worst-case execution times are therefore fundamental data for the validation and safety of such real-time systems, and even more in the context of autonomous real-time systems (robotics, autonomous car, GPS) for which safety is essential.
  • time-division multiplexing TDM
  • time-division multiplexing TDM
  • time slots each allocated to a predefined program for exclusive access to the shared resource.
  • the access time to the resource shared by a program can then be easily limited (it corresponds to the maximum delay until reaching the next time slot allocated to the program), the bandwidth offered to a program is independent of the other programs and the WCET programs can thus be determined.
  • the access time to the resource shared by a program depends on the scheduling of the time slots allocated to it.
  • this scheduling is generally static since it is carried out during the design of the system, before the programs are executed. It generally includes the assignment of a sequence of time slots to different programs, this sequence repeating periodically (we speak of TDM period).
  • the time slots of a TDM period are only used by the programs if they have a request to access the shared resource to be sent. When this is not the case, these time slots are therefore unused.
  • a basic TDM arbitration policy is therefore said to be idle because these time slots are not recovered by the other programs in order to reduce their access time to the shared resource.
  • TMDds dynamic TDM with slack counters
  • a processing margin counter (“slack counter” in English) is associated with each critical program. This counter indicates the number of time slots separating the effective termination of the processing of an access request from its processing deadline. This counter is used to delay, if necessary, the deadline for processing the next access request from the critical program.
  • the arbitration carried out at the start of each time slot then consists in selecting the pending access request having the closest processing deadline, independently of the critical program to which this time slot is allocated. If this TDMds arbitration policy makes it possible to improve the use of the shared resource, it nevertheless remains room for improvement.
  • the length of the time slots must be greater than or equal to the maximum time taken by a request, sent in isolation, to be processed by the shared resource.
  • the shared resource is a memory
  • the access time of a write request is less than the access time of a read request, since in this second case the memory must send the requested data to destination of the requesting program.
  • the access time to a memory can depend on the history of the requests emitted by the other programs. An upper bound for processing requests must therefore be identified to determine the length of the time slots. However, the processing of most requests will by definition end before this terminal, so that the TDMds arbitration policy remains idle.
  • the object of the invention is to propose an improved arbitration policy which makes it possible to optimize the use of the shared resource while guaranteeing the temporal predictability of the processing of requests for access to the shared resource originating from critical programs.
  • the invention provides a computer implemented method of arbitration between computer programs seeking to access concurrently a shared resource by each issuing an access request.
  • the method realizes a time division multiple access according to which the time is divided into time slots each allocated to a critical program for access to the shared resource, each time slot comprising a plurality of time units.
  • a processing margin is associated with each critical program in order to delay a processing deadline for an access request sent by the critical program.
  • the method comprises, at each time unit, a step of selecting an access request from one or more pending access requests and a step of determining an authorization for immediate processing of the selected access request .
  • the determination step comprises for a time unit not corresponding to the start of a time slot, when the critical program to which the next time slot is allocated has not issued the selected request, the authorization for immediate processing of the selected request if the processing margin of the critical program to which the next time slot is allocated is greater at a threshold.
  • the determination step comprises, for a time unit not corresponding to the start of a time slot, when the critical program to which the next time slot is allocated has not sent the selected request and when the processing margin of the critical program to which the next time slot is allocated is below the threshold, putting the selected request on hold;
  • the threshold corresponds to the time difference between the time unit at which the determination step is carried out and the time unit corresponding to the start of the next time slot;
  • the determination step comprises, for a time unit not corresponding to the start of a time slot, when the critical program to which the next time slot is allocated has sent the selected request, authorizing the immediate processing of the selected request ;
  • the determination step comprises, for a time unit corresponding to the start of a time slot, authorizing the immediate processing of the selected request;
  • the selection step comprises, in the presence of an access request awaiting a critical program and an access request awaiting a non-critical program, the selection of the access request of the non-critical program if the deadline for processing the access request of the critical program is later than the end of the next time slot;
  • the processing margin of a critical program is updated at each termination of processing of an access request from the critical program to correspond to the number of time units separating the termination of processing from the request for access and the deadline for processing the access request; - the deadline for processing a request to access a critical program corresponds to the end of a time slot allocated to the critical program which is the first to start after a date corresponding to a date of issue of the request access delayed by adding the processing margin of the critical program;
  • Figures la and lb are diagrams illustrating the principle of arbitration carried out in the invention to authorize or not an immediate access to the shared resource
  • FIG. 2 is a state machine representing a sequence of steps of the method according to the invention.
  • FIG. 3 is a timing diagram showing an example of arbitration operated by the method according to the invention.
  • FIG. 4 is a diagram of a circuit configured to implement the method according to the invention.
  • a computer implemented method of arbitrating between computer programs seeking concurrent access to a shared resource by each issuing an access request is typically implemented on a multi-core hardware architecture where each core CO, Cl, Cm is configured to execute a program capable of requiring access to the shared resource during its execution.
  • Each core can have a private cache memory and the shared resource is for example a shared memory MM.
  • a hardware implementation configured to implement this method takes the form of a time division multiplexing circuit CMT interposed between the cores and the shared resource.
  • the method according to the invention realizes a multiple access with distribution in time according to which the time is divided into time slots (slots in English) each allocated to a critical program for an access to the shared resource, each time slot comprising a plurality of time units (a time unit is for example a clock cycle).
  • FIGS. 1a, 1b and 3 show an example of such a time division into slots of identical sizes alternately allocated to a first critical program A (the slots having an odd number) and to a second critical program B (the slots with an even number).
  • a critical program is for example a program subject to time constraints and for which it is desired to be able to limit the execution time in the worst case (WCET).
  • the method according to the invention associates a processing deadline with each access request sent by a critical program. This deadline corresponds to the moment at which the processing of the critical program request must be completed at the latest and must be respected.
  • the method also relates to access requests sent by programs not subject to time constraints, i.e. non-critical programs, and for which no notion of processing deadline is necessary.
  • the method according to the invention also exploits a processing margin associated with each critical program, this processing margin being used to possibly delay a processing deadline for an access request sent by the critical program, in particular when the program critic has accumulated sufficient processing margin.
  • this processing margin being used to possibly delay a processing deadline for an access request sent by the critical program, in particular when the program critic has accumulated sufficient processing margin.
  • arbitration decisions are made at the start of each time slot and are only based on requests awaiting processing. It is then possible to delay a request from a critical program, depending on the deadline for processing this request.
  • the processing margin is not used during arbitration decisions and has only an effect on the calculation of the processing times for requests.
  • the invention is based on the fact of recognizing that a processing margin is also valid when a critical program has not (yet) issued a request for access to the resource.
  • the shared resource can then start processing any of the pending requests if this lower bound is later than the end of the next time slot. This ensures that the memory can partially process the request in the current time slot, while completing this processing in the next time slot without violating the behavior in the worst case.
  • the invention thus proposes to exploit the processing margins, not at the start of each time slot, but at each time unit.
  • the processing margin associated with the critical program to which the next time slot is allocated is consulted to determine whether a request can be immediately processed by the shared resource.
  • the purpose of this consultation is to check whether an overflow of the processing time of the request on the next time slot does not call into question the respect of the processing deadline associated with a possible request which would be issued by the critical program to which this next time slot is allocated.
  • the processing margin of a critical program is updated at each termination of processing of an access request from the critical program to correspond to the number of time units separating the termination of the processing of the access request and the deadline for processing the access request.
  • the deadline for processing a request for access to a critical program corresponds to the end of the time slot allocated to the critical program which is the first to start after a date corresponding to a date of issue of the request for access delayed by adding the processing margin of the critical program.
  • FIGS. 1a and 1b show an example in which at a time unit corresponding to time t, access to the resource is released and it is checked whether a pending request can be processed.
  • This time unit t does not correspond to the start of the time slot allocated to the critical program B which starts at to.
  • the processing margin MAY of the critical program A to which the next time slot is allocated (slot n ° 3) is large enough to allow delaying the processing time of a request which would be issued by the program A between t and ti. Instead of this deadline corresponding to the end 11 of the next time slot allocated to program A, it is delayed to correspond to the end El of time slot No. 5 allocated to program A which follows a date corresponding to a date of issue of the access request delayed by adding the processing margin of the critical program MAY. This amounts to determining that the processing margin MAI is greater than the number of time units separating t and ti.
  • FIG. 1b shows a state machine representative of an embodiment of the method according to the invention.
  • the reference “Rac” designates the issue of a request for access to the shared resource.
  • an “NC-AR” arbitration of non-critical requests is carried out according to a policy of arbitration (for example fixed priority or first come first served) to come and select one.
  • the selection includes the choice, among the critical program requests, of the request presenting the closest processing deadline.
  • the result of the selection is therefore either the critical request presenting the nearest processing deadline, or the non-critical request resulting from the “NC-AR” arbitration.
  • the access request of the user is selected. non-critical program if the processing deadline for the critical program is later than the end date of the next time slot.
  • the threshold can correspond, as we have seen above, to the time difference between the time unit t at which the determination step is carried out and the time unit ti corresponding to the start of the next time slot. Alternatively, the threshold can correspond to the size of a time slot.
  • the “MAJ MTs” update of the processing margin of this critical program is updated.
  • the processing margin of a critical program is updated at each termination of processing of an access request from the critical program to correspond to the number of time units separating the termination of processing from the access request and the deadline for processing the access request.
  • FIG. 3 shows an example of implementation of this method with two critical programs A and B, a non-critical program c and slots having a size of 8 time units.
  • the current value of the processing margin is indicated by the exponent of each request (for example the request Ai of critical program A has a processing margin of 10 D, or 10 time units).
  • a first access request Ao from the critical program A is firstly sent during the slot n ° l allocated to the program A.
  • the processing margin of A is zero and its processing deadline is fixed at the end of the next slot allocated to A (slot n ° 3).
  • the processing margin for B owner of the next slot # 2 is zero and it is not possible to perform immediate processing of Ao before the start of the next slot # 2.
  • the processing of Ao lasts six units of time and A has therefore accumulated a processing margin of 10 units of time.
  • a first access request Bo of the critical program B is issued during the slot n ° 2.
  • the next slot n ° 3 is allocated to the program A which has accumulated enough processing margin so that the immediate processing of the Bo request is authorized without risk that the overflowing of the processing of Bo on the niche 3 will jeopardize compliance with the processing deadline associated with a possible request sent by the critical program A to which slot No. 3 is allocated.
  • Program B sees its processing margin increase to 10 time units.
  • a first access request co from the non-critical program c and a second access request Bi from the critical program B are simultaneously sent.
  • the co request of the non-critical program is selected because the critical program B does not own the next slot # 5, and is immediately processed because the critical program A owner of the next slot # 5 has accumulated enough processing margin (in this case 10 time units).
  • the request Bi is processed immediately since program B owns the next slot n ° 6.
  • a second access request Ai of the critical program A and a second access request ci of the non-critical program c are sent.
  • the latter sees its processing margin increase to 7 time units.
  • the request Ai is selected and immediately processed because program A owns the next niche 7.
  • the processing of the request Ai ends during the slot n ° 6, and the processing margin of the program A increases to 11 time units.
  • the second access request ci of the non-critical program c is selected because the deadline for processing request B 2 is after the end of time slot 7, then immediately processed because the processing margin of program A owning the next time slot 7 is sufficient.
  • the request B 2 is immediately processed because the program B owns the next slot n ° 8.
  • the latter sees its processing margin increase to 5 units of time.
  • a third access request A 2 of the critical program A is then sent which, in view of the processing margin which then benefits the program A, has a processing deadline at the end of slot n ° ll.
  • program A owns the next slot n ° 9 and its request A 2 can be immediately processed.
  • FIG. 4 shows a possible implementation of a time division multiplexing circuit CMT configured to implement the method according to the invention.
  • the circuit CMT is interposed between cores C0, Cl, Cm each executing a program and a shared resource.
  • a processing margin is associated with each core executing a critical program.
  • a counter can for this be implemented in the form of a register storing a number of time units not used by the heart. This counter is part of the execution context of the critical program, and its value is therefore saved / restored at each preemption / resumption of program execution.
  • the CMT circuit includes an AR arbitration unit and a MUX multiplexer controlled by the arbitration unit to achieve selective access of one of the cores to the shared resource.
  • the CMT circuit also includes a processing deadline calculation unit DC0, DC1, DCm associated with each of the cores. This unit is configured to receive an access request R0, RI, Rm sent by a program executed on the core with which it is associated and to calculate the deadline for processing the request when it is sent by a critical program.
  • the unit DC0, DC1, DCm can include dedicated registers to store the calculated due date as well as the current processing margin.
  • the unit DC0, DC1, DCm simply passes the request to a unit NC.AR in charge of carrying out an arbitration between non-critical requests according to any arbitration policy. It can come to store a predefined value in the register dedicated to the deadline, for example the maximum value that can be taken by a deadline.
  • the arbitration circuit CA also includes a Min.extractor unit configured to receive processing deadline calculation units DC0, DC1, DCm the value stored in their register dedicated to the deadline, determining which is the smallest value and provide the arbitration unit AR with an identifier of the request having the closest deadline with respect to the current instant.
  • a Min.extractor unit configured to receive processing deadline calculation units DC0, DC1, DCm the value stored in their register dedicated to the deadline, determining which is the smallest value and provide the arbitration unit AR with an identifier of the request having the closest deadline with respect to the current instant.
  • the arbitration circuit CA also includes a unit SL configured to receive processing deadline calculation units DC0, DC1, DCm the value stored in their register dedicated to the margin and provide the arbitration unit AR with the margin of processing corresponding to the critical program to which the next time slot is allocated.
  • the AR arbitration unit selects a request (from the Min.extractor unit or the NC.AR unit) and checks whether it can be processed at once. To do this, if the time unit corresponds to the start of a time slot, the request is processed. Otherwise, the arbitration unit determines whether the processing of the request may extend to the next time slot. As we saw previously, such an overflow on the following time slot is authorized if one or the other of the following two conditions is met:
  • the next slot is allocated to the program sending the selected request.
  • the program to which the next slot is allocated has accumulated sufficient margin to allow an overflow of the selected request in its slot.
  • a sufficient margin corresponds to the size of a niche.
  • the cores can perform preemptive multitasking, that is to say distribute processor time between different programs.
  • a program running on one of the cores can thus be preempted in favor of another program.
  • the running program is then interrupted to allow the other program to run.
  • a time slot is actually associated with each heart. This window is allocated to it when the heart executes a critical program.
  • the slot can be exploited for processing other requests coming from other cores.
  • a critical program wishes to preempt a non-critical program (according to the scheduling of preemptive multitasking) and this non-critical program is awaiting processing of a request for access to the shared resource, this request must be processed so that the non-critical program can actually be preempted.
  • the latter in order to limit the waiting time for processing the non-critical request, the latter inherits the criticality of the critical program.
  • the heart then becomes critical and the time slot associated with it is again dedicated to it for processing the request.
  • the calculation of the deadline is therefore based on the next occurrence of the time slot which is again dedicated to it.
  • the current value of the processing margin of the critical program preempting the non-critical program can be added to determine this deadline.
  • the method according to the invention can thus include a preemption step for the benefit of a critical program of a first program having issued an access request to the shared resource awaiting processing.
  • This preemption step includes the calculation, possibly taking into account the processing margin of the critical program, of a processing deadline for said request corresponding to the end of a time slot allocated to the critical program.
  • the time division multiplexing circuit CMT can carry out such management of the preemptions in the following manner.
  • the pre-emptive core notifies the due date calculation unit associated with it. If a non-critical program A is preempted in favor of a critical program B, the presence of a request from the non-critical program A in the unit NC.AR is checked. If such a request exists, then this request is withdrawn from the unit NC.AR and is considered to be critical in the rest of the steps of the method previously described while potentially considering the processing margin of the critical program B for the calculation of the processing deadline now associated with program A. If a critical program A is pre-empted in favor of a critical program B, similarly, the processing margin of critical program B can be used to calculate the new processing deadline for program A .
  • the invention is not limited to the method described above but also extends to a time division multiplexing circuit for concurrent access to a shared resource required by computer programs, configured to implement the method, and in particular to the CMT circuit. previously described.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multi Processors (AREA)
  • Bus Control (AREA)

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-cœurs 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 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.
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 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 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 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. 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 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 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 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 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é. 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 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 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 œ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. Une marge de traitement est 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 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 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é 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 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 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 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 ; - 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.
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 :
- 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 ;
- 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 œuvre le procédé selon l'invention.
EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS
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. En référence à la figure 4 qui sera décrite plus en détail ultérieurement, ce procédé est typiquement mis en œuvre sur une architecture matérielle multi-cœurs où chaque cœur 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 cœur 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 œuvre ce procédé prend la forme d'un circuit de multiplexage temporel CMT interposé entre les cœurs 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 (slots en anglais) 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 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 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 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.
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 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 reconnaître qu'une marge de traitement est é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 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 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 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 terminaison du traitement de la requête d'accès et l'échéance de traitement de la 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 à ti.
Sur la figure la, la marge de traitement MAI 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 ti. 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 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 MAI. Cela revient à déterminer que la marge de traitement MAI est supérieure au nombre d'unités de temps séparant t et ti.
Sur la figure lb, la marge de traitement MA2 du programme critique A auquel le 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 ti. 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 ti. Dans un tel 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. 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 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 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.
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 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 créneau temporel (t¹ t0), lorsque le programme critique auquel le prochain créneau 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 ti correspondant au début du prochain créneau temporel. Alternativement, le seuil peut correspondre à la taille d'un créneau temporel.
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¹ t0), 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 »).
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 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 requête d'accès.
On a représenté sur la figure 3 un exemple de mise en œuvre 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 Ai du programme critique A bénéficie d'une marge de traitement de 10 D, 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°l 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.
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 é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 Bi du programme critique B sont simultanément émises. La requête co du programme non-critique est sélectionnée car le 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 Bi car le programme B est propriétaire du prochain créneau n°6.
Au cours du traitement de la requête Bi, une deuxième requête d'accès Ai du programme critique A et une deuxième requête d'accès ci du programme non-critique c sont émises. A la terminaison du traitement de la requête Bi au cours du créneau n°6, celui-ci voit sa marge de traitement passer à 7 unités de temps. La requête Ai est sélectionnée et immédiatement traitée car le programme A est propriétaire du prochain créneau n°7. Le traitement de la requête Ai 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 Ai deux requêtes sont en compétition : la deuxième requête d'accès ci 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 ci 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 ci, la requête B2 est immédiatement traitée car le programme B est propriétaire du prochain 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°ll. Néanmoins, le programme A est propriétaire du prochain créneau n°9 et sa 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 œuvre le procédé selon l'invention. Le circuit CMT est interposé entre des cœurs C0, Cl, Cm exécutant chacun un programme et une ressource partagée. Une marge de traitement est associée à chaque cœur 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 cœur. 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 commandé par l'unité d'arbitrage pour réaliser l'accès sélectif de l'un des cœurs à la ressource partagée. Le circuit CMT comprend par ailleurs une unité de calcul d'échéance de traitement DC0, DC1, DCm associée à chacun des cœurs. Cette unité est configurée pour réceptionner une requête d'accès R0, RI, Rm émise par un programme exécuté sur le cœur auquel elle est associée et pour calculer l'échéance de traitement de la requête lorsque celle-ci est émise par un programme critique. L'unité DC0, DC1, DCm peut 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é DC0, 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 DC0, DC1, DCm la valeur 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 DC0, DC1, DCm la valeur stockée dans leur 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 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 :
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 créneau. 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 cœurs 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 cœurs peut ainsi être préempté au profit d'un autre programme. Le programme en cours d'exécution est alors interrompu pour permettre à l'autre programme de s'exécuter.
Or un créneau temporel est en réalité associé à chaque cœur. Ce créneau lui est alloué lorsque le cœur exécute un programme critique. En revanche, lorsque le cœur exécute un programme non-critique, le créneau peut être exploité pour le traitement d'autres requêtes en provenance d'autres cœurs. Dans le cas où un programme critique souhaite préempter un programme non-critique (selon l'ordonnancement du multitâche 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 cœur devient 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.
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 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. 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 cœur 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 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 ê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 œuvre le procédé, et notamment au circuit CMT précédemment décrit.

Claims

REVENDICATIONS
1. Procédé mis en œuvre 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 (MAI, 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, co, ci) 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, c0, ci) si la marge de traitement du programme critique auquel le prochain créneau temporel est alloué est supérieure à un seuil.
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 (Ao) 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.
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.
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 (Ai).
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 (Ao).
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 (Bi) 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 (co) si l'échéance de traitement de la requête d'accès (Bi) du programme critique est postérieure à la fin du prochain créneau temporel.
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 l'échéance de traitement de la requête d'accès.
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.
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 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. 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é pour mettre en œuvre le procédé selon l'une des étapes 1 à 9.
EP19813627.7A 2018-10-31 2019-10-22 Procédé et circuit de multiplexage temporel d'accès concurrents à une ressource informatique Pending EP3850486A1 (fr)

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
EP3850486A1 true EP3850486A1 (fr) 2021-07-21

Family

ID=65861387

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19813627.7A Pending EP3850486A1 (fr) 2018-10-31 2019-10-22 Procédé et circuit de multiplexage temporel d'accès concurrents à une ressource informatique

Country Status (4)

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

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6061361A (en) * 1997-06-19 2000-05-09 Advanced Micro Devices, Inc. Time multiplexed scheme for deadlock resolution in distributed arbitration
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.
US7603503B1 (en) * 2006-09-18 2009-10-13 Nvidia Corporation Efficiency based arbiter
US20090217280A1 (en) * 2008-02-21 2009-08-27 Honeywell International Inc. Shared-Resource Time Partitioning in a Multi-Core System
US8695002B2 (en) * 2009-10-20 2014-04-08 Lantiq Deutschland Gmbh Multi-threaded processors and multi-processor systems comprising shared resources
US9189379B2 (en) * 2013-02-06 2015-11-17 Avago Technologies General Ip (Singapore) Pte. Ltd. Buffer for managing data samples in a read channel
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

Also Published As

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

Similar Documents

Publication Publication Date Title
US11606261B2 (en) Data service overload detection and mitigation
WO2014193438A1 (fr) Ordonnancement de fils d'execution sensible a la priorite efficace
US20070277232A1 (en) Ike daemon self-adjusting negotiation throttle
US11150999B2 (en) Method, device, and computer program product for scheduling backup jobs
US11330047B2 (en) Work-load management in a client-server infrastructure
WO2022183802A1 (fr) Procédé, appareil et dispositif d'équilibrage de charge, support de stockage et produit programme informatique
EP2203817A2 (fr) Procede de gestion des preemptions dans un systeme d'exploitation en temps reel
FR3047821A1 (fr) Procede et dispositif de gestion d'un appareil de commande
FR2990782A1 (fr) Procede de gestion d'une execution de taches dans un systeme informatique
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
EP3850486A1 (fr) Procédé et circuit de multiplexage temporel d'accès concurrents à une ressource informatique
JP4791315B2 (ja) 業務管理装置及び業務管理方法及びプログラム
Jolai et al. A preemptive discrete-time priority buffer system with partial buffer sharing
WO2012038000A1 (fr) Procede de gestion de taches dans un microprocesseur ou un ensemble de microprocesseurs
US11126472B2 (en) System and method for managing shared computer resources
FR2980611A1 (fr) Circuit pour planifier le deroulement d'un traitement de donnees
EP1841151A1 (fr) Système de commutation de message
US12019623B2 (en) Data transfer resiliency during bulk to streaming transition
WO2021210094A1 (fr) Dispositif de gestion de microservices, procédé de gestion de microservices et programme
US8805899B2 (en) Data channel utilization management in multi-user system
EP4113297A1 (fr) Procédé de gestion des travaux dans un système informatique et système associé
US10300386B1 (en) Content item instance scaling based on wait time
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
WO2005010633A2 (fr) Procédé de gestion de l'exécution d'au moins un programme sur plusieurs calculateurs
EP3807757A1 (fr) Procédé d'accéleration de l'exécution d'un programme à chemin unique par exécution en parallèle de séquences conditionnellement concurrentes

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20210413

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: INSTITUT MINES-TELECOM

Owner name: COMMISSARIAT A L'ENERGIE ATOMIQUE ET AUX ENERGIES ALTERNATIVES

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20230222