Utilisateur:Kayode Da Cruz/Brouillon

Une page de Wikipédia, l'encyclopédie libre.

Context[modifier | modifier le code]

Afin de tester et évaluer les politiques d'ordonnancement existants et nouveaux, ont pourraient les intégrées dans un RTOS pour real-time operating system, mais il est nécessaire de modifier la structure interne du système d'exploitation, ce qui nécessite des compétences de programmation particulières. De plus, la modification du noyau interne du système d'exploitation représente une tâche difficile et chronophage, ce qui est l'une des raisons pour lesquelles si peu de politiques d'ordonnancement ont déjà été mises en œuvre[1]. Pour ce fait la majorité des chercheurs se tournent vers des solutions de simulation, notamment par le biais de frameworks capables de simuler le comportement des RTOS.

Définitions[modifier | modifier le code]

Système d'exploitation temps réel[modifier | modifier le code]

Un système d'exploitation temps réel, en anglais RTOS pour real-time operating system, est un système d'exploitation pour lequel le temps maximum entre un stimulus d'entrée et une réponse de sortie est précisément déterminé.

Ordonnanceurs dans les systèmes d'exploitation[modifier | modifier le code]

Dans les systèmes d'exploitation, l’ordonnanceur est le composant du noyau du système d'exploitation choisissant l'ordre d'exécution des processus sur les processeurs d'un ordinateur.

Ordonnancement dans les systèmes temps réel[modifier | modifier le code]

Le but de l'ordonnancement des tâches est d'organiser l'ensemble des tâches prêtes à être exécutées par le système afin que les objectifs de performance soient atteints[2]. L'ordre de ces tâches est appelé planning. Pour les systèmes embarqués temps réel, l'objectif premier est de s'assurer que toutes les tâches respectent leurs délais. Un échéancier peut être faisable ou optimal : un échéancier faisable ordonne les tâches en les faisant respecter tous leurs délais ; un échéancier optimal est celui qui garantit que les échecs à respecter les délais des tâches sont minimisés. L'ordonnanceur est chargé de coordonner l'exécution de plusieurs tâches sur un processeur. L'ordonnanceur peut être préemptif ou non préemptif. L'ordonnanceur pour les systèmes temps réel durs doit coordonner les ressources pour répondre aux contraintes de temps du système physique, ce qui implique que l'ordonnanceur doit être capable de prédire le comportement d'exécution de toutes les tâches au sein du système[3]. La prévisibilité est donc l'exigence de base des systèmes en temps réel. A moins que le comportement d'un système temps réel ne soit prévisible, l'ordonnanceur ne peut garantir que les délais de calcul du système seront respectés[4].

Algorithmes d'ordonnancement[modifier | modifier le code]

Un algorithme d'ordonnancement est un ensemble de règles qui déterminent la tâche à exécuter à un moment donné. Les algorithmes d'ordonnancement étudiés dans cet article sont préemptives. Cela signifie que lorsqu'il y a une demande pour une tâche plus prioritaire que celle en cours d'exécution, la tâche en cours d'exécution est immédiatement interrompue et la nouvelle tâche demandée est lancée. Ainsi, la spécification de ces algorithmes revient à spécifier la méthode d'attribution des priorités aux d'affecter des priorités aux tâches. On dit d'un algorithme d'ordonnancement qu'il est statique si les priorités sont attribuées aux tâches une fois pour toutes. Un algorithme d'ordonnancement statique est également appelé algorithme d'ordonnancement à priorité fixe. Un algorithme d'ordonnancement est dit dynamique si les priorités des tâches peuvent changer d'une demande à l'autre. Un algorithme d'ordonnancement est dit mixte si les priorités de certaines tâches sont fixes alors que les priorités des autres tâches varient d'une demande à l'autre[5].

Algorithmes d'ordonnancement statique[modifier | modifier le code]

First Come First Served[modifier | modifier le code]

La politique FCFS est la stratégie d'ordonnancement la plus simple à trouver, car elle n'invoque aucune contrainte de tâche. Les tâches prêtes à l'emploi sont organisées dans une liste, celle en haut étant exécutée en premier[6]. Lorsqu'une tâche devient prête, elle est ajoutée à la fin de la liste prête. Ainsi, les tâches s'exécutent dans l'ordre dans lequel elles sont préparées, premier arrivé, premier servi. Il n'est pas préemptif, chaque tâche étant autorisée à s'exécuter jusqu'à son terme[7].

