EP2203817A2 - Procede de gestion des preemptions dans un systeme d'exploitation en temps reel - Google Patents

Procede de gestion des preemptions dans un systeme d'exploitation en temps reel

Info

Publication number
EP2203817A2
EP2203817A2 EP08869900A EP08869900A EP2203817A2 EP 2203817 A2 EP2203817 A2 EP 2203817A2 EP 08869900 A EP08869900 A EP 08869900A EP 08869900 A EP08869900 A EP 08869900A EP 2203817 A2 EP2203817 A2 EP 2203817A2
Authority
EP
European Patent Office
Prior art keywords
task
tasks
execution
time
priority
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.)
Withdrawn
Application number
EP08869900A
Other languages
German (de)
English (en)
Inventor
Fabrice Muller
Farooq Muhammad
Michel Auguin
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.)
Centre National de la Recherche Scientifique CNRS
Original Assignee
Centre National de la Recherche Scientifique CNRS
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 Centre National de la Recherche Scientifique CNRS filed Critical Centre National de la Recherche Scientifique CNRS
Publication of EP2203817A2 publication Critical patent/EP2203817A2/fr
Withdrawn 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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G06F9/4887—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues involving deadlines, e.g. rate based, periodic

Definitions

  • the subject of the present invention is a method for managing preemptions between several tasks in a real-time operating system (RTOS).
  • RTOS real-time operating system
  • pre-emption of tasks and more specifically the number of such pre-emptions has sometimes significant consequences on performance. Indeed, the processor can not be used to its maximum, because each preemption causes changes in the state of the cache memories (instructions and data), and these changes in turn lead to an increase in the execution time of the tasks (this which means that real-time constraints are no longer guaranteed) and the power consumption increases due to data movements between the different levels of the memory hierarchy at each preemption and each preemption return.
  • laxity tie The algorithm dedicated to the latency link problem relating to the LLT scheduling effect indeed for each task of the set of tasks and assigns individually to each task of the set of tasks a fixed priority for a time of dynamically calculated release, which greatly increases the complexity of task control (“TCB”), and increases execution times which leads to lower processor availability for its essential task which is the execution of tasks, except to choose a processor with greater processing power.
  • the first proposed solution is an acceleration of the clock rate to allow a lower priority task to complete before the arrival of a higher priority task, which requires that before the priority task higher happens, the CPU utilization rate is significantly less than 100% to allow then restore the clock rate, and this requires, for good efficiency, to oversize the processor.
  • the second proposed solution is to provide a largely oversized processor with respect to its total workload and to use a low clock rate so that it remains possible to finish tasks with low priority while there is a task of highest priority.
  • the basic idea of the invention is to determine for each task a non-preemption interval during which the task can remain in execution while a more priority task appears.
  • the invention thus relates to a method for managing preemptions between at least two tasks having different priorities in a real-time operating system, characterized in that, during a request to execute a task having a higher priority. the current task, the execution of the current task is interrupted only after a calculated time interval to allow at least the current task and the higher priority task to be executed before the end of the execution time assigned to them.
  • the time interval can be calculated once and for all for each task taking into account the execution of all other tasks that may have a higher priority, or dynamically taking into account all the other tasks having a priority. higher and for which an execution request is formed. In this case, the time interval of the current task can be refreshed each time an execution request is formed for a task having a higher priority than the current task.
  • the invention also relates to a method as defined above characterized in that the management of the preemption of several tasks whose indices i are chosen so that the tasks are classified in increasing order of execution priority, the index 1 being assigned to the task having the highest execution priority, and so on until the index p which is assigned to the task whose execution priority is the lowest, the time interval NPj non-preemption of the task of rank ia for value: with
  • P 1 designating the execution time assigned to the task Tj. This time is equal to the period of the task in the case of EDF scheduling with static calculation of NPj values, and also RM ("Rate Monotonic") by definition.
  • Pj can be equal in this equation and in all the following equations to a deadline Dj of value less than or equal to the period of task.
  • FIG. 1 is an example of implementation of an algorithm according to the invention
  • FIG. 2 illustrates the accumulation of the latency or laxity of the higher priority tasks than the current task T
  • FIGS. 3a and 3b are an example of implementation in a system implementing three tasks of which T 1 is the highest priority, respectively with an algorithm according to the invention and with a conventional "EDF" algorithm
  • FIGS. 4 and 5 illustrate the case of chain preemptions in the case of an "EDF” algorithm classic ( Figure 4) and how a algorithm according to the invention allows to avoid them ( Figure 5) or to reduce the number.
  • a real-time system is considered in which real-time tasks are ordered according to a closest maturity scheme (EDF).
  • the tasks T are of number n and are denoted (Ti, T 2 , ... T n ). These tasks are supposed to be mutually independent.
  • Each task Tj has its own execution time ("deadline”) Pj which is imposed on it and a runtime Ci calculated in the worst case execution time ("worst case execution time" or WCET).
  • Each task Tj has a latency or laxity Li which is defined by:
  • the task that runs is the one that expires at the nearest one.
  • the algorithm is based on dynamic priorities.
  • the algorithm described below is distinguished from a conventional EDF type 11 algorithm by the moment when the preemptions are performed, because the algorithm makes it possible to know whether immediate preemption is necessary or whether it is possible to delay it and for how long.
  • the tasks are sorted in ascending order with respect to their period P so that whatever is i, we have Pj ⁇ Pj + i, Pi being the task whose expiry time Pi is the shortest.
  • NPi defines the duration during which the current task Tj can proceed without inconvenience even in the presence at time t of one or more other tasks of higher priority than that of the current task. For this purpose, three conditions can be enumerated.
  • Condition 1 the latency Lj of the task Tj can be shifted over the entire time interval defined between its wake-up date and its due date
  • the task Tj never exceeds the deadline as, during the maturity period Pi, the processor assigns a processor time Cj.
  • Condition 2 the task Tj can be pre-empted only by a task having a higher priority and therefore a shorter expiration period Pj (in the case of an EDF or RM algorithm).
  • Forcing a lower priority task to continue execution when a higher priority task is to be executed is a priority override that can cause the higher priority task to be exceeded.
  • the RM Random Early Preemptive algorithm
  • the tasks are periodic and of period Pj, but the deadline is not necessarily at the end of the period. Tasks are sorted by increasing periods and priority is allocated inversely to the period. In the case of the "EDF" algorithm, the priority criterion is the absolute deadline d.
  • a task Tj can therefore be pre-empted only by a task which has a lower due period P.
  • a task that appears less frequently will always be preempted by a more frequent task.
  • a more frequent task may or may not pre-empt an infrequent task.
  • condition 2 is necessary, and for an "RM” algorithm it is necessary and sufficient.
  • Condition 3 In the case of an algorithm of type "EDF" giving priority to the deadline whose term is closest, a task T 1 may continue execution by causing a priority inversion during a statically or dynamically calculated NP time without any other task exceeding the assigned time.
  • each task Tj has two main parameters which are its execution time Cj in the worst case and its period Pj which sets the maturity period, that is to say the time that remains available to complete. the task within the prescribed time.
  • the expiry date of the task is only equal to its period in the case of EDF 1 scheduling if the NP values of tasks and RM scheduling are statically calculated.
  • Pj can be equal to a deadline Di of value less than or equal to the period of the task.
  • the third parameter developed from the first two is the latency or laxity L 1 .
  • a higher priority task has sufficient latency, then its execution can be delayed by delaying preemption for a time that is compatible with the fact that all tasks are performed without exceeding their deadlines.
  • a logic algorithm is shown in FIG. 1.
  • the procedure is conventional (for example "EDF" algorithm). If a task Tj is already active, the procedure "EDF" is continued if Pj ⁇ Pj, and otherwise the task T j is inserted in a temporary queue for a duration equal to the minimum between the execution time remaining for Tj and NPj value of the duration of non-preemption
  • the task Tj preempts the task Tj, except of course if the task Tj has already completed its execution, in which case the task Tj starts its execution as soon as the task Tj is completed.
  • the NPj value of the non-preemption period can be determined either statically or dynamically.
  • the latency L 1 of the task Tj defines the duration NPj + i during which a task T i + i of lower priority can cause a priority inversion without Tj missing its deadline.
  • the task Ti with the shortest expiry time can not be preempted by any other task, and the task T 2 can only be preempted by the task Ti, and so on until the task T p which can be preempted by the higher priority tasks T p- i, T p-2 , .. Ti.
  • NP 3 for the task T 3 , we define a virtual task used only in the calculations and whose objective is to model the deadlines and the execution times induced by the tasks higher priority than T 3 .
  • This virtual task has a latency L 2 7 and an execution time abs C 2 , defined in the worst case as equal to the sum of abs
  • NP 3 Min (NP 2 , L 2 abs )
  • NP 4 Mm (NP 3 , L 3 abs )
  • the task T 3 has the largest expiry time among the tasks Ti, T 2 , T 3 that can preempt the task T 4 .
  • the task Tj can be preempted by the tasks (Ti, T 2 ,..., TM), which have a duration of maturity shorter than its duration Pj.
  • a virtual task T ⁇ 5 whose laxity corresponds to the duration of no expiry NPj. It is thus possible to compute, from Ti up to T j , all NPj non-preemption times (i varying from 1 to j). To calculate the worst execution time of a virtual task, the task Tj is chosen for the case where all the tasks having a higher priority level are called at the same time during the execution of the task Tj .
  • the virtual task T ⁇ has a period equal to the due time P, -i of the task TVi and its execution time in the worst case noted C 1 ⁇ 3 is the weighted sum of the execution times in the most unfavorable case of all the tasks having a duration of expiration less than the duration C, of the task T ,.
  • the latency L 1 ⁇ 5 of the task T ⁇ indeed accumulates the latencies or laxities of all the higher priority tasks than the task T 1 .
  • Figure 2 shows that virtual task T ⁇ 8 collates the
  • This accumulated latency gives a greater ability to 0 a given task to continue without its execution being preempted by a more priority task.
  • the non-preemption time NP, of the task T is then defined:
  • NP 1 Mm (NP 14 ,)) 5
  • NP takes into account by its method of calculating the minimum value of the latency of the tasks of lower rank. Thus none of the tasks will be able to miss its deadline.
  • the algorithm described above delays the preemption of the current task for a duration equal to the value of NP 1 for the current task T 1 . It should be noted that the possible values of NP can be precalculated and placed in a table thus giving for each task the NP value.
  • This delay is counted by a counter and when this counter reaches the value 0, there is preemption of the current task unless of course the current task has ended before which case the new task is executed as soon as the task is completed. completion of the current task and without preemption.
  • NP takes into account the case where all the tasks higher priority than the current task appear simultaneously, which ensures that in the worst case, all the tasks will be carried out according to their deadline, whatever the tasks likely to appear later.
  • T 1 the highest priority
  • T 2 can only be preempted by T 1
  • T 3 can only be preempted by Ti or T 2 .
  • the static algorithm described in general does not allow to remove all preemptions, but only to reduce the number. It is possible to improve performance and further reduce the number of preemptions by dynamically adjusting the preemption time.
  • the dynamic calculation aims to take into account only the tasks actually called to be executed.
  • NPi is calculated and decremented while the task T 1 continues until the duration NP - has elapsed or task Tj ends. It is therefore necessary to recalculate NPj each time a new task called has a deadline before that of the current task, and restart the decrementation of NP, with the new value and with this new starting point, the calculation of NPj is done using the preceding equations, but taking into account only the tasks which are ready for execution and have an absolute deadline prior to that of task Tj
  • the tasks selected for the calculation of the NPj parameter are ordered according to the value of their absolute maturity date dj and not according to the value of their maturity period P j .
  • NPj will be chosen equal to the latency L k of the task Tk . If a new task Ti is ready (d
  • a recalculated value can only be less than or equal to the previous value. It should be noted that a statically calculated value NPj can not be greater than a dynamically calculated value NPj, since the static computation takes into account all the higher priority tasks whether or not they are ready, whereas the dynamic computation does not take place. only takes into account tasks that are actually ready for execution.
  • the complexity of the dynamic computation is proportional to the total number n of tasks, and the algorithm requires n iterations in the worst case, but the number of iterations will generally be much smaller than n.
  • This calculation of NP values can be incorporated into the algorithm used to place the newly called tasks for execution in the queue and whose complexity is also proportional to n.
  • a particularly troublesome phenomenon in the case of RM or EDF type algorithms is the existence of chain preemptions, that is to say that a task in progress is preempted by a higher priority task, itself pre-empted by a task even more priority and so on.
  • FIGS. 4 and 5 This is illustrated in FIGS. 4 and 5 for chain preemption for 6 tasks Ti to I classified as before in order of decreasing priority (Ti being the highest priority task).
  • TQ is preempted by T 5 , T 5 by T 4 , T 4 by T 3 , T 3 by T 2 and finally T 2 by T 1 , ie five cascaded preemptions which are avoided by the algorithm according to FIG. invention ( Figure 5).

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Advance Control (AREA)
  • Measurement Of The Respiration, Hearing Ability, Form, And Blood Characteristics Of Living Organisms (AREA)
  • Complex Calculations (AREA)

Abstract

L'invention concerne un procédé de gestion des préemptions entre au moins deux tâches ayant des priorités différentes dans un système d'exploitation en temps réel caractérisé en ce que lors d'une requête d'exécution d'une tâche ayant une priorité plus élevé que la tâche en cours, l'exécution de la tâche en cours n'est interrompue qu'au bout d'un intervalle de temps calculé pour permettre au moins à la tâche en cours et à la tâche de priorité plus élevée d'être exécutées avant la fin de délais d'exécution qui leur sont assignés.

Description

PROCEDE DE GESTION DES PREEMPTIONS DANS UN SYSTEME D'EXPLOITATION EN TEMPS REEL.
La présente invention à pour objet un procédé de gestion des préemptions entre plusieurs tâches dans un système d'exploitation en temps réel (RTOS).
Il est connu en effet de préempter une tâche par une tâche plus prioritaire afin de permettre à celle-ci d'être achevée avant une échéance qui est fixée, que ce soit dans le cas d'ordonnanceurs à priorité fixes ("fixed priority scheduling" ou FPS) ou dynamiques (priorité à l'échéance la plus proche soit "earliest deadline first" ou EDF), ou bien encore latence minimale (ou "least laxity").
Cependant, la préemption des tâches et plus particulièrement le nombre de ces préemptions a des conséquences parfois importantes sur les performances. En effet, le processeur ne peut être utilisé à son maximum, car chaque préemption entraîne des modifications de l'état des mémoires cache (instructions et données), et ces modifications entraînent à leur tour une augmentation des temps d'exécution des tâches (ce qui fait que les contraintes de temps réel ne sont plus garanties) et la consommation d'énergie augmente en raison des mouvements de données entre les différents niveaux de la hiérarchie des mémoires à chaque préemption et à chaque retour de préemption.
Il est donc souhaitable de diminuer le nombre des préemptions.
L'article de Radu DOBRIN et Gerhard FOHLER paru dans Real Systems 2004 - Proceedings ECRT 2004 - 16th Euromicro Conférence on Real Time Systems, 30 juin - 2 juillet 2004, pages 144 à 152 intitulé "Reducing the Number of Préemptions in Standard Fixed Priority Scheduling", propose un algorithme de préemption à priorités fixes (FPS) en analysant un jeu de tâches ("artifact tasks") ayant des périodes égales au plus petit commun multiple des périodes des deux tâches et ordonnancé par un algorithme de préemption à priorité fixe, puis en calculant le nombre de préemptions susceptible de se produire et impose l'exécution de la tâche préemptante ou des tâches préemptées de sorte qu'il évite une préemption des tâches au cours de leur exécution tout en permettant leur exécution dans le délai prescrit. La technique décrite permet de réduire le nombre de préemptions seulement dans le cas où le taux d'occupation des processeurs est notablement inférieur à 100%.
L'article de Sung-Heun Oh et Seung-Min YANG intitulé "A Modified Least-Laxity-First Scheduling for Real-Time Tasks" paru dans Proceedings of the 3th International Conférence on Real Time Computing Systems and Applications 1998 (27-29 octobre 1998, pages 31 à 36) propose un algorithme d'ordonnancement LLF (priorité à la latence minimale) pour résoudre un problème d'incompatibilité entre deux tâches en permettant à une des deux tâches de s'exécuter complètement sans préemption.
L'algorithme dédié au problème du lien de la latence ("laxity tie") relatif à l'ordonnancement LLT opère en effet pour chaque tâche du jeu de tâches et assigne individuellement à chaque tâche du jeu de tâches une priorité fixe pour un temps de libération calculé dynamiquement, ce qui augmente considérablement la complexité du contrôle des tâches ("TCB"), et augmente les temps d'exécution ce qui conduit à une plus faible disponibilité du processeur pour sa tâche essentielle qui est l'exécution des tâches, sauf à choisir un processeur ayant une plus grande puissance de traitement.
L'article de Cécilia EKELIN "Clairvoyant Non-Préemption EDF Scheduling" (18th Euromicro Conférence on Real Time Systems ECRTS'06 pages 23-32) propose de retarder l'exécution de certaines tâches en tenant compte de l'arrivée future de nouvelles tâches, mais cette technique s'applique seulement au cas de tâches sans règle de préemption.
L'article de Yun WANG et Manas SAKSENA "Scheduling Fixed-Priority Tasks with Préemption Threshold" (Sixth Conférence on Real Time Computing Systems and Applications RCTSA'99 pages 328-335) propose un algorithme de réduction des préemptions qui impose de calculer pour chaque tâche des seuils de préemption, d'où une complexité proportionnelle au carré du nombre n des tâches. L'article de Woonseok KIM, Jihong KIM et Sang Lyul MIN publié dans les "Proceedings of the 2004 International Symposium on Low Power Electronics and Design" ISPLED'04, 9-11 août 2004, pages 393 à 398, et intitulé "Preemption-Aware Dynamic Voltage Scaling in Hard Real-Time Systems" analyse l'effet négatif des préemptions sur la consommation électrique du processeur et propose deux solutions. La première solution proposée est une accélération de la cadence de l'horloge pour permettre à une tâche de plus faible priorité de se terminer avant l'arrivée d'une tâche de priorité plus élevée, ce qui impose qu'avant que la tâche de priorité plus élevée n'arrive, le taux d'utilisation du processeur soit notablement inférieur à 100 % pour permettre de rétablir ensuite la cadence de l'horloge, et ceci impose, pour une bonne efficacité, de surdimensionner le processeur.
La deuxième solution proposée consiste à prévoir un processeur largement surdimensionné par rapport à sa charge de travail totale et à utiliser une faible fréquence d'horloge de sorte qu'il reste possible de terminer des tâches ayant une faible priorité alors que se présente une tâche de plus haute priorité.
Il résulte de ce qui précède qu'il n'est pas actuellement connu de technologie qui soit apte à diminuer le nombre de préemptions sans que n'existe un inconvénient associé tenant à la disponibilité et/ou au dimensionnement du processeur.
L'idée de base de l'invention est de déterminer pour chaque tâche un intervalle de non préemption pendant lequel la tâche peut rester en exécution alors qu'une tâche plus prioritaire apparaît. L'invention concerne ainsi un procédé de gestion des préemptions entre au moins deux tâches ayant des priorités différentes dans un système d'exploitation en temps réel caractérisé en ce que, lors d'une requête d'exécution d'une tâche ayant une priorité plus élevée que la tâche en cours, l'exécution de la tâche en cours n'est interrompu qu'au bout d'un intervalle de temps calculé pour permettre au moins à la tâche en cours et à la tâche de priorité plus élevé d'être exécutées avant la fin de délais d'exécution qui leur sont assignés.
L'intervalle de temps peut être calculé une fois pour toutes pour chaque tâche en tenant compte de l'exécution de toutes les autres tâches pouvant avoir une priorité plus élevée, ou bien de manière dynamique en tenant compte de toutes les autres tâches ayant une priorité plus élevée et pour lesquelles une requête d'exécution est formée. Dans ce cas, l'intervalle de temps de la tâche en cours peut être réactualisé chaque fois qu'est formée une requête d'exécution pour une tâche ayant une priorité plus élevée que la tâche en cours. L'invention concerne également un procédé tel que défini ci- dessus caractérisé en ce que la gestion de la préemption de plusieurs tâches dont les indices i sont choisis de sorte que les tâches sont classées en ordre croissant de priorité d'exécution, l'indice 1 étant affecté à la tâche ayant la priorité d'exécution la plus élevée, et ainsi de suite jusqu'à l'indice p qui est affecté à la tâche dont la priorité d'exécution est la plus faible, l'intervalle de temps NPj de non préemption de la tâche de rang i a pour valeur : avec
P1 désignant le délai d'exécution assigné à la tâche Tj. Ce temps est égal à la période de la tâche dans le cas d'un ordonnancement EDF avec calcul statique des valeurs de NPj, et également RM ("Rate Monotonie") par définition. Dans le cas des ordonnancements EDF avec calcul dynamique des valeurs de NPi, ou bien DM ("Deadline monotonie"), Pj peut être égal dans cette équation et dans toutes les équations suivantes à une échéance Dj de valeur inférieure ou égale à la période de la tâche.
Cj désignant la durée d'exécution de la tâche Ti D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description ci-après en liaison avec les dessins dans lesquels : - la figure 1 est un exemple de mise en œuvre d'un algorithme selon l'invention, la figure 2 illustre l'accumulation de la latence ou laxité des tâches plus prioritaires que Ia tâche T en cours, les figures 3a et 3b sont un exemple de mise en œuvre dans un système mettant en œuvre trois tâches dont T1 est la plus prioritaire, respectivement avec un algorithme selon l'invention et avec un algorithme "EDF" classique, et les figures 4 et 5 illustrent le cas de préemptions en chaîne dans le cas d'un algorithme "EDF" classique (Figure 4) et comment un algorithme selon l'invention permet de les éviter (Figure 5) ou d'en diminuer le nombre.
On considère à titre d'exemple un système en temps réel dans lequel des tâches en temps réel sont ordonnées selon un schéma d'échéance la plus proche (EDF). Les tâches T sont au nombre de n et sont notée (T-i, T2, ...Tn). Ces tâches sont supposées être mutuellement indépendantes. Chaque tâche Tj a son propre délai d'exécution ("deadline") Pj qui lui est imposé ainsi qu'une durée d'exécution Ci calculée dans le cas d'exécution le plus défavorable ("worst case exécution time" ou WCET). Chaque tâche Tj présente une latence ou laxité Li qui est définie par :
Li = Pi - Q
Chaque tâche réapparaît de manière cyclique et la keme implémentation de la tâche Tj est notée Tj.k.
Chaque implémentation k de la tâche Tj,k a une date de réveil π,k = kPj et un délai d'exécution (date d'échéance) dj,k ≈ (k+1)P|.
Avec un algorithme EDF, la tâche qui s'exécute est celle qui à l'échéance d la plus proche. L'algorithme est donc basé sur des priorités dynamiques. L'algorithme décrit ci-après se distingue d'un algorithme classique de type 11EDF" par l'instant où les préemptions sont réalisées. En effet, l'algorithme permet de savoir si une préemption immédiate est nécessaire ou bien s'il est possible de la retarder et pendant combien de temps.
Par convention, les tâches sont triées par ordre de manière ascendante par rapport à leur période P de sorte que quelque soit i, on a Pj <Pj+i, Pi étant la tâche dont le délai d'échéance Pi est le plus court.
On définit par NPi la durée pendant laquelle la tâche en cours Tj peut se poursuivre sans inconvénient même en présence à l'instant t d'une ou plusieurs autres tâches de priorité plus élevée que celle de la tâche en cours. A cet effet, on peut énumérer trois conditions.
Condition 1 : la latence Lj de la tâche Tj peut être décalée sur tout l'intervalle de temps défini entre sa date de réveil et sa date d'échéance
Pi.
En effet, la tâche Tj ne dépasse jamais l'échéance tant que, pendant la durée d'échéance Pi, le processeur lui attribue un temps de processeur Cj. Condition 2 : la tâche Tj peut être préemptée seulement par une tâche ayant une priorité supérieure et donc une durée d'échéance Pj inférieure (dans le cas d'un algorithme EDF ou RM).
Forcer une tâche de plus faible priorité à continuer son exécution alors qu'une tâche de plus haute priorité doit être exécutée est une inversion de priorité qui peut provoquer un dépassement de l'échéance fixée pour la tâche de plus haute priorité.
Seules des tâches de plus haute priorité peuvent donc préempter des tâches de plus faible priorité. L'algorithme RM ("Rate Monotonie"), préemptif, est basé sur des priorités fixes. Les tâches sont périodiques et de période Pj, mais l'échéance n'est pas nécessairement en fin de période. Les tâches sont classées par périodes croissantes et la priorité est allouée en fonction inverse de la période. Dans le cas de l'algorithme "EDF", le critère de priorité est l'échéance absolue d.
Si la tâche Tj est préemptée à l'instant n par la tâche Tj prête pour l'instant k, ce qui implique que :
Comme la tâche Tj est préemptée à l'instant n par la tâche Tj, ce qui implique que l'échéance de Tj est plus proche que celle de Ti, d'où :
II en résulte que Pj < Pj.
Une tâche Tj ne peut donc être préemptée que par une tâche qui à une durée d'échéance P inférieure.
Dans un algorithme "RM", une tâche qui apparaît moins fréquemment sera toujours préemptée par une tâche plus fréquente. Dans le cas d'un algorithme EDF, une tâche plus fréquente peut ou non préempter une tâche peu fréquente. Dans le cas d'un algorithme "EDF", la condition 2 est nécessaire, et pour un algorithme "RM" elle est nécessaire et suffisante. Il en résulte comme corollaire que seules les tâches qui ont un délai d'échéance inférieur à celui de la tâche Tj peuvent dépasser leur échéance en cas d'inversion de priorité au profit de la tâche Tj. Condition 3 : Dans le cas d'un algorithme de type "EDF" donnant la priorité à l'échéance dont le terme est le plus proche, une tâche T1 peut poursuivre son exécution en causant une inversion de priorité pendant un temps NP calculé de manière statique ou dynamique sans qu'aucune autre tâche ne dépasse l'échéance qui lui est assignée.
Autrement dit, chaque tâche Tj présente deux paramètres principaux qui sont sa durée d'exécution Cj dans le cas le plus défavorable et sa période Pj qui fixe la durée d'échéance, c'est-à-dire le temps qui reste disponible pour terminer la tâche dans le délai prescrit.
La date d'échéance de la tâche n'est assimilée à sa période que dans le cas de l'ordonnancement EDF1 si on calcule statiquement les valeurs NP des tâches et de l'ordonnancement RM. Pour les ordonnancements EDF avec calcul dynamique des valeurs de NPi ou bien DM ("Deadline Monotonie"), Pj peut être égal à une échéance Di de valeur inférieure ou égale à la période de la tâche.
Le troisième paramètre élaboré à partir des deux premiers est la latence ou laxité L1.
Si une tâche de plus haut niveau de priorité présente une latence suffisante, alors on peut décaler son exécution en retardant la préemption pendant une durée qui est compatible avec le fait que toutes les tâches sont effectuées sans dépassement de leur échéances. Un algorithme logique est représenté à la figure 1. A l'arrivée d'une tâche Tj, si aucune tâche n'est active, on procède de manière classique (par exemple algorithme "EDF"). Si une tâche Tj est déjà active, on poursuit la procédure "EDF" si Pj < Pj, et sinon la tâche Tj est insérée dans une file d'attente temporaire pour une durée égale au minimum entre le temps d'exécution restant pour Tj et la valeur NPj de la durée de non préemption
Dès que cette durée est atteinte, la tâche Tj préempte la tâche Tj, sauf bien sûr si la tâche Tj a déjà terminé son exécution, auquel cas la tâche Tj commence son exécution dès que la tâche Tj est achevée. La valeur NPj de la durée de non préemption peut être déterminée soit de manière statique, soit de manière dynamique.
Une détermination statique est décrite ci-après :
La latence L1 de la tâche Tj définit la durée NPj+i pendant laquelle une tâche Ti+i de priorité plus faible peut causer une inversion de priorité sans que Tj ne manque son échéance.
On a donc : NP2 = L1
La tâche Ti qui a la durée d'échéance la plus petite ne peut être préemptée par aucune autre tâche, et que la tâche T2 ne peut être préemptée que par la tâche Ti, et ainsi de suite jusqu'à la tâche Tp qui peut être préemptée par les tâches plus prioritaires Tp-i , Tp-2, .. Ti .
Pour calculer NP3 pour la tâche T3, on définit une tâche virtuelle utilisée uniquement dans les calculs et dont l'objectif est de modéliser les échéances et les temps d'exécution induits par les tâches plus prioritaires que T3. Cette tâche virtuelle a une latence L 2 7 et un temps d'exécution abs C 2, défini dans le cas le plus défavorable comme étant éqal à la somme de abs
C2 et d'un temps d'exécution proportionnel à celui de la tâche Ti pour la période égale à la période de cette tâche virtuelle, soit : p p 2 - r i 2 p
^ abs ~ ^2 + p *-l On aura :
NP3= Min(NP2, L2 abs )
C'est-à-dire que l'on choisit le minimum entre les deux valeurs entre parenthèses. On aura de la même façon :
NP4 = Mm(NP3, L3 abs)
En effet, la tâche T3 a la durée d'échéance la plus grande parmi les tâches Ti, T2, T3 qui peuvent préempter la tâche T4.
De manière générale, la tâche Tj peut être préemptée par les tâches (Ti, T2, ..., TM), qui ont une durée d'échéance inférieure à sa durée Pj.
Si on tient compte de toutes les tâches qui peuvent préempter la tâche Tj, on peut définir une tâche virtuelle T^5 dont la laxité correspond à la durée de non péremption NPj. On peut ainsi calculer en remontant depuis Ti jusqu'à Tj, toutes les durées de non préemption NPj (i variant de 1 à j). Pour calculer le temps d'exécution le plus défavorable d'une tâche virtuelle, on choisit pour la tâche Tj le cas où toutes les tâches ayant un niveau de priorité plus élevé sont appelées en même temps au cours de l'exécution de la tâche Tj. La tâche virtuelle T^ présente une période égale à la durée d'échéance P,-i de la tâche TVi et sa durée d'exécution dans le cas le plus défavorable notée C1^3 est la somme pondérée des durées d'exécution dans le cas le plus défavorable de toutes les tâches ayant une durée d'échéance 5 inférieure à la durée C, de la tâche T,.
On aura donc : i υ t-Obs ~ rabs Uabs
La latence L1^5 de la tâche T^ accumule en effet les latences ou laxités de toutes les tâches plus prioritaires que la tâche T1.
La figure 2 montre que la tâche virtuelle T^8 collationne la
15 latence accumulée L1'^ de toutes les tâches plus prioritaires que la tâche T, tandis que la durée P^5 de la tâche virtuelle T3 1^5 a une valeur plus élevée que pour chacune des tâches de plus grande priorité que T, et C^5 est le cumul pondéré des temps d'exécution les plus défavorables de ces tâches.
Cette latence accumulée donne une plus grande capacité à 0 une tâche donnée de se poursuivre sans que son exécution soit préemptée par une tâche plus prioritaire.
On définit alors le temps de non préemption NP, de la tâche T, :
NP1 =Mm(NP14 ,^) 5
La formule donnant NP, tient compte de par son mode de calcul de la valeur minimale de la latence des tâches de rang inférieur. Ainsi aucune des tâches ne pourra manquer son échéance. 0 L'algorithme décrit ci-dessus retarde la préemption de la tâche en cours pendant une durée égale à la valeur de NP1 pour la tâche en cours T1. On notera que les valeurs possibles de NP peuvent être précalculées et placées dans un tableau donnant ainsi pour chaque tâche la valeur NP.
Ce délai est décompté par un compteur et quand ce compteur atteint la valeur 0, il y a préemption de la tâche en cours sauf si bien sûr la tâche en cours s'est terminée avant auquel cas il y a exécution de la nouvelle tâche dès la fin de l'exécution de la tâche en cours et sans préemption.
Si pendant l'intervalle de temps NPj de la tâche en cours Tj, d'autres tâches apparaissent, elles seront retardées jusqu'à ce que l'intervalle NPi soit terminé. Ce n'est qu'ensuite que les échéances de ces tâches seront prises en compte.
Le calcul de NP prend en compte le cas où toutes les tâches plus prioritaires que la tâche en cours apparaissent simultanément, ce qui assure que dans le pire des cas, toutes les tâches seront menées à bien en respectant leur échéance, quelque soient les tâches susceptibles d'apparaître ultérieurement.
Exemple :
On prend un modèle simple présentant trois tâches T1, T2, T3. Elles ont été classées par ordre de priorité, en fonction de leur période, T1 étant la plus prioritaire, comme indiqué ci-dessous :
On a :
T2 C2 = 6 P2 = 21
T3 C3 = 9 P3 = 33 Ti ne peut être préemptée
T2 ne peut être préemptée que par T1
T3 ne peut être préemptée que par Ti ou T2.
On a NP3 = P2 - J ^C; soit NP3 = 21 - — x 4- 6 = 6,6
NP2 = P1 - C1 = 6
Les figures 3a et 3b sont des chronogrammes montant d'une part (figure 3a) le fonctionnement de l'algorithme selon l'invention et d'autre part (figure 3b) selon un algorithme EDF classique, pour une tâche T2 arrivant aux instants t = 0 et 21 (deux occurrences), une tâche Ti arrivant aux instants 3,13, 23 et 33 (4 occurrences), et une tâche T3 arrivant aux instants 0 et 33.
A la figure 3a, il n'y a plus de préemption, alors qu'à la figure 3b, on a deux préemptions. En effet, la tâche T2 n'est pas du tout préemptée par la tâche
Ti qui arrive à l'instant 3 car NP2 = 6 ce qui est supérieur au temps nécessaire à la tâche P2 pour s'achever. La tâche T1 commence son exécution à l'instant t = 6 et se termine avant son échéance à t = 10. A l'instant t = 10, la tâche T3 commence son exécution jusqu'à ce que la deuxième occurrence de la tâche T1 apparaissent à l'instant t = 13, mais la préemption de T3 est retardée car NP3 = 6,6, ce qui permet à la tâche T3 de se terminer sans préemption. La deuxième occurrence de la tâche Ti est exécutée entre les instants t = 19 et t = 23, et la troisième occurrence de la tâche T1 est exécutée entre les instants t = 23 et t = 27. La tâche Tj qui est la plus prioritaire ne pouvant être préemptée, la deuxième occurrence de T2 à l'instant t = 20 est retardée jusqu'à t = 27 quand la tâche T1 est terminée, et la deuxième occurrence de la tâche T2 est exécutée entre t = 27 et t = 33.
L'algorithme statique décrit ne permet en général pas de supprimer toutes les préemptions, mais seulement d'en diminuer le nombre. II est possible d'améliorer les performances et de diminuer encore le nombre de préemptions en ajustant de manière dynamique la durée de préemption.
Le calcul précédent revient en effet à prendre en compte le fait que toutes les tâches à faible périodicité soient appelées simultanément ce qui est en pratique.
Le calcul dynamique vise à ne prendre en compte que les tâches effectivement appelées pour être exécutées.
Si une tâche Tk est appelée et présente une échéance antérieure à celle de la tâche Ti en cours, alors, NPi est calculé et est décrémenté pendant que la tâche T1 se poursuit jusqu' ce que Ia durée NP,- soit écoulée ou que la tâche Tj se termine. Il s'agit donc de recalculer NPj chaque fois qu'une nouvelle tâche appelée a une échéance située avant celle de la tâche en cours, et recommencer la décrémentation de NP, avec la nouvelle valeur et avec ce nouveau point de départ, le calcul de NPj s'effectue en utilisant les équations précédentes, mais en ne tenant compte que des tâches qui sont prêtes à être exécutées et qui ont une échéance absolue antérieure à celle de la tâche Tj
Dans ce calcul dynamique, les tâches sélectionnées pour le calcul du paramètre NPj sont ordonnées en fonction de la valeur de leur échéance absolue dj et non en fonction de la valeur de leur durée d'échéance Pj.
Si la tâche TR est la première à être appelée alors que Tj est exécutée (dk < dj), NPj sera choisi égal à la latence Lk de la tâche Tk. Si une nouvelle tâche Ti est prête (d| < dj ), alors NPj sera recalculé en tenant compte des paramètres des tâches Tk et Ti selon les formules données ci-dessus.
Une valeur recalculée ne peut qu'être inférieure ou égale à la valeur précédente. On notera qu'une valeur NPj calculée de manière statique ne peut pas être supérieure à une valeur NPj calculée de manière dynamique, car le calcul statique tient compte de toutes les tâches plus prioritaires qu'elles soient ou non prêtes alors que le calcul dynamique ne tient compte que des tâches qui sont effectivement prêtes pour être exécutées.
La complexité du calcul dynamique est proportionnelle au nombre total n de tâches, et l'algorithme nécessite n itérations dans le pire des cas, mais le nombre d'itérations sera en général très inférieur à n. Ce calcul des valeurs de NP peut être incorporé dans l'algorithme qui sert à placer les tâches nouvellement appelées pour exécution dans la file d'attente et dont la complexité est également proportionnelle à n.
Un phénomène particulièrement gênant dans le cas des algorithmes de type RM ou EDF est l'existence de préemptions en chaîne, c'est-à-dire qu'une tâche en cours est préemptée par une tâche plus prioritaire, elle-même préemptée par une tâche encore plus prioritaire et ainsi de suite.
Du fait que l'algorithme selon l'invention, qu'il soit statique ou dynamique, tient toujours compte de toutes les tâches prêtes pour exécution (de toutes les tâches susceptibles d'être prêtes dans le cas d'un algorithme statique et réellement prêtes dans le cas d'un algorithme dynamique), ce phénomène peut être évité ou atténué.
Ceci est illustré aux figures 4 et 5 pour une préemption en chaînes pour 6 tâches Ti à Je classées comme précédemment par ordre de priorité décroissante (Ti étant la tâche la plus prioritaire). A la figure 4 TQ est préempté par T5, T5 par T4, T4 par T3, T3 par T2 et enfin T2 par Ti, soit cinq préemptions en cascade qui sont évitées par l'algorithme selon l'invention (figure 5).
On notera que l'introduction de l'algorithme selon l'invention ne modifie pas les conditions de faisabilité des algorithmes classiques qui est, par exemple dans le cas de l'algorithme EDF, que, U étant le taux maximal d'utilisation de processeur : n z"1 / i = l / '

