Introduction Programmation Temps Réel

INTRODUCTION LA
PROGRAMMATION TEMPS REL

POLYCOPI DU COURS PTR
Prof. Yann Thoma
HEIG-VD
2010
Chapitre 1
Introduction la programmation temps rel
1.1 Quest-ce que la programmation temps rel ?
U
N SYSTME temps rel est un systme informatique devant rpondre des stimuli de
lenvironnement en tenant compte de contraintes de temps. Le comportement correct
dun tel systme ne dpend donc pas uniquement des rsultats fournis, mais galement
de la date laquelle ces rsultats sont communiqus. Un calcul correct mais tardif sera
considr comme faux, si les contraintes temporelles du systme sont strictes.
Par opposition aux systmes temps rel, un systme informatique standard est dit transformationnel.
Une application de bureautique standard tournant sur un PC est un systme transformationnel. Les
donnes y sont traites, sans que le temps ncessaire ce traitement ne soit crucial.
Un systme temps rel typique sera dcompos en tches, chaque tche tant responsable de la
gestion dune partie du systme. La gure 1.1 illustre linteraction qua un tel systme avec son
environnement, dans le cas dune tche de contrle. Nous pouvons noter que certains systmes
nauront pas proprement parler de systme de gestion des sorties vers lenvironnement. Les sorties
pourront effectivement tre un chier restant interne au systme informatique.
Figure 1.1 Systme temps rel pour une tche de contrle
Systme de
contrle
Gestion des
entres
Gestion des
sorties
Environnement
Systme
temps rel
La dnition donne par Abrial-Bourgne dnit bien ce quest un systme temps rel :
Un systme fonctionne en temps rel sil est capable dabsorber toutes les informations
dentre sans quelles soient trop vieilles pour lintrt quelles reprsentent, et par
ailleurs, de ragir celles-ci sufsamment vite pour que cette raction ait un sens. [6]
Programmation Temps Rel c Yann Thoma // HEIG-VD
1.2 CHAPITRE 1. INTRODUCTION LA PROGRAMMATION TEMPS REL
Et ladage suivant devra tre gard en mmoire :
Un rsultat juste mais hors dlai est un rsultat faux.
Le fait quun rsultat soit faux de par son arrive tardive peut tre extrmement critique et mme
dangereux. Un exemple typique est un pilote automatique dans un avion. Un tel systme pourrait
tre dcompos en une tche responsable de rcuprer les valeurs de diffrents capteurs (altitude,
vitesse, ...), une tche responsable de calculer la puissance fournir aux racteurs ainsi que les
angles des empennages, et une dernire tche responsable des actuateurs (arrive de carburant, em-
pennages). Si une mesure des capteurs est effectue rgulirement, que les donnes sont transmises
la tche de calcul, qui ensuite transmet ses rsultats la dernire tche, il serait judicieux que ce
processus ne prenne pas un temps trop important. En effet, 300km/h lors dun atterissage, une se-
cond dinattention pourrait tre fatale. Dans ce cas, les tches doivent avoir des dlais stricts, et ces
dlais doivent absolument tre respects pour que le fonctionnement global soit considr comme
correct, un fonctionnement anormal pouvant avoir des consquences dsastreuses.
Cet exemple peut montrer quil faut que le systme effectue son traitement le plus rapidement
possible. Mais attention ne pas tomber dans le pige : Un systme temps rel nest pas un systme
qui effectue du calcul de manire rapide. En effet, les systmes que nous traiterons doivent fournir
les rsultats dans un temps bien spcique, mais celui-ci peut tre long. La rapidit nest pas un
critre, par contre la abilit, lie au respect de contraintes temporelles, en est un.
Les dlais de systmes temps rel peuvent effectivement tre trs lches, mais extrmement sen-
sibles des dpassements de dlai. Le tableau 1.1 montre des exemples dordres de grandeur de
temps, dans les systmes informatiques.
Durant ce cours de programmation temps rel, nous allons tudier des algorithmes permettant das-
surer la bonne marche dun systme temps rel, et notamment voir pourquoi aller vite ne suft pas.
Nous verrons galement quil est trs dlicat dtre sr quun systme a t correctement conu,
et quil est possible quun tel systme fonctionne pendant longtemps avant quune faute ne puisse
survenir. An de garder lesprit ce type de mauvaise surprise, le tableau 1.2 liste quelques lois
tires de [4] particulirement adaptes au contexte du temps rel. Noubliez pas de vous y rfrer
lorsquun systme qui a fonctionn pendant plusieurs minutes, heures, ou jours, vient subitement
de dcider de crasher.
1.2 Proprits attendues
Les systmes temps rel sont des systmes devant respecter les contraintes de temps imposes. A
priori, le code de chacune des tches composant un tel systme est connu. Il peut donc tre analys
en termes de temps dexcution, ressources ncessaires, et dpendance envers dautres tches. Les
proprits suivantes devraient tre respectes :
Gestion du temps. Les rsultats doivent tre corrects, non seulement en termes de valeur, mais ga-
lement termes de temps darrive. Le systme doit garantir que les tches se terminent dans les
dlais impartis, en respectant les contraintes de temps imposes.
Conception pour stress. Un systme temps rel ne doit pas succomber lorsquil est soumis une
charge importante. Des scnarios mettant en avant des charges limites doivent tre anticips, et
tests.
Predictibilit. A chaque dcision lie lordonnanement des tches, le systme doit tre capable
de prdire les consquences de son choix. Il doit pouvoir dire si les tches sont ordonnanables, et
si tel est le cas proposer un ordonnanement. Sil nest pas possible de grer lensemble de tches,
des actions coordonnes doivent tre prises an de ne pas compromettre le fonctionnement du
systme.
1.2. PROPRITS ATTENDUES 1.3
Temps Exemple
nanosecond - O(ns) Temps daccs une RAM (5-80ns)
Dure entre deux ticks dhorloge dun processeur Pentium
(1GHz)
Frquence de 1GHz (10
9
Hz)
microseconde - O(s) Traitement dans un noyau de systme dexploitation (chan-
gement de contexte, interruption matrielle)
Systmes utilisant des radars (navigation, dtection de
mouvement, etc.)
Transmission sur des bus de terrain, transmission radio
Frquence de 1 MHz (10
6
Hz)
milliseconde - O(ms) Temps daccs un disque dur SCSI ou IDE (5-20 ms)
La dure dchantillonnage du son, protocoles de tlcom-
munication
Frquence de 1 KHz (10
3
Hz)
seconde (s) - O(s) Systmes de visualisation humain (temps durant lequel
loeil peut "intgrer" 25 images au plus)
Applications multimdia
Temps de rponse des applications informatiques (accs
DB, compilation, etc.)
Frquence de 1 Hz
Lheure (h) - O(h) Applications de surveillance de ractions chimiques, sur-
veillance de donnes mtorologiques
Le mois, lanne - O(m, a) Systmes de navigation de sonde spatiale
Tableau 1.1 Ordres de grandeur de temps
Tolrance aux fautes. Un systme de contrle critique (p. ex. dans un avion) doit tre tolrant aux
fautes logicielles et matrielles. Les composants utiliss doivent donc tre conu pour tre tol-
rants aux fautes.
Maintenance. Comme tout systme informatique, larchitecture dun systme temps rel doit tre
pens de faon modulaire, an que des modications du systme puissent tre ralises facilement.
1.2.1 Prdictibilit
Alors quun systme informatique standard ne fait que traiter des donnes, le systme temps rel
doit garantir que les contraintes de temps seront respectes. Lors de lattribution du processeur
telle ou telle tche, le systme doit obligatoirement connatre le temps dexcution de chacune des
tches. Ceci ncessite de connatre plusieurs lments :
Le code crit par le programmeur
La structure du noyau du systme dexploitation
La structure du processeur et de ses priphriques
Murphys General Law
If something can go wrong, it will go wrong.
Murphys Constant
Damage to an object is proportional to its value.
Naesers Law
One can make something bomb-proof, not jinx-proof.
Troutman Postulates
1. Any software bug will tend to maximize the damage.
2. The worst software bug will be discovered six months after the
eld test.
Greens Law
If a system is designed to be tolerant to a set of faults, there will always
exist an idiot so skilled to cause a nontolerated fault.
Corollary
Dummies are always more skilled than measures taken to keep them
from harm.
Johnsons First Law
If a system stops working, it will do it at the worst possible time.
Sodds Second Law
Sooner or later, the worst possible combination of circumstances will
happen.
Corollary
A system must always be designed to resist the worst possible combina-
tion of circumstances.
Tableau 1.2 Lois de Murphy relatives aux systmes temps-rel.
1.2. PROPRITS ATTENDUES 1.5
Programmation
Le code dune tche devant tre excute dans un contexte temps rel doit tre particulirement bien
conu. Nous notons ici trois lois quun dveloppeur devrait respecter :
Absence de structures de donnes dynamiques. Les langages de haut niveau permettent dallouer
et de dsallouer dynamiquement de la mmoire lors de lexcution. Toutefois ces oprations sont
trs lourdes en termes de temps processeur, et ne peuvent aisment tre bornes en temps. Ds
lors il est trs dlicat dvaluer le pire temps dexcution dune tche excutant une allocation
mmoire. Si des allocations dynamiques sont ncessaires, elles devraient tre faites au lancement
du systme, mais pas durant son excution courante.
Absence de rcursion. Les appels rcursifs devraient tre vits, car, si la profondeur de rcursion
nest pas connu a priori, le temps ainsi que les ressources ncessaires ne pourront tre borns.
Boucles bornes en temps. Le nombre ditrations des boucles devrait tre born, an de pouvoir
estimer leut temps dexcution. Si tel nest pas le cas, il est impossible destimer le temps dex-
cution dune tche.
Appels systme
En analysant le code crit par le programmeur, il semble tre possible destimer le pire temps dex-
cution. Un des problmes vient des diffrents appels systme, lautre type de problme tant li
la structure matrielle du processeur. Les appels systmes font appel des librairies, et permettent
par exemple une tche dallouer de la mmoire, dcrire/lire dans des chiers, afcher des infor-
mations sur un cran, communiquer via un port Ethernet ou un port srie, ou se synchroniser avec
dautres tches. Ces diffrents appels systme, vus par le programmeur, restent des appels des
fonctions de haut niveau. Le noyau du systme dexploitation se charge du traitement des requtes,
et ce traitement dpend grandement du systme dexploitation cible. Toutes les fonctions appeles
devraient tre analyses an de mieux dnir le temps dexcution dune tche.
Gestion de la mmoire
Le systme dexploitation est responsable de la bonne gestion de la mmoire (pagine, segmen-
te). Le concept de mmoire virtuelle, que lon trouve utilis dans tous les systmes dexploitation
standards, permet de mieux protger les processus, et doffrir aux processus limpression quils dis-
posent dune quantit de mmoire plus importante que la quantit de mmoire physique rellement
prsente. Ce concept puissant a toutefois un dsavantage en termes de temps dexcution. Les accs
mmoires y sont plus lents, et surtout une faute de page ncessite un temps de traitement trs im-
portant. Une faute de page pouvant intervenir nimporte quand, il est ds lors impossible de prdire
le temps dexcution dune tche si la mmoire virtuelle est active.
Un systme temps rel doit donc viter dutiliser le concept de pagination tel quil existe dans les
OS standards.
Verrous/Smaphores
Nous verrons plus loin le concept de verrous et de smaphores. Les verrous servent protger une
ressource critique an dviter que deux tches ny accdent en mme temps. A titre dexemple,
un chier est une ressource critique pour laquelle il nest pas possible de voir deux tches y crire
des donnes en mme temps sous peine de corruption de chier. Lutilisation de verrous dans un
cadre temps rel pose le problme de linversion de priorit, que nous verrons galement plus loin.
Ce problme peut tre rsolu par diffrents algorithmes (hritage de priorit, priorit plafonne,
allocation de ressource base sur une pile) qui doivent tre implments dans le noyau. Les fonctions
daccs aux verrous et aux smaphores doivent donc tre adaptes pour pouvoir donner des garanties
sur le temps dexcution des tches.
Interruptions
Les interruptions sont gnres par les priphriques dun systme informatique. Un port de com-
munication peut ainsi per exemple signaler que des donnes sont prtes, et quune application peut
donc les rcuprer pour les traiter. Les interruptions sont gnralement traites de manire priori-
taire sur les autres tches. Le problme lie au temps rel vient du fait quil est en gnral impossible
de savoir quand ses interruptions peuvent survenir, ni quel sera leur frquence. An de grer tout de
mme les priphriques, trois alternatives peuvent tre proposes :
1. Toutes les interruptions peuvent tre masques, pour tre sr quaucune delle ne viendra
interfrer avec le droulement des tches. Linterfaage des priphriques est ainsi laiss au
soin des tches, qui doivent aller rgulirement vrier ltat des priphriques et agir en
consquence. Lobservation des priphriques se fait donc par scrutation, ce qui oblige le
processeur tre oisif lorsquil est en attente dune entre. De la puissance de calcul est
alors perdue chaque fois quune tche doit attendre quil se passe quelque chose sur un
priphrique.
2. Toutes les interruptions sont masques, lexception du timer. Une routine du noyau est alors
appele rgulirement et vrie ltat des diffrents priphriques. Si un priphrique voit son
tat modi, la routine averti alors la tche attendant les donnes y relatives. Cette approche
permet de grer les priphriques avec une tche priodique borne, qui peut sans autre tre
prise en compte lors des choix dordonnanement. Du temps est tout de mme perdu par la
scrutation active des priphriques par cette tche.
3. Une troisime alternative propose dautoriser les interruptions, mais de ne placer que du code
minimal dans les routines appeles. La routine du driver
1
appele par une interruption ny
fait que noter le fait quune interruption a t leve, et active la tche qui tait en attente
sur des donnes particulires. Ici une tche ayant besoin dattendre des donnes venant dun
port de communication sera mise en attente passive et permet de ne pas gaspiller du temps
processeur en excutant une boucle de scrutation. Le temps de gestion de linterruption par
la routine du driver est trs faible, et peut souvent tre nglig.
DMA
Le concept de DMA (Direct Memory Access) est un mcanisme permettant au processeur de dl-
guer un sous-systme le soin deffectuer un grand transfert de mmoire. Ceci permet au proces-
seur de continuer excuter des instructions pendant que le transfert seffectue. Bien que permettant
dacclrer le traitement global, ce mcanisme peut momentanment ralentir le cours dexcution
car le processeur doit partager le bus de donnes avec le contrleur DMA. Si la tche excute par le
processeur ncessite daccder la mmoire, un arbitrage doit se faire. Plusieurs solutions existent,
mais sortent du cadre de ce cours. Nous pouvons toutefois noter que ce problme ne doit pas tre
nglig lors de lestimation du temps dexcution dune tche.
1. Portion de code charge dans le noyau, et responsable de la bonne gestion dun priphrique.
1.3. SYSTME DEXPLOITATION 1.7
Mmoire cache
Pour terminer, les mmoires caches (ou antmmoires) ont t introduites dans les systmes infor-
matiques an dacclrer les accs mmoire. Une mmoire cache est insre entre le processeur et
la mmoire principale et contient un sous-ensemble des donnes prsentes en mmoire principale.
Etant plus petite et plus proche du processeur, son accs est nettement plus rapide, et le principe de
localit temporelle et spatiale permet de voir le temps dexcution des applications fondre. Laccs
une donne prsente en cache est donc trs rapide. Les tudes montrent que 80% des accs m-
moires sont trouvs en cache, et que seulement 20% ncessitent un accs la mmoire principale.
Le problme de la prdictibilit est quil est impossible de savoir exactement quels seront les accs
russi et lesquels seront des checs. Il est donc possible de borner le temps dexcution dune tche
lorsquil ny a pas de cache, ou que son accs a t dsactiv. Par contre, si une cache est utilise,
une borne pourrait tre donne en considrant que tous les accs sont des checs, ce qui donne-
rait une estimation totalement fausse. Il sagit du seul moyen dassurer une predictibilit exacte,
mais lerreur destimation est norme. Il est donc possible dtre un peu plus exible en usant de
statistiques concernant la probabilit de russite/chec des accs mmoires.
Comme nous venons de le voir, les facteurs dimpredictibilit sont nombreux, et peuvent aisment
conduire lobservation dun systme fonctionnant parfaitement le 99% du temps et se retrouvant
soudainement dans un tat non grable. Ces facteurs doivent donc tre nement analyss lors de la
mise au point dune application temps rel.
1.3 Systme dexploitation
Un systme temps rel peut tre mis en place via un systme dexploitation ou non. Sans systme
dexploitation, il est possible de disposer dun excutif (ou moniteur) temps rel, qui est une sorte
de micro-noyau. Cet excutif est responsable de lordonnanement des tches (ordre dans lequel
elles sexcutent), les tches soccupant de leur traitement propre. Cette solution peut tre adapte
des systmes embarqus dont la fonctionnalit est trs spcique et peu soumise modication.
Dans des systmes plus importants, il est agrable de disposer des facilits proposes par un systme
dexploitation, tels quune interface utilisateur ou la gestion de chiers, par exemple. Un systme
dexploitation doit par contre tre spciquement conu pour le temps rel. Il est en effet impossible
de faire fonctionner une application temps rel strict sur un systme dexploitation standard. Ceci
est notamment en partie d aux facteurs dimprdictibilit cits prcdemment. Il existe plusieurs
systmes dexploitation temps rel, propritaires ou open source. Dans le cadre de ce cours, nous
utiliserons Xenomai [1], qui est un noyau temps rel quil est possible dadjoindre un Linux
standard. Les applications temps rel peuvent alors tre gres correctement par Xenomai, tandis
que les applications standards son excutes dans le contexte Linux.
1.4 Temps rel strict vs. souple
En fonction de la nature des contraintes temporelles appliques un systme temps rel, celui-ci
peut tre de deux types :
Temps rel strict ou dur (hard). Il sagit dun systme o lensemble des contraintes temporelles
doit absolument tre respect. Pour ce faire il faut pouvoir dnir les conditions de fonctionne-
ment du systme, cest--dire connatre parfaitement lenvironnement du systme. Il faut ga-
lement tre capable de garantir la abilit du systme avant son excution. Tous les scnarios
possibles dexcution doivent donc tre tudis et le bon fonctionnement du systme doit tre
garanti pour chacun de ces scnarios. Lensemble du systme doit videmment tre sufsamment
connu pour pouvoir fournir de telles garanties.
A titre dexemple, le contrle dun avion par un pilote automatique est un systme temps rel
strict.
Il existe galement des systmes appels temps rel ferme (rm), o la pertinence du rsultat est
nulle passe lchance, mais dont le non respect de lchance ne compromet pas le fonctionne-
ment du systme ou lintgrit des personnes. Une application bancaire responsable de calculer
des risques en fonction des paramtres courants du march en est un exemple.
Temps rel souple ou mou (soft). Les systmes temps rel souple ont des contraintes de temps
moins exigeantes que les prcdents. Une faute temporelle ny est pas catastrophique pour le
fonctionnement. Un tel systme pourra donc accepter un certain nombre de fautes temporelles,
tout en pouvant continuer son excution.
Atitre dexemple, les applications de type multimdia telles que la tlphonie ou la vido sont des
applications temps rel souple, car la perte de certaines informations, lie un dbit trop faible,
nest pas dangereux ou catastrophique. Les systmes de ce type peuvent ensuite tre compars
en fonction de la qualit de service quils offrent, en termes de probabilit derreur.
La gure 1.2 rsume la valeur dun calcul en fonction de son instant darrive. Dans le cas dune
chance stricte ou rme, pass lchance, le calcul na plus aucune valeur. La diffrence entre
ces deux cas vient du fait quune chance stricte manque met en pril le systme, alors quune
chance rme manque implique uniquement que le rsultat du calcul nest plus pertinent. Dans
le cas dune chance molle, la pertinence du rsultat perd de sa valeur aprs lchance, mais ce
dune manire plus douce.
Valeur
Temps
chance
(a) Echance stricte
Valeur
Temps
chance
(b) Echance ferme
Valeur
Temps
chance
(c) Echance molle
Figure 1.2 Valeur du calcul en fonction du temps
Chapitre 2
Introduction aux tches
2.1 Quest-ce quune tche ?
E
N PROGRAMMATION squentielle, un programme est dcompos en sous-programmes
(procdures ou fonctions). Chaque sous-programme correspond une suite dinstruc-
tions, et lexcution du programme voit ces instructions tre excutes les unes la suite
des autres. Il est en gnral possible de raliser une application en une seule tche, mais
la scrutation de priphriques risque dy tre dlicate et coteuse en temps processeur.
Un systme temps rel est toujours dcompos en tches, chacune ayant des fonctionnalits, des
temps dexcution et des chances diffrentes. Il serait parfois possible de les combiner en une
seule tche, mais cet exercice nest pas souhait, notamment cause du contrle plus dlicat sur les
parties dexcution que ceci impliquerait.
Considrons un simple systme compos de deux entres (un port srie et un clavier), dune partie
de traitement, et dune sortie. Dans un contexte temps rel, le port srie doit tre scann rgulire-
ment an dviter quun octet ne soit perdu. Si la tche de traitement est consquente, il faudrait, en
milieu de traitement, aller vrier ltat du port srie, sans oubli la gestion du clavier. Il faudrait
galement faire de mme si la transmission vers la sortie est lente. Dans un tel cas, la dcompo-
sition du systme en tches distinctes permet dviter ces inconvnients. Nous pouvons imaginer
une tche responsable de lire les donnes venant du port srie, et ce une cadence garantissant le
respect des chances visant ne pas perdre doctet. Une autre tche serait responsable de la gestion
du clavier, une autre du traitement, et enn une dernire de la gestion de la sortie. Des mcanismes
de communication peuvent tre mis en oeuvre pour permettre aux diffrentes tche de schanger
des donnes, et des priorits peuvent tre assignes, notamment pour garantir que le port srie est
bien gr.
Les systmes temps rel tant gnralement bass sur une architecture relativement semblable
cet exemple, nous traiterons donc de systmes multi-tches. A lheure actuelle, les systmes infor-
matiques sont multi-tches, et supportent lexcution pseudo-parallle de plusieurs tches. Ceci a
t rendu possible par la mise au point de systmes dexploitation nettement plus complexes. Un
processeur peut donc voir plusieurs tches en cours dexcution se partager le temps de traitement.
Dans le cadre dune application particulire, il est ds lors possible davoir, par exemple, une tche
responsable dexcuter un calcul lourd pendant quun autre gre les interactions avec lutilisateur. Il
est intressant de noter que le concept de programmation multi-tches est autant valable sur un pro-
cesseur simple coeur que sur un multi-coeur. Sur un simple coeur, les parties de tches sexcutent
tour tour de manire transparente, et sur un multi-coeur, un rel paralllisme peut tre observ,
2.2 CHAPITRE 2. INTRODUCTION AUX TCHES
chaque coeur pouvant excuter un ensemble de tches.
2.2 Anatomie dune tche
Un processus correspond un chier excutable en cours dexcution sur un processeur. Il est
entre autre caractris par un code (le programme excuter), une pile et un tas qui permettent de
stocker les donnes ncessaires son bon fonctionnement, un identiant unique, et une priorit. La
priorit permet au systme dexploitation de grer plusieurs processus en cours dexcution sur un
processeur, un processus plus haute priorit se voyant attribuer un temps dutilisation processeur
plus important.
Un processus peut galement tre dcompos en tches (threads ou ls dexcution), chaque tche
tant une sorte de processus lger. Dans ce cours, nous utiliserons le terme de tche pour dsi-
gner une suite dinstructions squentielles correspondant une tche. Toutefois, les notions dor-
donnancement introduites dans le chapitre correspondant peuvent tre aussi bien appliques des
processus.
La gure 2.1 illustre la dcomposition de lespace dadressage dun processus en trois parties prin-
cipales :
Le code contenant les instructions du programme (text segment en anglais).
Les variables globales et les variables alloues dynamiquement (data segment en anglais).
La pile, o les variables locales de ses sous-programmes, ainsi que diverses informations tempo-
raires ayant une dure de vie gale au sous-programme sont stockes (stack segment en anglais).
Figure 2.1 Espace dadressage dun processus
datasegment
stacksegment
textsegment
(code)
Espaced'adressage
Processus
Un processus, dans un cadre multi-tche, est dcompos en deux parties :
La premire contenant les ressources globales, telles que les instructions du programme et les
variables globales. Cette partie correspond au processus. Il sagit des deux premiers points de
lespace dadressage.
2.3. AVANTAGES DU MULTI-TCHE 2.3
La deuxime contenant des informations lies ltat dexcution, telles que le compteur de
programme (aussi appel compteur ordinal) et la pile dexcution. Cette partie correspond une
tche. Il est noter que chaque tche possde un compteur de programme et une pile. Il sagit de
la partie lie la tche.
Etant donn que les tches dun mme processus partagent le mme espace dadressage, une
tche peut facilement corrompre les donnes utilises par une autre tche. Des outils de syn-
chronisation permettent toutefois dliminer les risques de ces corruptions, sils sont utiliss de
manire approprie.
Toujours li au partage de lespace dadressage, si une tche effectue un accs mmoire erron
fatal, le processus entier risque de se terminer. Ce nest videmment pas le cas pour un systme
plusieurs processus.
Une tche est li un programme particulier, et ne peut donc pas tre lanc par un autre pro-
gramme. Les processus peuvent en revanche tre lanc par un autre processus, et donc tre plus
aisment rutiliss.
2.3 Avantages du multi-tche
En comparaison dun programme ne contenant quune seule tche, un programme dcompos en
tches permet de mieux grer les entres/sorties et le calcul. Une tche peut soccuper du calcul,
tandis que dautres grent les entres/sorties. De ce fait, lusage dun GUI (Graphical User Interface)
est plus ergonomique et convivial. Prenons lexemple dune application visant afcher la courbe
de Mandelbrot. Pour chaque point de limage, une grande quantit de calcul doit tre effectue.
Supposons que lutilisateur peut cliquer sur des boutons pour zoomer. Si nous ne disposons pas de
multi-tche, un clique sur le bouton va ensuite voir lapplication se bloquer pendant que la nouvelle
image est calcule. Si par contre nous disposons de plusieurs tches, une tche peut soccuper du
calcul pendant que lautre gre linterface graphique. Ds lors lutilisateur a encore la possibilit
dinteragir avec lapplication sans devoir souffrir de laccaparement du processeur pour le calcul.
Dans le cas dun processeur multi-coeur, un autre avantage du multi-tche peut sexploiter. En effet,
chaque coeur peut prendre en charge un ou plusieurs tches. En reprenant lexemple de Mandelbrot,
si nous supposons que nous sommes en prsence dun dual-core, alors nous pouvons dcomposer
notre calcul en deux tches, chacune tant responsable de la gnration de la moiti de limage.
Lorsque lutilisateur clique sur le bouton, la nouvelle image pourra donc safcher en un temps
rduit de moiti. Il sagit l dun paralllisme rel, rendu possible par lamlioration des plateformes
matrielles proposes sur le march. Nous pouvons toutefois noter que lacclration dun facteur
n pour un n-core reste thorique, la probable communication inter-tche imposant une perte en
performance.
En comparaison dun systme multi-processus, une application multi-tche requiert une surcharge
(overhead) moindre pour la gestion des tches. En effet, commuter dune tche une autre est
nettement moins coteux en terme de temps processeur que de commuter dun processus un
autre. Un avantage dune application multi-processus est la possibilit dexcuter les processus sur
des machines diffrentes, ce qui nest pas le cas du multi-tche. Pour ce qui est de la commutation,
le responsable de son fonctionnement, dans les deux cas, est le systme dexploitation.
La table suivante (tire de [9]) liste les avantages et les inconvnients du multi-tche par opposition
au multi-processing :
Figure 2.2 Espace dadressage dun processus multi-tche
pthread_tthreadA;
pthread_tthreadB;
intx;
inty;
voidfonctionA(void*p)
{
inti=100;
}
voidfonctionB(void*p)
{
inti=10;
}
main()
{
pthread_create(&threadA,NULL,fonctionA,NULL);
pthread_create(&threadB,NULL,fonctionB,NULL);
...
}
Espaced'adressage
Processus
stacksegment
datasegment
textsegment
fonctionA()
i=100
main()
ThreadA
threadB
x
y
PileduthreadA
Registres
________
SP
PC
...
Attributs
________
priorit=2
taille=...
...
ThreadID
________
212
threadA
fonctionB()
i=10
PileduthreadB
Registres
________
SP
PC
...
Attributs
________
priorit=2
taille=...
...
ThreadID
________
315
threadB
2.4. TCHES DANS UN CONTEXTE TEMPS REL 2.5
Avantage des tches Dsavantages des tches
Moins de ressources ncessaires lors dun chan-
gement de contexte
Requiert des mcanismes de synchronisation lors
daccs mmoires concurrents
Amliore le dbit de traitement des donnes dans
une application
Peut facilement polluer lespace dadressage du
processus
Ne ncessite pas de mcanismes spciaux de
communication entre tches
Nexiste que dans un processus, et nest donc pas
rutilisable
Permet de simplier la structure dun programme
Dans le cadre de systmes temps rel, un autre avantage du multi-tche est la possibilit de mieux
grer les chances et priodes des tches. Nous reviendrons sur ces notions dans le chapitre sur
lordonnancement.
2.4 Tches dans un contexte temps rel
2.4.1 Cycle de vie
La gure 2.3 illustre les diffrentes tapes de la vie dune tche, dans un contexte temps rel. Ltat
initial dune tche est inexistante. Aprs sa cration, elle passe ltat passive lorsque toutes les
ressources son bon fonctionnement ont t rquisitionnes. Elle reste dans cet tat jusqu tre
rveille, ce qui peut nest fait quune seule fois pour une tche apriodique, ou de manire rpte
pour une tche priodique. Aprs le rveil, elle se trouve dans ltat prte, o elle se retrouve en
comptition avec les autres tches disposes tre excutes. Lordonnanceur a alors la charge de
choisir les tches activer. De ltat prte, le systme dexploitation peut ensuite la faire passer
dans ltat lue, tat dans lequel la tche sexcute.
Figure 2.3 Etats et transitions dune tche dans un contexte temps rel.
non existante
passive
lue
prte
bloque
termine
cration
requte
excution
premption
faute temp.
terminaison requte
premption
attente
terminaison
faute temporelle
rveil
Ce passage nest pas du ressort de la tche, mais bien de lordonnanceur, qui soccupe dallouer
le processeur aux diffrentes tches concurrentes, et ce en suivant la politique dordonnancement
choisie. A tout instant lordonnanceur peut replacer la tche dans ltat prte, pour laisser une autre
tche sexcuter. Il sagit de la premption dune tche, qui se fait sans que la tche prempte
nen soit consciente. Depuis ltat lue, la tche peut aussi se retrouver dans ltat bloque, lors
de lattente dun vnement ou du relchement dun mutex, par exemple. La tche ressort de cet
tat par son rveil suite au relchement dun mutex ou au fait quun vnement sur lequel la tche
attend a t dclench. Dans ce cas, la tche passe ltat prte, prte continuer son excution.
Lorsque la tche sexcute, elle peut se terminer, et se retrouver dans ltat de terminaison. Elle
peut galement terminer une occurence, et passer dans ltat passive, si elle est priodique. Il est
intressant de noter que des fautes temporelles peuvent survenir, la tche nayant pas termin son
traitement temps. Ceci peut faire passer la tche de ltat lue ou prte ltat passive. Elle y
restera ensuite jusqu une nouvelle requte, pour le cas o elle est priodique.
2.4.2 Taxonomie
Les tches sont divises en deux grandes catgories, en fonction de leur priodicit.
Les tches priodiques (ou cycliques) sont des tches qui sont excutes intervalles rguliers.
Elles sont entre autre dnies par la priode avec laquelle elles sont censes sexcuter, ce qui est
gr par lordonnanceur.
Une tche priodique peut par exemple tre responsable de lobservation dun capteur inter-
valles rguliers, de la rgulation de moteurs, de monitoring, etc.
Les tches apriodiques sont, quant elles, excutes intervalles irrguliers, et peuvent donc
survenir nimporte quel instant. Il sagira typiquemenent de tches de conguration, et de tches
actives par une alarme, ou par une entre de lutilisateur. Les interruptions jouent un rle impor-
tant, tant le principal vecteur dactivation.
Une tche est dite sporadique si elle est apriodique et que lintervalle minimal entre deux acti-
vations est connu.
Au niveau de linteraction entre tches, nous pouvons distinguer :
Les tches indpendantes, dont lordre dexcution peut tre quelconque.
Les tches dpendantes, pour lesquelles il existe des contraintes de prcdence. Il sagit de cas
o une tche doit attendre quune autre ait termin son traitement pour pouvoir commencer le
sien.
Au niveau des politiques dordonnancement, il est clair que les dpendances entre tches auront un
rle crucial et devront tre prises en compte de manire judicieuse.
2.4.3 Paramtres dune tche
La dnition dune tche est videmment fortement lie au programme dcrivant son excution.
Toutefois, dans le cadre de lordonnancement de systmes temps rel, diffrents paramtres sont
galement ncessaires la mise au point de solutions correctes.
Les paramtres dune tche T sont :
r : la date de rveil de la tche (ou date de demande dactivation)
C : sa dure dexcution, calcule en temps processeur. Il sagit du pire temps dexcution.
D : son dlai critique, au-del duquel le rsultat est jug comme tant non pertinent
P : sa priode, pour le cas dune tche priodique
d : pour une tche contraintes strictes, son chance, calcule comme tant d = r +D
s : date de dbut dexcution de la tche
f : date de n dexcution de la tche
u =
C
P
: son facteur dutilisation du processeur
ch =
C
D
: son facteur de charge du processeur
2.4. TCHES DANS UN CONTEXTE TEMPS REL 2.7
L = D C : sa laxit nominal. Indique le retard maximum que peut prendre la tche sans
dpasser son chance
D(t) = d t : son dlais critique rsiduel au temps t
C(t) : sa dure dexcution rsiduelle au temps t
L(t) = D(t) C(t) : sa laxit rsiduelle au temps t
TR = f r : son temps de rponse. Lchance est respecte si tr D
Nous pouvons noter les proprits suivantes :
u 1
ch 1
0 D(t) D
0 C(t) C
L(t) = D(t) C(t) = D +r t C(t)
Une tche apriodique est donc reprsente par le tuple T(r, C, D), alors quune tche priodique
lest par le tuple T(r
0
, C, D), r
0
tant la date de rveil de la premire occurence.
Un tche chance sur requte est une tche priodique pour laquelle le dlai critique est gal la
priode (D = P).
La gure 2.4 illustre ces diffrents paramtres. Dans les diagrammes temporels utiliss, nous no-
terons loccurence dun rveil de tche laide dune che pointant vers le haut, lchance de la
tche tant reprsente par une che pointant vers le bas.
Figure 2.4 Paramtres typiques dune tche T
i
.
T
i
C
i
r
i
s
i
f
i
d
i
La gure 2.5 montre les paramtres dune tche priodique, et la gure 2.6 illustre les caractris-
tiques dune tche priodique chance sur requte, o la priode est gale au dlai critique.
Figure 2.5 Paramtres typiques dune tche priodique T.
T
C
D
P
r
0
s
0
f
0
d
0
C
D
P
r
1
s
1
f
1
d
1
r
2
Figure 2.6 Paramtres typiques dune tche priodique chance sur requte T.
T
C
D = P
r
0
s
0
f
0
C
D = P
r
1
s
1
f
1
r
2
2.5 Ordonnancement non temps rel
Tout systme dexploitation dispose dun ordonnanceur, qui a pour fonction de rpartir lutilisation
du processeur entre les diffrentes tches demandeuses. Diverses solutions existent, et peuvent tre
classes en fonction de diffrents paramtres. La section suivante propose une taxonomie des algo-
rithmes dordonnancement. La section 2.6 vise dnir les moyens de calcul des performances des
algorithmes, et la section 2.7 introduit plusieurs algorithmes dordonnancement classiques, au sens
o ils sont utiliss dans des systmes nayant pas recours des contraintes temps rel.
Dnition 2.1. faisabilit
Un ensemble de tches est dit faisable sil est possible den proposer un ordonnancement respectant
lensemble des contraintes de temps imposes.
2.5.1 Taxonomie
Les algorithmes dordonnancement peuvent tre catgoriss selon les critres suivants (inspir de
[10]) :
Monoprocesseur/multiprocesseur
Larchitecture physique du systme a une inuence sur la manire dagencer les tches. Certains
algorithmes ne peuvent tre appliqus quau des systmes monoprocesseur (ordonnancement mo-
noprocesseur), alors que dautres se destinent des systmes multi-processeur (ordonnancement
multiprocesseur). Dans le cadre de ce cours, nous ne traiterons que les algorithmes monoproces-
seur.
Premptif/non-premptif
La premption consiste en le fait quune tche peut tre interrompue son insu pour cder sa place
une autre tche. Les algorithmes premptifs traitent donc des systmes o les tches peuvent
tre premptes (cf. gure 2.8), tandis que les algorithmes non-premptifs traitent de ceux dont
une tche ayant commenc son traitement doit obligatoirement le terminer avant quune autre ne
sexcute (cf. 2.7).
Figure 2.7 Exemple dordonnancement sans premption
T
0
T
1
T
2
Figure 2.8 Exemple dordonnancement avec premption
T
0
T
1
T
2
2.6. CALCUL DE PERFORMANCE 2.9
La possibilit de premption permet notamment dviter que le processeur ne soit occup trop
longtemps par une tche, ce qui pourrait empcher une autre tche de se terminer temps. Cette
exibilit a toutefois un cot li au temps ncessaire pour le changement de contexte dune tche
lautre. Ce cot peut tre intolrable suivant lapplication, et donc un choix doit tre fait, pour un
systme particulier, de partir sur une solution avec ou sans premption (cf. [14]).
En-ligne/hors-ligne (online/ofine)
Un ordonnancement hors-ligne est effectu avant le lancement du systme. Ceci implique que tous
les paramtres des tches soient connus a priori, et notamment les dates dactivation. Limplmenta-
tion du systme est alors trs simple : il suft de stocker lidentiant de la tche effectuer chaque
moment dordonnancement dans une table, lordonnanceur exploitant ensuite cette information pour
slectionner la tche excuter. Le dsavantage de cette approche est la grande dpendance au sys-
tme cible, par contre lanalyse hors-ligne permet une meilleure prdiction de la satisfaction ou non
des contraintes temporelles. De mme, la puissance de calcul disponible hors-ligne permet de cal-
culer un ordonnancement optimal, ce qui est un problme NP-complet, tche impossible raliser
dans un systme embarqu.
Un ordonnancement en-ligne est effectu durant le fonctionnement du systme. Lordonnanceur
recalcule un nouvel ordonnancement chaque fois quune nouvelle tche est active. Lavantage de
cette approche est la exibilit, et ladaptabilit lenvironnement que procure le calcul en-ligne.
Par contre, ce calcul devant tre excut par le systme, qui est temps rel, il doit tre le plus simple
et rapide possible, rendant impossible une solution dite optimale. Diffrents algorithmes permettent
de rsoudre ceci, notamment en utilisant des heuristiques.
Statique/dynamique
Un ordonnancement est dit statique sil est uniquement bas sur les proprits des tches avant le
lancement du systme. Un ordonnancement est dynamique sil est capable de ragir la modica-
tion des proprits des tches durant le fonctionnement du systme (typiquement un changement de
priorit).
Optimal/non optimal
Un algorithme dordonnancement est dit optimal sil est capable de fournir un ordonnancement qui
respecte toutes les contraintes de temps si un tel ordonnancement existe. Si un algorithme optimal
nest pas capable de trouver un ordonnancement correct, aucun autre algorithme ne le pourra. Un
algorithme non optimal (ou heuristique, ou best effort) na pas la prtention dtre optimal, mais
doit faire de son mieux pour fournir un ordonnancement le plus proche possible de loptimal.
2.6 Calcul de performance
Comment calculer lefcatit dun algorithme dordonnancement ? La question est dlicate et peut
conduire plusieurs rponses. Il faut en effet dnir le facteur valuer. Le tableau 2.1 donne des
fonctions de cot qui peuvent tre exploites pour la comparaison des algorithmes.
Nom Fonction
Temps de rponse moyen t
r
=
1
n
n
i=1
(f
i
r
i
)
Temps dexcution total t
c
= max
i
(f
i
) min
i
(r
i
)
Somme pondre des n dexcution t
w
=