Round Robin[modifier | modifier le code]

La politique RR est la version préemptive de la technique FCFS. Les tâches sont toujours classées dans la liste des prêts dans l'ordre dans lequel elles sont prêtes à être exécutées, mais lorsqu'elles sont définies en cours d'exécution, elles s'exécutent dans une tranche de temps fixe[8]. Si une tâche est toujours en cours d'exécution à la fin de sa tranche de temps, elle est supprimée de force du processeur. Son remplacement est la tâche qui était en tête de la file d'attente prête et la tâche préemptée est envoyée à la fin de la file d'attente prête. Au fur et à mesure que l'ensemble de tâches est exécuté, il progresse progressivement vers le haut de la file d'attente. Lorsqu'il est à nouveau installé sur le processeur, il reprend l'exécution à partir du point d'interruption[9].

Shortest Job First[modifier | modifier le code]

La politique SJF est une alternative statique basée sur la priorité à la stratégie de planification FCFS. Il utilise un seul critère pour définir la priorité, le temps d'exécution des tâches. Dans la liste prête, la tâche avec le temps de calcul le plus court (dans le pire des cas) se voit attribuer la priorité de planification la plus élevée. En conséquence, il est placé en tête de la file d'attente des prêts, en attente de service par le processeur. Cependant, la stratégie n'est pas préemptive et la tâche d'exécution en cours est toujours autorisée à se terminer[10].

Rate Monotonic[modifier | modifier le code]

L'ordonnancement monotone de fréquence est un algorithme d'ordonnancement à priorité statique pour les tâches périodiques. En RM, les priorités sont égales aux périodes des tâches associées. Par conséquent, la tâche avec la période la plus courte a la priorité la plus élevée et la tâche avec la période la plus longue a la priorité la plus faible. Intuitivement, cette hiérarchisation a du sens, puisque la tâche qui a la période la plus courte sera la première à être relâchée. Par conséquent, il devrait être le premier à terminer. RM n'est pas optimal lorsque l'échéance de chaque tâche n'est pas simultanée avec la prochaine version de la tâche (période)[11].

Deadline Monotonic[modifier | modifier le code]

L'ordonnancement DM est un algorithme d'ordonnancement à priorité statique pour les tâches périodiques. DM utilise la durée d'échéance de chaque tâche pour sa priorité. Ainsi, les tâches avec le plus petit délai auront la priorité la plus élevée, et les tâches avec le plus grand délai auront la priorité la plus faible. L'intuition derrière DM est que la tâche avec le plus petit délai (pas nécessairement celle avec la plus petite période) devrait être la tâche considérée comme la plus urgente et donc la tâche avec la priorité la plus élevée[12].

Algorithmes d'ordonnancement dynamique[modifier | modifier le code]

Earliest Deadline First[modifier | modifier le code]

EDF est un algorithme d'ordonnancement de priorité dynamique qui attribue la priorité la plus élevée à toute tâche ayant l'échéance la plus proche. Formellement, la priorité d'une tâche τi à l'instant t est donnée par :

où est la prochaine échéance de τi (à ou après ). Pour les ensembles de tâches où la période de la tâche est identique à sa durée d'échéance, EDF produira un calendrier valide si et seulement si l'utilisation du processeur de l'ensemble de tâches est de un ou moins. Si un ensemble de tâches a une utilisation supérieure à un, l'ensemble de tâches n'a pas de planification valide[13].

Least Laxity First[modifier | modifier le code]

Le principe d'ordonnancement LLF (ou Earliest Deadline as Late as possible, EDL) utilise le critère du laxisme de la tâche (c'est-à-dire du temps libre). EDL attribue la priorité la plus élevée à la tâche ayant le moins de laxisme. Pour EDL, une fois qu'une tâche est préparée, le délai jusqu'à l'échéance diminue au fur et à mesure que le temps s'écoule. L'expression générale définissant la laxité d'une tâche est :

  • laxity(i,t) = max(TD(i) − Tc(i) − t,0.000)