Claims

REVENDICATIONS
1. Procédé de gestion des préemptions entre au moins deux tâches ayant des priorités différentes dans un système d'exploitation en temps réel caractérisé en ce que lors d'une requête d'exécution d'une tâche ayant une priorité plus élevée que celle de la tâche en cours, l'exécution de la tâche en cours n'est interrompue qu'au bout d'un intervalle de temps calculé pour permettre au moins à la tâche en cours et à la tâche de priorité plus élevée d'être exécutée avant la fin de délais d'exécution qui leur sont assignés et caractérisé en ce que pour la gestion de la préemption de plusieurs tâches dont les indices i sont choisis de sorte que les tâches sont classées en ordre croissant du délai d'exécution, l'indice 1 étant affecté à la tâche ayant le délai d'exécution le plus court, et ainsi de suite jusqu'à l'indice p qui est affecté à la tâche dont le délai d'exécution est le plus long, l'intervalle de temps NPi de non préemption de la tâche de rang i a pour valeur :
NP1 = Mm(NP1,, ^ ) avec
P1 désignant le délai d'exécution assigné à la tâche T1
C1 désignant la durée d'exécution dans le pire cas de la tâche T1
2. Procédé selon la revendication 1 caractérisé en ce que ledit intervalle de temps est calculé pour chaque tâche de manière fixe en tenant compte de l'exécution de toutes les autres tâches pouvant avoir une priorité plus élevée.
3. Procédé selon la revendication 2 caractérisé en ce que lesdits intervalles de temps sont précalculés.
4. Procédé selon la revendication 1 caractérisé en ce que ledit intervalle de temps est déterminé pour la tâche en cours de manière dynamique en tenant compte de toutes les autres tâches ayant une priorité plus élevée et pour lesquelles une requête d'exécution est formée.
5. Procédé selon la revendication 4 caractérisé en ce que ledit intervalle de temps de la tâche en cours est réactualisé chaque fois qu'est formée une requête d'exécution pour une tâche ayant une priorité plus élevée que la tâche en cours.
6. Procédé selon une des revendications précédentes, caractérisé en ce que les tâches présentent une priorité fixe.
7. Procédé selon une des revendications 1 à 5, caractérisé en ce que les tâches ont une priorité dynamique.
8. Procédé selon la revendication 1 caractérisé en ce que ledit intervalle de temps NPj est calculé de manière fixe en tenant compte de toutes les autres tâches ayant un délai d'exécution plus court que le temps d'exécution Pj de la tâche en cours Tj et en ce que la tâche en cours Tj ne peut être préemptée que par une tâche ayant un délai d'exécution qui est inférieur à son délai d'exécution Pj.
9. Procédé selon la revendication 1 caractérisé en ce que ledit intervalle de temps NPj est calculé de manière dynamique en tenant compte de toutes les tâches appelées pour exécution et ayant une échéance absolue antérieure à celle de la tâche en cours T,- et en ce que la tâche en cours ne peut être préemptée que par une tâche ayant une échéance absolue antérieure à son échéance absolue d,.
EP08869900A 2007-10-24 2008-10-22 Procede de gestion des preemptions dans un systeme d'exploitation en temps reel Withdrawn EP2203817A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0707478A FR2923039A1 (fr) 2007-10-24 2007-10-24 Procede de gestion des preemptions dans un systeme d'exploitation en temps reel
PCT/FR2008/001481 WO2009087317A2 (fr) 2007-10-24 2008-10-22 Procede de gestion des preemptions dans un systeme d'exploitation en temps reel