n
i=1
w
i
f
i
Maximum lateness L
max
= max
i
(f
i
d
i
)
Nombre maximum de tche en retard N
late
=

n
i=1
miss(f
i
)
miss(f
i
) =
_
0 si f
i
d
i
1sinon
Tableau 2.1 Fonctions de cot pour valuation des performances.
2.7 Ordonnancements classiques
Comme dj mentionn, un systme dexploitation classique contient un ordonnanceur responsable
de rpartir le temps CPU entre les diffrentes tches prsentes dans le systme. Nous prsentons ici
quelques algorithmes dordonnancement, et nous traiterons des algorithmes spciques au temps
rel dans le chapitre 3.
2.7.1 Algorithmes non premptifs
Les algorithmes non premptifs sont appliqus lorsque les tches ne peuvent tre premptes, cest-
-dire o une tche ayant commenc son excution doit forcment la terminer avant quune autre
tche ne puisse dbuter.
Premier arriv premier servi
Cet algorithme fonctionne de la manire la plus simple qui soit. Les tches sont stockes dans une
structure de type FIFO, la premire tche est excute, et lorsquelle termine, la suivante est lance.
Les tches nouvellement actives sont stockes la n de la le dattente.
La gure 2.9 illustre le concept de cet ordonnancement. Nous pouvons noter que les tches T
1
et T
2
doivent attendre un temps important que la tche T
0
se termine.
shortest job rst
An dviter que des tches courtes ne doivent attendre trop longtemps sur des tches longues, il
est possible dappliquer un algorithme o la tche la plus courte est servie en premier. De ce fait,
les tches courtes sont favorises, et le temps dattente moyen est minimis. Un des problmes
de cette approche est le risque de famine des tches longues. Si de nouvelles tches courtes son
rgulirement rveilles, il se peut quelles passent toujours devant une tche longue, empchant
ainsi celle-ci de sexcuter.
La gure 2.10 illustre le fonctionnement de cet algorithme.
2.7. ORDONNANCEMENTS CLASSIQUES 2.11
Figure 2.9 Exemple dordonnancement premier arriv premier servi
Tche Cot Arrive
T
0
8 1
T
1
2 2
T
2
4 4
T
0
0 5 10 15
T
1
T
2
Figure 2.10 Exemple dordonnancement plus court dabord
Tche Cot Arrive
T
0
8 0
T
1
2 0
T
2
4 0
T
0
0 5 10 15
T
1
T
2
2.7.2 Algorithmes premptifs
Dans le cadre premptif, une tche peut tre momentanment interrompue par lordonnanceur an
de laisser une autre tche sexcuter. De ce fait, une tche trs longue na plus de risque de bloquer
des tches plus courtes trop longtemps.
Round robin/tourniquet
Lalgorithme du tourniquet (round robin en anglais) vise traiter les tches avec le plus dquit
possible, en allouant un quantum de temps identique toutes les tches, et les traiter dans un ordre
FIFO. Les tches sont places dans une le dattente, et la premire de la le est excute pendant
un quantum de temps. A la n de ce quantum, si la tche nest pas termine, elle est replace la
n de la le et une nouvelle tche est slectionne depuis le dbut de la le. Si la le est vide, la
tche peut continuer son excution.
La gure 2.11 illustre cet algorithme, avec un quantum de temps gal 2. Nous pouvons noter que la
tche T
0
garde laccs au processeur lorsquelle se retrouve tre la seule en cours dexcution. Il ny
a donc pas de changement de contexte si ceci nest pas ncessaire. Cette technique de tourniquet
correspond la politique standard observe dans les systmes dexploitation, car elle permet
toutes les tches de sexcuter sans risque de famine. Nous pouvons toutefois noter quil sagira
dune variante avec priorit.
Figure 2.11 Exemple dordonnancement tourniquet
Tche Cot Arrive
T
0
8 0
T
1
2 1
T
2
4 3
T
0
0 5 10 15
T
1
T
2
Priorit xe
Lalgorithme du tourniquet traite toutes les tches sur le mme pied dgalit. Hors il est souvent
ncessaire de dnir des priorits entre tches, an par exemple de garantir que la lecture dun
chier audio se fasse de manire uide, mme lorsquune compilation est en cours. Lalgorithme
priorit xe fonctionne comme celui du tourniquet lintrieur dune priorit, et les priorits sont
traites dans lordre. Les tches dune priorit particulire y sont traites selon un tourniquet, pour
autant quaucune tche de plus haute priorit ne soit prte tre excute.
La gure 2.12 illustre cet algorithme, avec un quantum de temps gal 2. Nous pouvons noter que
la tche T
1
, la plus prioritaire, est excute au dpart, puis un tourniquet est effectu pour les deux
autres tches. Cette technique de tourniquet priorit correspond la politique standard observe
dans les systmes dexploitation, car elle permet toutes les tches de sexcuter sans risque de
famine.
Earliest deadline rst
Lalgorithme Earliest Deadline First (EDF) donne la priorit la tche ayant lchance la plus
proche. A chaque fois quune tche est rveille, lordonnanceur rvalue les tches prtes et slec-
tionne celle ayant lchance la plus courte.
La gure 2.13 illustre cet algorithme. Nous reviendrons sur lalgorithme EDF dans le chapitre sui-
vant, tant donn quil sagit dune des politiques dordonnancement les plus utilises.
2.7. ORDONNANCEMENTS CLASSIQUES 2.13
Figure 2.12 Exemple dordonnancement tourniquet avec priorit
Tche Cot Priorit Arrive
T
0
6 1 0
T
1
6 2 0
T
2
4 1 0
T
0
0 5 10 15
T
1
T
2
Figure 2.13 Exemple dordonnancement EDF
Tche Cot Echance Arrive
T
0
6 12 0
T
1
4 8 2
T
2
2 5 3
T
0
0 5 10 15
T
1
T
2
Chapitre 3
Algorithmes dordonnanement temps rel
pour tches priodiques
3.1 Introduction
L
E PROBLME fondamental en programmation concurrente est celui de garantir le respect
des chances des diffrentes tches le constituant. Il existe en outre un grand nombre
de manire dordonnancer un ensemble de tches, et ce notamment en fonction des ca-
ractristiques de celles-ci. Elles peuvent tre indpendantes, dpendantes, priodiques,
apriodiques, elles peuvent partager ou non des ressources, et changer ou non des informations.
Dans ce chapitre, nous nous intressons au cas de tches purement priodiques.
Dans nombre de systmes temps rel, certaines tches doivent sexcuter de manire rpte,
intervalles rguliers. Il pourra par exemple sagir dune tche charge daller vrier la valeur dun
capteur tous les diximes de seconde. Ces tches sont appeles tches priodiques, puisquelles
doivent sexcuter rgulirement, en suivant une priode xe.
Pour la mise au point des algorithmes dordonnancement dans le cadre des tches priodiques, nous
utiliserons la notation suivante :
Variable Description
Un ensemble de tches priodiques
i
Une tche priodique gnrique
i,j
La j
me
instance de la tche priodique
i
r
i,j
Le temps darrive de la j
me
instance de la tche priodique
i
i
Le dphasage de la tche
i
; il sagit du temps darrive de
i,0
(
i
= r
i,0
)
D
i
Echance relative de la tche
i
d
i,j
Echance absolue de la j
me
instance de la tche
i
(d
i,j
=
i
+ (j 1)T
i
+D
i
)
s
i,j
Temps de dbut dexcution de la j
me
instance de la tche
i
f
i,j
Temps de n dexcution de la j
me
instance de la tche
i
Dans la suite de ce chapitre, nous allons en outre faire les hypothses suivantes :
3.2 CHAPITRE 3. ALGORITHMES DORDONNANEMENT TEMPS REL POUR TCHES PRIODIQUES
Hypothse
H1 Les instances dune tche priodique sont actives avec une priode constante
H2 Toutes les instances dune tche ont le mme pire temps dexcution C
i
H3 Toutes les instances dune tche ont la mme chance relative D
i
H4 Toutes les tches sont indpendantes. Il ny a pas de dpendances entre tches
H5 Une tche ne peut se suspendre elle-mme
H6 La surcharge lie aux oprations du noyau est nglige
Nous traiterons ultrieurement les systmes o lhypothse H4 nest pas vrie.
Dans le cas des tches chance sur requte, nous pouvons calculer les temps darrive des tches,
ainsi que leurs chances respectives de cette manire :
r
i,j
=
i
+ (j 1)P
i
(3.1)
d
i,j
= r
i,j
+P
i
=
i
+jP
i
(3.2)
Une tche est dite faisable si toutes ses instances peuvent se terminer en respectant leur chance.
Lensemble des tches ordonnancer est dit ordonnanable (ou faisable) si toutes ses tches de
sont faisables.
3.1.1 Gigue
La gigue observe peut ltre sur diffrentes variables du systme. Nous pouvons dnir les gigues
suivantes :
La gigue de release relative (Relative Release Jitter) dune tche est la dviation maximale des
temps de dmarrage de deux instances conscutives :
RRJ
i
= max
j
|(s
i,j
r
i,j
) (s
i,j1
r
i,j1
)| (3.3)
La gigue de release absolue (Absolute Release Jitter) dune tche est la dviation maximale des
temps de dpart sur toutes les instances :
ARJ
i
= max
j
(s
i,j
r
i,j
) min
j
(s
i,j
r
i,j
) (3.4)
La gigue de n relative (Relative Finishing Jitter) dune tche est la dviation maximale des
temps de n de deux instances conscutives :
RFJ
i
= max
j
|(f
i,j
r
i,j
) (f
i,j1
r
i,j1
)| (3.5)
La gigue de n absolue (Absolute Finishing Jitter) dune tche est la dviation maximale des
temps de n sur toutes les instances :
AFJ
i
= max
j
(f
i,j
r
i,j
) min
j
(f
i,j
r
i,j
) (3.6)
3.1. INTRODUCTION 3.3
3.1.2 Priode dtude
Les ordonnancements de ce chapitre son ddis aux ensembles de tches priodiques. Le fonction-
nement complet du systme est donc cyclique. Lalgorithme dordonnancement doit trouver une
squence de tches, valable sur toute la dure de fonctionnement du systme. Cette squence est
toutefois caractrise par une priodicit de longueur L, tant donn que les tches sont priodiques.
La priode de longueur L est appele priode dtude, ou priode de base.
Pour un ensemble de tches priodiques synchrones (qui dbutent toutes linstant 0), la priode
dtude est :
L = [0, PPCM(P
i
)] (3.7)
O le PPCM dnote le plus petit multiple commun des priodes des tches. Ds lors, si les tches
sont ordonnanables sur la priode dtude, nous pouvons garantir quelles le seront pour un temps
inni, tant donn que lordonnancement pourra tre calcul en rptant la squence de tches
trouve sur cette priode dtude. La priode dtude peut toutefois savrer trs longue, suivant les
relations entre les priodes.
Pour des tches asynchrones, ne dbutant donc pas au mme instant, la priode dtude est :
L = [min{r
i,0
}, 2 PPCM(P
i
) + max{r
i,0
]} (3.8)
O r
i,0
est la date dactivation de la premire occurence de la tche priodique T
i
Et enn, en prsence de tches apriodiques, la priode dtude devient :
L = [min{r
i,0
}, 2 PPCM(P
i
) + max{r
i,0
, r
j
+D
j
}] (3.9)
O r
j
est la date dactivation de la tche apriodique T
j
, et o D
i
est son chance relative.
3.1.3 Taux dutilisation du processeur
Pour un ensemble de n tches priodiques , le facteur doccupation du processeur est la fraction
de temps processeur ncessaire lexcution de cet ensemble de tches. Pour une tche
i
, le facteur
doccupation est dni par :
u
i
=
C
i
P
i
(3.10)
Pour lensemble des tches , le facteur dutilisation est ds lors :
U =
n
i=1
C
i
P
i
(3.11)
Ce facteur U correspond la charge applique par lensemble des tches sur le processeur. Il est
vident que la charge maximale ne doit pas dpasser 1, sans quoi le processeur nest pas mme
dexcuter lensemble des tches.
U =
n
i=1
C
i
P
i
1 (3.12)
U, qui doit donc tre plus petit que 1, dpend en outre des caractristiques des tches, ainsi que de
lalgorithme dordonnancement utilis pour les ordonnancer. Pour un algorithme A particulier et
un ensemble de tches , il existe une valeur U
ub
(, A) au-del de laquelle les tches ne sont pas
ordonnanables. U
ub
est la limite maximale dutilisation du processeur (Upper Bound).
Si U = U
ub
(, A), alors lensemble utilise entirement le processeur. Une petite modication de
peut ds lors faire dpasser cette limite et rendre lensemble des tches non ordonnanable. Pour
un algorithme A donn, nous pouvons dnir la valeur minimale des U
ub
(Least Upper Bound) :
U
lub
(A) = min
U
ub
(, A) (3.13)
De ce fait, un ensemble de tches est ordonnanable si son facteur dutilisation du processeur est
infrieur cette limite minimale :
U
=
n
i=1
C
i
P
i
U
lub
(A) = min
U
ub
(, A) est ordonnanable (3.14)
La gure 3.1 reprsente, pour un algorithme donn, lordonnanabilit de quatre ensembles de
tches. Si le facteur dutilisation du processeur est infrieur ou gal la limite minimale, alors
lensemble est ordonnanable (
3
), sil est suprieur 1 il nest pas ordonnanable (
3
), et sinon
un test supplmentaire est ncessaire pour tablir son ordonnanabilit (
1
, et
2
).
Figure 3.1 Signication du Least Upper Bound
U
1
U
2
U
3
U
4
Ordonnanable ?
Oui Peut-tre Non
0 U
lub
1
3.2 Rate Monotonic
Lalgorithme Rate Monotonic est un algorithme statique, applicable un ensemble de tches
chance sur requte, o les priorits des tches sont xes et dcide avant le lancement du systme.
La priorit des tches est xe en fonction de leur priode dactivation. Plus une tche a une petite
priode dactivation, plus sa priorit sera haute. Il sagit dun algorithme premptif, lactivation
dune tche de petite priode devant permettre la premption dune tche de priode plus grande.
Cet algorithme est optimal dans le cas des priorits xes, pour .
La gure 3.2 montre un exemple dordonnancement selon lalgorithme Rate Monotonic.
3.2.1 Analyse dordonnanabilit
Une condition sufsante dordonnanabilit est :
n
i=1
C
i
P
i
U
lub
RM
(n) = n(2
1
n
1) (3.15)
Le tableau suivant donne la valeur de U
l
ub(n) pour quelques valeurs de n :
3.3. DEADLINE MONOTONIC 3.5
Figure 3.2 Exemple dordonnancement selon Rate Monotonic
Tche Cot Priode
T
0
2 6
T
1
3 8
T
2
4 24
T
0
0 5 10 15 20 25
T
1
T
2
n U
lub
1 1.000
2 0.828
3 0.780
4 0.757
5 0.743
Nous pouvons calculer U
lub
pour de grandes valeurs de n :
U
lub
= lim
n
n(2
1
n
1) = ln2 0.69 (3.16)
Donc, si U
est plus petit que 0.69, lensemble est ordonnanable. Sil est plus grand, il faut le
comparer U
lub
RM
(n). Sil est plus grand que cette dernire valeur, il reste un test permettant dta-
blir son ordonnanabilit. Il est dcrit dans la section dvolue lalgorithme Deadline Monotonic,
en page 6.
En 2001, une nouvelle condition dordonnanabilit, appele Hyperbolic Bound, a t propose. Il
sagit galement dune condition sufsante mais pas ncessaire :
n
i=1
(U
i
+ 1) 2 (3.17)
Cette condition est moins restrictive que la prcdente, et est donc intressante.
3.3 Deadline Monotonic
Lalgorithme Rate Monotonic est bas sur lhypothse que les tches sont chance sur requte,
cest--dire que lchance dune tche est gale sa priode. Dans certains systmes cette hypo-
thse ne pourra savrer exacte, et les chances pourront tre plus petites que les priodes. Dans
ce cas, lalgorithme Deadline Monotonic est un algorithme optimal dans le cas des algorithmes
priorit statique avec chances plus petites que les priodes. Comme RM, il est premptif.
La priorit dune tche est xe par son chance. Plus son chance est petite, plus sa priorit est
grande.
La gure 3.3 montre un exemple dordonnancement selon lalgorithme Deadline Monotonic.
Figure 3.3 Exemple dordonnancement selon Deadline Monotonic
Tche Cot Priode Echance
T
0
2 6 5
T
1
3 8 4
T
2
4 24 20
T
0
0 5 10 15 20 25
T
1
T
2
Une condition sufsante dordonnanabilit est :
n
i=1
C
i
D
i
n(2
1
n
1) (3.18)
Ce test nest toutefois pas vraiment optimal, car la charge du processeur y est surestime. Il est
possible de dduire un autre test, en se basant sur les observations suivantes :
1. Le pire cas au niveau des demandes dutilisation du processeur se trouve au moment o toutes
les tches sont actives simultanment ;
2. Le pire temps de rponse dune tche correspond la somme de son temps dexcution et des
interfrences des tches de priorit suprieure.
Si nous supposons les tches ordonnes selon lordre ascendant de leurs chances, le test corres-
pond vrier que :
i : 1 i n C
i
+I
i
D
i
(3.19)
O I
i
est linterfrence
1
mesure sur la tche
i
:
I
i
=
i1
j=1
_
D
i
P
j
_
C
j
(3.20)
Si ce test passe, alors lensemble de tches est ordonnanable. Toutefois, linterfrence est calcule
en partant du principe quune tche
j
interfre exactement
_
D
i
P
j
_
fois, ce qui nest pas forcment le
cas.
La mthode suivante permet une meilleure approximation de cette interfrence, et donc du temps
de rponse de la tche.
Test en zone critique : calcul du temps de rponse
Si le facteur dutilisation du processeur de lensemble de tches est plus petit que 1, mais plus
grand que U
lub
(n), nous pouvons appliquer le test suivant, propos par Audlsey et al. Ce test est
1. A titre de rappel, pour r R, n = r N, est lentier immdiatemment suprieur r.
3.3. DEADLINE MONOTONIC 3.7
valable pour lalgorithme Rate Monotonic et Deadline Monotonic. Ce test consiste en le calcul du
pire temps de rponse des tches, en prenant en compte les interfrences des tches de priorit
suprieure.
Lide est de partir du pire cas, o toutes les tches sont actives au mme instant. Le temps de
rponse R
i
dune tche
i
est alors la somme de son temps dexcution et du temps dexcution de
toutes les tches de priorit suprieure :
R
i
= C
i
+I
i
(3.21)
O
I
i
=
i1
j=1
_
R
i
P
j
_
C
j
(3.22)
Dans cette quation, le terme
_
R
i
P
j
_
C
j
reprsente linterfrence de la tche j sur la tche i le temps
R
i
.
Nous avons donc :
R
i
= C
i
+
i1
j=1
_
R
i
P
j
_
C
j
(3.23)
Il faut vrier que le temps de rponse soit plus faible que lchance de la tche. Nous nous trou-
vons toutefois devant une quation o R
i
apparat des deux cts de lgalit. Nous pouvons appli-
quer une mthode itrative pour son calcul, en observant que seuls certains points dans lintervalle
[0, D
i
] sont pertinents.
1. Nous commenons par prendre un premier point dapproximation :
R
0
i
=
i
j=1
C
j
(3.24)
2. Si ce temps de rponse est au-del de lchance D
i
, la tche nest pas ordonnanable. Sinon
nous passons au point suivant.
3. Nous calculons le point dapproximation suivant :
R
n+1
i
= C
i
+
i1
j=1
_
R
n
i
P
j
_
C
j
(3.25)
4. Si R
n+1
i
= R
n
i
, nous avons atteint le pire temps de rponse pour la tche, qui peut alors tre
compar D
i
. Sinon, nous reprenons au point 3.
Prenons comme exemple lensemble de tches suivant :
Tche Cot Priode Echance Priorit
T
0
40 100 100 3
T
1
40 150 150 2
T
2
100 350 350 1
Pour T
0
, qui est la tche la plus prioritaire, il suft de vrier que son cot soit plus faible que son
chance.
Pour T
1
, nous pouvons appliquer la mthode :
R
0
1
=
1
j=0
C
j
= C
0
+C
1
= 80
R
1
1
= C
1
+
0
j=0
_
R
0
1
P
j
_
C
j
= 40 +
_
80
100
_
40 = 80
R
1
1
= R
0
1
, donc la phase itrative est termine.
Comme R
1
= 80 D
1
= 100, T
1
est ordonnanable.
Pour T
2
, nous pouvons appliquer la mthode :
R
0
2
=
2
j=0
C
j
= C
0
+C
1
+C
2
= 180
R
1
2
= C
2
+
1
j=0
_
R
0
2
P
j
_
C
j
= 100 +
_
180
100
_
40 +
_
180
150
_
40 = 260
R
2
2
= C
2
+
1
j=0
_
R
1
2
P
j
_
C
j
= 100 +
_
260
100
_
40 +
_
260
150
_
40 = 300
R
3
2
= C
2
+
1
j=0
_
R
2
2
P
j
_
C
j
= 100 +
_
300
100
_
40 +
_
300
150
_
40 = 300
R
3
1
= R
2
1
, donc la phase itrative est termine.
Comme R
2
= 300 D
2
= 350, T
2
est ordonnanable.
3.4 Earliest Deadline First
Lalgorithme Earliest Deadline First (EDF) donne la priorit la tche ayant lchance la plus
proche. A chaque fois quune tche est rveille, lordonnanceur rvalue les tches prtes et s-
lectionne celle ayant lchance la plus courte. Cet algorithme est appliqu, ici, des tches prio-
diques chance sur requte o la premption est autorise.
La gure 3.4 illustre cet algorithme.
Lalgorithme EDF est optimal dans le cas premptif. La condition ncessaire et sufsante dordon-
nanabilit est :
n
i=1
C
i
P
i
1 (3.26)
Un ensemble de tches est donc ordonnanable si son taux dutilisation du processeur est plus petit
ou gal 0.
3.4.2 Cas non-premptif
Lalgorithme EDF est optimal dans le cas premptif. A titre indicatif, observons son comportement
si la premption est impossible.
Considrons lexemple suivant deux tches :
3.4. EARLIEST DEADLINE FIRST 3.9
Figure 3.4 Exemple dordonnancement EDF
Tche Cot Priode
T
0
2 5
T
1
3 7
T
2
1 10
T
0
0 5 10 15 20
T
1
T
2
Tche Cot Arrive Echance
T
0
4 0 7
T
1
2 1 5
Dans le cas premptif, lordonnancement trouv est :
T
0
0 5 10
T
1
Nous pouvons observer que la tche T
0
est prempte au temps 1 par la tche T
1
, et lorsque cette
dernire est termine, T
0
peut reprendre son excution. Dans le cas non-premptif, larrive de
la tche T
1
au temps 1 voit la tche T
0
continuer son excution, tant donn quelle ne peut tre
prempte :
T
0
0 5 10
T
1
Nous pouvons donc observer que lchance de T
1
nest pas respecte. Lordonnancement suivant
est une solution possible dans le cadre non-premptif :
T
0
0 5 10
T
1
3.10CHAPITRE 3. ALGORITHMES DORDONNANEMENT TEMPS REL POUR TCHES PRIODIQUES
Cet ordonnancement montre quune solution existe dans ce cadre. Toutefois, EDF traite les tches
ds leur moment darrive. Sans la connaissance a priori des temps darrive des tches, il nest pas
possible, au temps 0, de prendre la dcision de retarder lexcution de T
0
. En effet, ici le processeur
reste inactif durant un quantum de temps, ce qui aurait pu tre prjudiciable suivant le temps darri-
ve de T
1
. Si la premption nest pas autorise, le problme de trouver un ordonnancement faisable
devient NP-dur.
3.5 Least Laxity First
Lalgorithme Least Laxity First (LLF) est, linstar dEDF, un algorithme priorit dynamique. Il
traite des tches priodiques pour lesquelles la premption est autorise.
La rgle dcrivant lalgorithme est simplement que la tche dont la laxit est la plus faible est la
plus prioritaire.
Les dnitions suivantes permettent daborder la notion de laxit :
L = D C : sa laxit nominal. Indique le retard maximum que peut prendre la tche sans
dpasser son chance
D(t) = d t : son dlais critique rsiduel au temps t
C(t) : sa dure dexcution rsiduelle au temps t
L(t) = D(t) C(t) : sa laxit rsiduelle au temps t
Figure 3.5 Exemple dvolution de la laxit dune tche, pour un ordonnancement EDF
T
0
0 5 10 15 20 25 30 35
T
1
L
T
1
(t)
A partir de la dnition de la rgle, nous pouvons dduire deux implmentations de LLF :
1. La laxit rsiduelle est calcule au lancement de la tche. Nous nous trouvons dans un cas de
gure de type EDF
2. La laxit rsiduelle est calcule chaque instant t.
La deuxime option est videmment la plus intressante. Elle permet dexcuter, un instant t, la
tche qui a le moins de marge disposition pour tenir son chance.
La condition dordonnanabilit est identique celle dEDF. Nous avons donc la condition suf-
sante et ncessaire suivante :
n
i=1
C
i
P
i
1 (3.27)
Bibliographie
[1] Site web Xenomai : http ://www.xenomai.org .
[2] Doug ABBOTT. Linux fo Embedded and Real-time Applications. Newnes, 2003.
[3] Alan BURNS et Andy WELLINGS. Real-Time Systems and Programming Languages.
Addison-Wesley, second edition dition, 1997.
[4] Giorgio C. BUTTAZZO. Hard Real-time Computing Systems. Kluwer Academic Publishers,
2000.
[5] Francis COTTET, Jolle DELACROIX, Claude KAISER et Zoubir MAMMERI. Ordonnance-
ment temps rel. HERMES Science Publications, 2000.
[6] Alain DORSEUIL et Pascal PILLOT. Le Temps Rel en Milieu Industriel. Dunod, 1991.
[7] Bruce Powel DOUGLAS. Real Time UML. Addison-Wesley, third edition dition, 2004.
[8] Jack GANSSLE. The Art of Designing Embedded Systems. Newnes (Elsevier), 2008.
[9] Cameron HUGHES et Tracey HUGHES. Parallel and Distributed Programming Using C++.
Addison-Wesley, 2003.
[10] Omar KERMIA. Ordonnancement temps rel multiprocesseur de tches non-premptives
avec contraintes de prddence, de priodicit stricte et de latence . PhD thesis, Universit
Paris XI, UFR scientique dOrsay, 2009.
[11] Mark H. KLEIN, Thomas RALYA, Bill POLLAK, Ray OBENZA et Michael Gonzlez HAR-
BOUR. A Practioners Handbook for Real-Time Analysis : Guide to Rate Monotonic Analysis
for Real-Time Systems. Kluwer Academic Publishers, 1993.
[12] Phillip A. LAPLANTE. Real-time Systems Design and Analysis. IEEE Press, second edition
dition, 1997.
[13] R.J. WIERINGA. Design Methods for Reactive Systems. Morgan Kaufmann Publishers, 2003.
[14] P. Meumeu YOMSI et Y. SOREL. Extending Rate Monotonic Analysis with Exact Cost of
Preemptions for Hard Real-Time Systems . Dans 19th Euromicro Conference on Real-Time
Systems. ECRTS 07., pages 280290, 2007.
[15] Luigi ZAFFALON. Programmation Synchrone de Systmes Ractifs avec Esterel et les Synch-
Charts. Presses Polytechniques et Universitaires Romandes, 2005.
1

Introduction Programmation Temps Réel

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Introduction Programmation Temps Réel

Hochgeladen von

Copyright:

Verfügbare Formate

INTRODUCTION LA

PROGRAMMATION TEMPS REL

Das könnte Ihnen auch gefallen