où est sa date limite, est son temps de calcul et est le temps d'exécution actuel. Le deuxième paramètre de fonction max est fixé à 0,000 car une valeur de laxité ne doit jamais être négative. Il est évident que le laxisme est un attribut dynamique ; faisant ainsi de LLF une politique d'ordonnancement dynamique[14].

Frameworks de simulation temps réel[modifier | modifier le code]

Voici quelques frameworks qui par leur capacité à simuler les systèmes temps permettent de tester les algorithmes d'ordonnancement des tâches temps réels :

  • Realtss : un simulateur d'ordonnancement en temps réel open source qui est adapté pour simuler des algorithmes d'ordonnancement en temps réel sans avoir besoin de les implémenter dans un RTOS[15].
  • STORM[16] : est un framework pour la simulation de tâches en temps réel conçues pour un multiprocesseur et a donc un support inhérent pour les ressources multicœurs et partagées.
  • YASA[17] : est un framework développé à l'Université de Rostock (Deutchland). Ses objectifs sont la simulation et l'analyse d'applications temps réel sur différentes plateformes (le simulateur et RT-Linux). Le framework prend en charge divers types d'algorithmes de planification en temps réel et de protocoles de synchronisation qui peuvent être simulés à des fins d'évaluation. De plus les implémentations de ces algorithmes peuvent être testées dans un système d'exploitation temps réel.
  • Cheddar[18] : est un framework Ada qui implémente la plupart des méthodes théoriques classiques d'ordonnancement en temps réel. Les systèmes à analyser peuvent être décrits avec AADL ou avec un langage spécifique. Cheddar propose deux types de fonctionnalités : un moteur de simulation et des calculs de tests de faisabilité. Le moteur de simulation Cheddar fournit des outils pour concevoir des planificateurs et des modèles de tâches spécifiques.
  • SimSo[19] : est un outil de simulation conçu pour la comparaison et la compréhension des politiques d'ordonnancement en temps réel. Actuellement, il supporte plus de 20 algorithmes et il peut être facilement étendu à d'autres algorithmes.
  • YARTISS : est un simulateur d'ordonnancement multi-processeurs en temps réel. Il permet de simuler un ensemble de tâches sur un ou plusieurs processeurs en contrôlant la consommation énergétique du système, simuler simultanément un grand nombre d'ensembles de tâches et présenter les résultats d'une manière conviviale qui permet d'isoler les cas intéressants et enfin générer aléatoirement un grand nombre d'ensembles de tâches[20].
  • EERTS : est un simple planificateur de tâches en temps réel avec l'énergie ambiante comme caractéristique principale [21].
  • STRESS[22] : est un framework qui comprend un langage de simulation pour spécifier à la fois l'environnement du système et les paramètres de la tâche. Il comprend aussi une interface graphique pour le contrôle et l'affichage, des tests de faisabilité et la prise en charge du multitraitement et de la mise en réseau.
  • SAGS : est le premier simulateur qui montre graphiquement toutes les étapes de l'exécution des systèmes en temps réel. Nous modélisons un système en temps réel avec un système liquide-bouteille-convoyeur à bande et les algorithmes d'ordonnancement peuvent être écrits en utilisant une combinaison de paramètres du système ou en utilisant une fonction C++ écrite[23].

Méthodes de comparaison des algorithmes d'ordonnancemnet[modifier | modifier le code]

Les performances des tests d'ordonnancement pour les algorithmes d'ordonnancement en temps réel peut être comparée de plusieurs manières différentes. Celles-ci peuvent être classées en deux grandes catégories :

  • Les méthodes théoriques telles que la dérivation des relations de dominance, les limites d'utilisation[24] ou les résultats des facteurs d'augmentation des ressources et les résultats des facteurs d'accélération[25]. Ces approches donnent généralement une comparaison dans le pire des cas contre un concurrent spécifique, c'est-à-dire un test d'ordonnançabilité alternatif pour le même ou un différent concurrent.
  • Les méthodes empiriques consistent à évaluer les tests d'ordonnançabilité sur un grand nombre d'ensembles de tâches de différents niveaux d'utilisation. Ces approches facilitent généralement une comparaison de cas moyen avec un certain nombre de différents concurrents[26].

Les méthodes théoriques[modifier | modifier le code]

Les relations de dominance (Dominance Relationships)[modifier | modifier le code]