Publications (1)

Publication Number Publication Date
EP2203817A2 true EP2203817A2 (fr) 2010-07-07

Family

ID=39522409

Family Applications (1)

Application Number Title Priority Date Filing Date
EP08869900A Withdrawn EP2203817A2 (fr) 2007-10-24 2008-10-22 Procede de gestion des preemptions dans un systeme d'exploitation en temps reel

Country Status (4)

Country Link
EP (1) EP2203817A2 (fr)
JP (1) JP2011501309A (fr)
FR (1) FR2923039A1 (fr)
WO (1) WO2009087317A2 (fr)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103870327A (zh) * 2012-12-18 2014-06-18 华为技术有限公司 一种实时多任务调度方法和装置
GB2545507B (en) * 2015-12-18 2019-07-17 Imagination Tech Ltd Controlling scheduling of a GPU
GB2545508B (en) 2015-12-18 2019-04-10 Imagination Tech Ltd Controlling operation of a GPU
US10366013B2 (en) * 2016-01-15 2019-07-30 Futurewei Technologies, Inc. Caching structure for nested preemption
CN109684060B (zh) * 2018-12-21 2023-05-23 中国航空工业集团公司西安航空计算技术研究所 一种多类型时间关键任务的混合调度方法
KR20200101682A (ko) * 2019-02-20 2020-08-28 삼성전자주식회사 전자 장치 및 그 제어 방법
CN110221907B (zh) * 2019-05-24 2023-06-27 昆明理工大学 一种基于edf算法和模糊集的实时任务调度方法
CN110784418B (zh) * 2019-10-24 2022-06-24 烽火通信科技股份有限公司 一种基于时延约束的数据发送方法及系统
FR3133934B1 (fr) * 2022-03-24 2024-08-09 Vitesco Technologies Procédé de gestion d’exécution d’une pluralité de fonctions

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2009087317A2 *

Also Published As

Publication number Publication date
WO2009087317A3 (fr) 2009-09-03
WO2009087317A2 (fr) 2009-07-16
JP2011501309A (ja) 2011-01-06
FR2923039A1 (fr) 2009-05-01

Similar Documents

Publication Publication Date Title
EP2203817A2 (fr) Procede de gestion des preemptions dans un systeme d&#39;exploitation en temps reel
US8392312B2 (en) Adaptive scheduling of storage operations based on utilization of a multiple client and server resources in a distributed network storage system
KR102585591B1 (ko) 이기종 프로세서 기반 엣지 시스템에서 slo 달성을 위한 인공지능 추론 스케쥴러
US8397235B2 (en) User tolerance based scheduling method for aperiodic real-time tasks
WO2002039256A2 (fr) Procede et systeme de determination du temps de reponse dans le meilleur des cas pour une tache periodique
EP2987081B1 (fr) Procédé d&#39;allocation temporelle de tâches permettant une récupération d&#39;erreur deterministe en temps réel
EP2266011B1 (fr) Procede de gestion de la consommation d&#39;energie pour les systemes multiprocesseurs
CN105389204B (zh) 一种多资源偏序调度方法
CN115421905A (zh) 一种任务调度方法、装置、电子设备及存储介质
EP2850520B1 (fr) Procede de gestion d&#39;une execution de taches dans un systeme informatique
EP2709008B1 (fr) Procédé et dispositif de décompte du temps déporté pour unité de traitement dans un système de traitement de l&#39;information
US20160299787A1 (en) System, method and managing device
US7293004B1 (en) Method for tuning state-based scheduling policies
CN117667332A (zh) 一种任务调度方法及系统
US20170147641A1 (en) Dynamic block intervals for pre-processing work items to be processed by processing elements
CN116438520A (zh) 用于非抢占式系统的实时任务调度的方法和装置
Springer et al. Resource synchronization in hierarchically scheduled real-time systems using preemptive critical sections
US7444316B1 (en) Method for scheduling jobs using distributed utility-based preemption policies
US12045671B2 (en) Time-division multiplexing method and circuit for arbitrating concurrent access to a computer resource based on a processing slack associated with a critical program
Gergeleit et al. Scheduling transient overload with the taft scheduler
CN111950835B (zh) 基于竞价型实例的截止期约束工作流资源调度方法
Zhao et al. Worst case response time analysis of sporadic graph tasks with fixed priority scheduling on a uniprocessor
US7363283B1 (en) Method for scheduling jobs using distributed utility-based oversubscription policies
NGUYEN THE UNIVERSITY OF CHICAGO
KR20050084107A (ko) 하드 실시간 시스템에서의 소프트웨어 구성요소의 풀스케줄링

Legal Events

Date Code Title Description
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

17P Request for examination filed

Effective date: 20100309

AK Designated contracting states

Kind code of ref document: A2

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

AX Request for extension of the european patent

Extension state: AL BA MK RS

RIN1 Information on inventor provided before grant (corrected)

Inventor name: AUGUIN, MICHEL

Inventor name: MUHAMMAD, FAROOQ

Inventor name: MULLER, FABRICE

17Q First examination report despatched

Effective date: 20101220

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: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20110701