Cette méthode montrent qu'un test d'ordonnançabilité est toujours plus performant qu'un autre. Par exemple, on dit que le test d'ordonnancement A domine le test d'ordonnancement B si chaque ensemble de tâches qui est ordonnançable selon le test B est également ordonnançable selon le test A, et qu'il existe des ensembles de tâches qui sont ordonnançables selon selon le test A mais pas selon le test B. Si deux tests d'ordonnançabilité considèrent précisément les mêmes ensembles de tâches comme étant dits équivalents. S'il existe des ensembles de tâches tâches qui sont ordonnançables selon le test A et non pas selon le test B, et vice versa, les tests sont dits incomparables[27].

  • Prouver les relations de dominance présente l'avantage évident suivant : il est démontré que la méthode dominante est toujours meilleure. Pour example nous avons la comparaison entre l'agorithme d'ordonnancement EDF(Earliest Deadline First) et l'algorithme d'ordonnancement a priorité fixe[28].
  • Les inconvénients sont que la relation de dominance ne vaut généralement que pour un modèle simplifié. Par exemple, EDF(Earliest Deadline First) domine l'ordonnancement à priorité fixe que pour les modèles simples dans lesquels l'inclusion des frais généraux d'ordonnancement ou des délais de préemption liés au cache est négligeable[29].

Limites d'utilisation (Utilisation Bounds)[30][modifier | modifier le code]

Cette méthode permet de fournir un moyen simple de comparer différents algorithmes d'ordonnancement. La limite pour un algorithme d'ordonnancement donné est la valeur d'utilisation la plus élevée telle que tous les ensembles de tâches dont l'utilisation ne dépasse pas cette cette valeur soient garantis comme étant planifiables (selon un test exact).

  • Le principal avantage d'une limite d'utilisation est qu'elle illustre le comportement le plus défavorable pour tout ensemble de tâches à échéance implicite[31], et peut donc être utilisée comme un simple test d'ordonnancement en temps linéaire[32].
  • Les inconvénients sont que la limite s'applique uniquement à un modèle de système simple (c'est-à-dire des échéances implicites, pas de frais généraux, etc)et le comportement le plus défavorable peut n'exister que pour des cas particuliers spécifiques qui présentent peu d'intérêt dans la pratique[33][20].

Facteurs d'accélération (Speedup Factors )[34][modifier | modifier le code]

Cette méthode permet d'indiquer le facteur par lequel la vitesse d'un système devrait augmenter pour que tout ensemble de tâches qui étaient ordonnançable sous l'algorithme A soit garanti de devenir ordonnançable sous l'algorithme B[35].

  • L'avantage de dériver des facteurs d'accélération est qu'ils illustrent les pires performances qu'un algorithme d'ordonnancement peut avoir par rapport à un autre[36].
  • Les inconvénients de l'utilisation des facteurs d'accélération comme mesure sont les suivants le comportement le plus défavorable peut n'exister que dans des cas isolés qui présentent peu d'intérêt en pratique[37].

Les méthodes empiriques[modifier | modifier le code]

Simulations ou évaluations basées sur des scénarios (Simulations or scenario based assessments)[modifier | modifier le code]

Cette méthode consiste à simuler l'exécution d'un ensemble de tâches sur une longue période de temps et est généralement répétée pour plusieurs ensembles de tâches.

  • De telles simulations sont utiles pour explorer le comportement du cas moyen[38].
  • Les inconvénients de la simulation sont les suivants qu'il n'y a généralement aucune garantie que les comportements les plus défavorables seront observés, sauf si le scénario le plus défavorable (modèle d'arrivées) est connu[39].

Expériences réelles (Real experiments)[modifier | modifier le code]

Cette méthode implique l'exécution de code réel ou dans certains cas, du code de tâche généré synthétiquement, sur du matériel réel.

  • De telles expériences présentent des avantages similaires à ceux de la simulation (exploration du comportement dans le cas moyen et et en tant que test d'ordonnancement nécessaire)[40].
  • Les inconvénients de cette approche expérimentale sont qu'il n'y a garantie que le comportement le plus défavorable a été observé, sauf si le scénario le plus défavorable est connu[41].

Études de cas (Case studies)[modifier | modifier le code]

Un ou plusieurs exemples d'ensembles de tâches sont tirés d'applications industrielles. Généralement, l'étude de cas fournit des valeurs de paramètres spécifiques (par exemple, périodes, temps d'exécution, pour les tâches) et dans certains cas, elle peut fournir un code à partir duquel d'autres valeurs de paramètres peuvent être dérivées. Par exemple, le code de la suite de benchmark Mälardalen[42] peut être utilisé peut être utilisé pour obtenir non seulement les temps d'exécution dans le pire des cas (WCET), mais aussi des traces d'accès aux adresses et donc une caractérisation de la demande en mémoire et de mémoire et de l'utilisation du cache[43].

  • Les avantages de l'utilisation d'informations provenant d'études de cas sont le suivants, la certitude que les valeurs de paramètres utilisées sont réalistes (au moins pour un domaine d'application), et la possibilité d'obtenir des valeurs de paramètres cohérentes pour chaque tâche.
  • Les inconvénients comprennent une couverture potentiellement très limitée de l'espace des paramètres, par exemple, l'utilisation d'un seul exemple peut cacher des problèmes ailleurs[44].

Évaluation empirique (Empirical evaluation)[modifier | modifier le code]

Cette méthode implique l'utilisation d'un grand nombre de tâches générées synthétiquement pour évaluer la performance des tests d'ordonnancement.

  • Les avantages de cette approche présente est que si elle est bien conçue, cela permet de bien couverture de l'espace des paramètres et donc fournir une comparaison comparaison équitable et impartiale.
  • Les inconvénients comprennent l'incertitude quant à si les valeurs couvertes sont représentatives de systèmes réels et la prise en compte des frais généraux, qui est souvent négligée[45].

Notes et Références[modifier | modifier le code]

  1. ↑ Arnoldo 2007, p. 165
  2. ↑ Barbara 1994, p. 501-511
  3. ↑ Chi-scheng 2001, p. 120-122
  4. ↑ Yaashuwanth 2010, p. 826
  5. ↑ LIU 1973, p. 48
  6. ↑ Barbara 1994, p. 501-511
  7. ↑ Yaashuwanth 2010, p. 827
  8. ↑ Krithi 1994, p. 55-67
  9. ↑ Yaashuwanth 2010, p. 827
  10. ↑ Yaashuwanth 2010, p. 827
  11. ↑ Yaashuwanth 2010, p. 827
  12. ↑ Yaashuwanth 2010, p. 827-828
  13. ↑ Yaashuwanth 2010, p. 827
  14. ↑ Yaashuwanth 2010, p. 827
  15. ↑ Arnoldo 2007, p. 165
  16. ↑ Richard 2010
  17. ↑ Frank 2002
  18. ↑ Frank 2004
  19. ↑ Maxime 2014
  20. ↑ Younès 2012, p. 7
  21. ↑ Girish 2017
  22. ↑ Audsley 1994, p. 2
  23. ↑ Kamal 2011
  24. ↑ Liu 1973, p. 46-61
  25. ↑ Bala 1995, p. 214-221
  26. ↑ Robert 2016, p. 1
  27. ↑ Robert 2016, p. 1
  28. ↑ Liu 1973, p. 46-61
  29. ↑ Will 2014
  30. ↑ Liu 1973, p. 46-61
  31. ↑ Dans un ensemble de tâches à délais implicites, toutes les tâches ont des délais égaux à leurs périodes
  32. ↑ Robert 2016, p. 1
  33. ↑ John 1989, p. 166–171
  34. ↑ Bala 1995, p. 214-221
  35. ↑ Robert 2016, p. 2
  36. ↑ Robert 2009, p. 211-258
  37. ↑ Robert 2015, p. 566-601
  38. ↑ Joël 2016, p. 1-25
  39. ↑ Romulo 2013
  40. ↑ Bjorn 2011, p. 1
  41. ↑ Robert 2016, p. 2
  42. ↑ Gustafsson 2010, p. 137–147
  43. ↑ Altmeyer 2015, p. 1129-138
  44. ↑ Robert 2016, p. 2
  45. ↑ Robert 2016, p. 2-3

Bibliographie[modifier | modifier le code]

Document utilisé pour la rédaction de l’article *(en) Frank Golatowski, J. Hildebrandt, Jan Blumenthal et Dirk Timmermann, « Framework for validation, test and analysis of real-time scheduling algorithms and scheduler implementations », IEEE Xplore,‎ (ISBN 0-7695-1703-X, DOI 10.1109/IWRSP.2002.1029750)

Document utilisé pour la rédaction de l’article *(en) C. Yaashuwanth et R. Ramesh, « Web-Enabled Framework for Real-Time Scheduler Simulator (A Teaching Tool) », IEEE Xplore,‎ (ISBN 978-0-7695-4043-6, DOI 10.1109/ICCRD.2010.181)

Document utilisé pour la rédaction de l’article *(en) R. Ramesh et Yaashuwanth Calpakkam, « Design and Development of Real Time Scheduler Simulator with Co-processor (Teaching Tool) », IAENG,‎ (ISBN 978-988-18210-9-6)

Document utilisé pour la rédaction de l’article *(en) Frank Singhoff, Jérôme Legrand, Laurent Nana et Lionel Marcé, « Cheddar: a flexible real time scheduling framework », ACM Digital Library,‎ (ISBN 978-1-58113-906-8)

Document utilisé pour la rédaction de l’article *(en) Maxime Chéramy, Pierre-Emmanuel Hladik et Anne-Marie Déplanche, « SimSo: A Simulation Tool to Evaluate Real-Time Multiprocessor Scheduling Algorithms », HAL,‎

Document utilisé pour la rédaction de l’article *(en) Younès Chandarli, Frédéric Fauberteau, Damien Masson, Serge Midonnet et Manar Qamhieh, « YARTISS: A Tool to Visualize, Test, Compare and Evaluate Real-Time Scheduling Algorithms », HAL,‎

Document utilisé pour la rédaction de l’article *(en) Kamal Jamshidi et Mohsen Koohi, « SAGS: Scheduling Algorithms Graphical Simulator of RTOSs », AACE,‎ (ISBN 978-1-880094-85-3)

Document utilisé pour la rédaction de l’article *(en) Girish S. Thakare et Prashant R. Deshmukh, « EERTSS: An Energy Efficient Real-Time Task Scheduling Simulator », IEEE Xplore,‎ (ISBN 978-1-5386-4008-1, DOI 10.1109/ICCUBEA.2017.8463807)

Document utilisé pour la rédaction de l’article *(en) Goran Martinović, Željko Hocenski et Leo Budin, « Validation of scheduling algorithms for aperiodic tasks in the real time systems », IEEE Xplore,‎ (ISBN 953-96769-1-6)

Document utilisé pour la rédaction de l’article *(en) Arnoldo Diaz, Ruben Batista et Oskardie Castro, « Realtss: a real-time scheduling simulator », IEEE Xplore,‎ (ISBN 978-1-4244-1165-8, DOI 10.1109/ICEEE.2007.4344998)

Document utilisé pour la rédaction de l’article *(en) Richard Urunuela, Anne-Marie Déplanche et Yvon Trinquet, « STORM a simulation tool for real-time multiprocessor scheduling evaluation », IEEE Xplore,‎ (ISBN 978-1-4244-6850-8, DOI 10.1109/ETFA.2010.5641179)

Document utilisé pour la rédaction de l’article *(en) Barbara Korousic-Seljak, « Task scheduling policies for real-time systems », ScienceDirect,‎ (DOI 10.1016/0141-9331(94)90073-6)

Document utilisé pour la rédaction de l’article *(en) Chi-scheng Shih, Lui Sha et Jane Liu, « Scheduling Tasks with Variable Deadlines », IEEE Xplore,‎ (ISBN 0-7695-1134-1, DOI 10.1109/RTTAS.2001.929874)

Document utilisé pour la rédaction de l’article *(en) R. Ramesh et Yaashuwanth Calpakkam, « Design and Development of Real Time Scheduler Simulator with Co-processor (Teaching Tool) », IAENG,‎ (ISBN 978-988-18210-9-6)

Document utilisé pour la rédaction de l’article *(en) Robert I. DAVIS et Alan BURNS, « A survey of hard real-time scheduling for multiprocessor sys- tems », ACM Computing Surveys,‎ (DOI 10.1145/1978802.1978814)

Document utilisé pour la rédaction de l’article *(en) C. L. LIU et James W. LAYLAND, « Scheduling Algorithms for Multiprogramming in a Hard- Real-Time Environment », ACM Digital Library,‎ (DOI 10.1145/321738.321743)

Document utilisé pour la rédaction de l’article *(en) Krithi Ramamritham et John A. Stankovic, « Scheduling algorithms and operating systems support for real-time systems », IEEE Xplore,‎ (DOI 10.1109/5.259426)

Document utilisé pour la rédaction de l’article *(en) Bala Kalyanasundaram et Kirk Pruhs, « Speed is as powerful as clairvoyance », Journal of the ACM,‎ (DOI 10.1.1.55.5046)

Document utilisé pour la rédaction de l’article *(en) Robert I. Davis, « On the Evaluation of Schedulability Tests for Real-Time Scheduling Algorithms », In WATERS,‎

Document utilisé pour la rédaction de l’article *(en) Will Lunniss, Sebastian Altmeye et Robert I. Davis, « A Comparison between Fixed Priority and EDF Scheduling accounting for Cache Related Pre-emption Delays », Leibniz Transactions on Embedded Systems,‎ (DOI 10.4230/LITES-v001-i001-a001)

Document utilisé pour la rédaction de l’article *(en) Joël Goossens, Emmanuel Grolleau et Liliana Cucu-Grosjean, « Periodicity of real-time schedules for dependent periodic tasks on identical multiprocessor platforms », Real-Time Systems,‎ (DOI 10.1007/s11241-016-9256-1)

Document utilisé pour la rédaction de l’article *(en) Romulo S. de Oliveira, Andreu Carminati et Renan A. Starke, « On using adversary simulators to evaluate global fixed-priority and FPZL scheduling of multiprocessors », Journal of Systems and Software,‎ (DOI 10.1016/j.jss.2012.09.002)

Document utilisé pour la rédaction de l’article *(en) John Lehoczky, L. Sha et Y. Ding, « The rate monotonic scheduling algorithm: Exact characterization and average case behaviour », In Proceedings Real-Time Systems Symposium,‎ (ISBN 0-8186-2004-8, DOI 10.1109/REAL.1989.63567)

Document utilisé pour la rédaction de l’article *(en) Robert I. Davis, T. Rothvoß, S.K Baruah et A. Burns, « Exact Quantification of the Sub-optimality of Uniprocessor Fixed Priority Pre-emptive Scheduling », Real-Time Systems,‎ (DOI 10.1007/s11241-009-9079-4)

Document utilisé pour la rédaction de l’article *(en) Robert I. Davis, T. Rothvoß, S. Baruah, A. Burns, L. George et O. Gettings, « Exact comparison of fixed priority and EDF scheduling based on speedup factors for both pre-emptive and non-pre-emptive paradigms », Real-Time Systems,‎ (DOI 10.1007/s11241-015-9233-0)

Document utilisé pour la rédaction de l’article *(en) Bjorn B. Brandenburg, « Scheduling and Locking in Multiprocessor Real-Time Operating Systems », PhD Thesis, The University of North Carolina at Chapel Hill,‎ (ISBN 978-1-267-25618-8, DOI 10.5555/2521882)

Document utilisé pour la rédaction de l’article *(en) Jan Gustafsson, A. Betts, A. Ermedahl et B. Lisper, « The Mälardalen WCET benchmarks – past, present and future », In WCET,‎ (DOI 10.4230/OASIcs.WCET.2010.136)

Document utilisé pour la rédaction de l’article *(en) N. C. Audsley, A. Burns, M. F. Richardson et A. J. Wellings, « STRESS: A Simulator for Hard Real-time Systems », SOFTWARE—PRACTICE AND EXPERIENCE,‎ (DOI 10.1.1.38.751)

Liens externes[modifier | modifier le code]

Document utilisé pour la rédaction de l’article « Système d'exploitation temps réel », sur https://fr.wikipedia.org/

Document utilisé pour la rédaction de l’article « Ordonnancement dans les systèmes d'exploitation », sur https://fr.wikipedia.org/

Document utilisé pour la rédaction de l’article « Ordonnancement et Analyse d'ordonnancement », sur http://david.decotigny.free.fr/

Document utilisé pour la rédaction de l’article « Architecture Analysis and Design Language », sur https://fr.wikipedia.org/

Document utilisé pour la rédaction de l’article « Framework », sur https://fr.wikipedia.org/

Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Utilisateur:Kayode_Da_Cruz/Brouillon&oldid=189658586 ».