Chapitre 2 Modèle considéré et contraintes de conception pour le temps-réel
Il y a de nombreux formalismes de modélisation de systèmes
informatiques qui font intervenir le temps. Citons en particulier les
méthodes formelles (logiques temporelles, algèbres de processus), les
méthodes structurées (systèmes réactifs synchrones et asynchrones,
réseaux de Pétri temporels et temporisés par exemples).
Pour notre part, nous nous intéressons au formalisme utilisé dans la
communauté de l'ordonnancement temps-réel. Dans ce formalisme, le
temps est une grandeur physique mesurable (espace discret ou dense)
qui permet de caractériser les éléments du système, dont les
traitements font partie (on parle de tâches). Le système est
modélisé sous la forme de demandeurs de ressources d'un côté, et de
serveurs de ressources de l'autre, le tout étant arbitré par un
composant central : le support d'exécution (en général un
système d'exploitation). La capacité des serveurs peut correspondre à
une densité temporelle (ressources actives : processeurs,
réseau), ou à une capacité scalaire (ressources passives :
verrous, sémaphores, rendez-vous par exemple). Et les demandeurs en
ressources (les traitements) ont des contraintes de validité
fonctionnelles et temporelles, en même temps que des besoins en
ressources quantifiés.
2.1 Modèle de système considéré
Le formalisme adopté possède l'avantage d'être proche des
implantations concrètes, ce qui permet un dimensionnement simple du
système d'après le modèle, et ce qui permet de valider l'implantation
avec les mêmes outils que pour la vérification du modèle.
Plus précisément, nous nous appuyons sur le modèle de
système de la
figure 2.1.
Figure 2.1 : Modèle de système considéré
Le système est soumis à des événements provenant de
l'environnement du système, et générés par du matériel
spécialisé (réseau, capteurs ou générateur d'impulsions par
exemple). Il effectue des traitements en tenant compte ou non
de ces événements, qui peuvent décider d'actions à
entreprendre sur l'environnement au moyen de témoins (écrans ou diodes
par exemples), d'actionneurs (moteurs ou relais par exemple), ou
de messages (réseau par exemples).
2.1.0.1 Niveau logiciel
Les traitements forment l'application et le support d'exécution temps-réel. L'application effectue les
traitements utiles du système pour lesquels elle a des besoins en ressources logiques ou matérielles (entre autres des ressources
processeur), et est soumises à des contraintes liées aux
spécifications, dont les contraintes temporelles font partie. Elle est
structurée en tâches, c'est à dire en flots de contrôle (i.e. séquences d'opérations du processeur).
Le support d'exécution est chargé de répartir les demandes en
ressources de l'application entre les ressources matérielles ou
logiques disponibles, tout en veillant au respect de toutes les
contraintes. Il peut prendre la forme d'un système d'exploitation
contrôlant directement le matériel, ou d'un intergiciel (middleware en anglais) s'intercalant entre le système
d'exploitation et l'application. La particularité d'un support
d'exécution temps-réel est qu'il prend les contraintes temporelles
ainsi que le comportement temporel de l'application et du système en
compte. Tout particulièrement, c'est une composante du support
d'exécution qui décide quelle tâche doit s'exécuter sur quel
processeur : l'ordonnanceur.
Dans les sections 2.1.1 et 2.2 qui
suivent, nous revenons plus précisément sur la caractérisation
temporelle des tâches et du support d'exécution.
2.1.0.2 Niveau matériel
Le système repose sur un ou plusieurs processeurs pour
effectuer les traitements. Il est découpé en noeuds
qui communiquent (par messages ou par mémoire partagée), chaque
noeud correspondant à un processeur et aux traitements qui sont
exécutés par le processeur au cours de la vie du système.
En temps-réel, l'interaction entre logiciel et matériel est fine,
puisque le comportement temporel des traitements exécutés par les
processeurs dépend des capacités des processeurs (puissance de
calcul). Nous voyons dans la suite que cette donnée est importante
pour l'établissement des propriétés temporelles du système.
2.1.1 Caractérisation des tâches
2.1.1.1 Description et définitions
Une tâche est en charge de fournir un des services de
l'application. Elle correspond aux exécutions d'une séquence
d'opérations donnée sur le processeur. Que les tâches partagent un
unique espace d'adressage, ou que le
cloisonnement mémoire soit possible (notion de processus Unix par
exemple), est indifférent pour la suite.
Dans le modèle canonique du domaine, le service fourni par la tâche
peut être rendu plusieurs fois au cours de la vie du système. Ce qui
signifie que la séquence d'opérations d'une tâche peut être ré-exécuté
plusieurs fois. Pour cette raison, chacune de ces exécutions de la
séquence d'opérations est considérée individuellement sous la forme de
travaux (``jobs'' en anglais).
Plusieurs travaux de plusieurs tâches (distinctes ou non) sont
susceptibles de s'exécuter sur un même processeur, mais, par
définition, ce dernier ne peut en exécuter qu'un seul à la fois. Un
travail est donc associé à une structure de données qui renferme en
particulier son état d'exécution.
Le système d'exploitation s'occupe entre autre de passer l'état des
travaux d'un état à un autre suivant le diagramme de transition des
travaux (la figure 2.2 propose un exemple), en même
temps qu'il choisit d'exécuter un travail plutôt qu'un autre.
Généralement, le diagramme d'état des travaux fait couramment
intervenir les états suivants :
-
ready :
- travail prêt à démarrer, i.e. pas encore démarré, ou
dont l'exécution a été interrompue d'autorité (suite à un événement
matériel par exemple) pour laisser la place à un autre travail.
- running :
- travail en cours d'exécution sur le processeur ;
- blocked :
- travail en attente de la disponibilité d'une ou
plusieurs ressources ;
- sleeping :
- travail en sommeil, en attente d'un événement de
réveil ;
- stopped :
- travail terminé.
Figure 2.2 : Diagramme d'état des travaux
La vie d'un travail peut également être représentée suivant un chronogramme ou diagramme de
Gantt tel que celui
de la figure 2.3, ce qui permet d'introduire
la terminologie suivante :
Figure 2.3 : Événements au cours de la vie d'un travail
-
1 : date de création ou d'activation.
- Le travail est créé et prêt à être exécuté sur le
processeur. Arrival ou Request time en anglais.
- 2 : date de démarrage.
- Le travail commence à être exécuté sur le processeur
pour la première fois. Start time en anglais.
- 3 : dates de préemption.
- Le
travail est momentanément interrompu au profit d'un autre, plus prioritaire (plusieurs possibles durant la vie du travail).
- 4 : dates de reprise.
- Le processeur reprend l'exécution du travail là
où il avait été précédemment préempté (plusieurs possible durant la
vie du travail).
- 5 : date de terminaison.
- Le travail termine de s'exécuter sur le
processeur. Finishing ou completion time en anglais.
- 6 : temps de réponse.
- L'écart entre la date de terminaison et la date
d'activation d'un travail. Response time en anglais.
2.1.1.2 Caractéristiques et contraintes temporelles
Le système d'exploitation doit connaître les
caractéristiques
temporelles des travaux de chaque tâche, formant une partie du modèle de tâche, puisqu'il doit garantir que les
contraintes temporelles
sont respectées. Dans le modèle de tâche figurent habituellement les
caractéristiques temporelles suivantes :
-
Le temps d'exécution :
- il s'agit du temps d'exécution d'un
travail de la tâche sur le processeur et considéré de manière
isolé. En général, il s'agit d'un temps d'exécution
pire-cas (ou WCET pour Worst
Case Execution Time en anglais), c'est à dire un majorant sur tous
les temps d'exécution possibles de tous les travaux de la tâche,
chacun pris en isolement du reste du système. Cette donnée constitue
un paramètre d'entrée important aux méthodes et outils de vérification
du respect des échéances. Quelques systèmes temps-réel souple
considèrent un temps d'exécution moyen, ou minimal.
- La loi d'arrivée :
- Il s'agit de la répartition dans le temps
des dates de création des travaux de la tâche. On distingue
couramment trois lois :
-
périodique :
-
Les travaux de la tâche sont créés de façon rigoureusement
périodique, et la période est précisée. Si les périodes Ti des
tâches du système sont telles que " i,j, Ti > Tj
Þ Ti multiple de Tj, alors le système est harmonique. Si la date
d'activation du premier travail est donnée, la tâche est dite concrète. De plus, si
toutes les tâches sont périodiques concrètes, et si les dates
d'activation du premier travail sont identiques, les tâches sont
dites synchrones.
Si toutes les tâches du système sont synchrones, le motif
d'activation des travaux se répète à l'identique par intervalles de
durée multiple de l'hyperpériode (le plus petit commun
multiple des périodes des tâches du système, i.e. la plus grande
période dans le cas particulier d'un système harmonique). Par
extension, on conserve cette définition de l'hyperpériode pour des
tâches non concrètes.
- sporadique :
-
Les travaux de la tâche sont créés de sorte qu'une durée minimale
sépare deux travaux successifs : le délai
d'inter-arrivée, qui est précisé. Une tâche périodique est
un cas particulier de tâche sporadique.
- apériodique :
-
Un travail de la tâche peut être créé à tout instant. Une tâche
sporadique est un cas particulier de tâche apériodique.
D'autres lois d'arrivée moins usuelles sont possibles. La connaissance
de cette donnée est un paramètre d'entrée important aux outils de
vérifications de la garantie du respect des échéances.
Le modèle de tâche indique également les contraintes temporelles des
travaux. Les contraintes temporelles courantes sont (voir la
figure 2.4) :
Figure 2.4 : Contraintes temporelles courantes
-
1 : date
d'échéance :
- il s'agit de la date à
laquelle les travaux doivent être terminés, relativement à leur date
de création, ou sous forme d'un vecteur de dates absolues. Relative ou absolute deadline en anglais.
- 2 : gigue de démarrage :
- il s'agit de la mesure de dispersion (écart-type,
variance) des délais entre la date de création et la date de
démarrage des travaux d'une tâche. Release jitter en
anglais.
- 3 : précédence :
- avant de pouvoir démarrer, un travail doit attendre le
résultat d'un travail d'une autre tâche. On représente ce type de
contrainte sous la forme d'un graphe de précédence,
i.e. un graphe orienté dont les noeuds sont les tâches et dont les
arcs sont les relations de précédence (éventuellement augmentées des
messages qui transitent).
Quelques mesures pour caractériser le comportement temporel sont
dérivées des contraintes et des caractéristiques temporelles :
-
L'utilisation (ou taux d'utilisation) :
- c'est la
proportion de ressources données occupées par les travaux d'une
tâche. Le plus souvent, on s'intéresse à l'utilisation du
processeur : si la tâche ti est périodique de période Ti et
si chaque travail nécessite un temps d'exécution Ci sur le
processeur, alors son taux d'utilisation est : ui =
Ci/Ti. On définit également l'utilisation processeur pour
un ensemble de tâches périodiques : U = åi ui = åi
Ci/Ti. On montre aisément que 1 est une borne supérieure
d'utilisation : au delà de ce seuil, la ressource est dite surchargée puisque potentiellement la demande en ressource
excède la capacité disponible.
- Le retard :
- c'est l'écart entre la date de terminaison du
travail et la date d'échéance. Négatif quand le travail respecte son
échéance. Lateness en anglais (``tardiness''
lorsqu'on ne s'intéresse qu'aux retards positifs).
- La laxité :
- c'est l'écart maximal entre la date
d'activation et la date de démarrage du travail, de sorte que
l'échéance demeure respectée. Laxity ou Slack time
en anglais.
Les contraintes temporelles doivent être impérativement respectées en
temps-réel dur. En temps réel souple, des dépassements qui ne remettent
pas en cause la structure de l'application (i.e. tout sauf les
contraintes de précédence) sont tolérées. Dans ce cas, il est possible
de définir une métrique qui mesure la qualité de service
qui demeure assurée (par exemple le nombre de travaux qui respectent
leur échéance relativement au nombre total de travaux créés pour la
tâche). Cette qualité de service peut être évaluée globalement pour
tout le système, ou relativement à chaque sous-système (ensemble de
tâches de l'application), avant fonctionnement (par analyse) et/ou en
cours de fonctionnement (exécution effective ou simulation). Dans
certains systèmes, la qualité de service constitue une contrainte
supplémentaire conditionnant la correction du comportement du système
(systèmes dits à réservation de ressources en particulier).
Dans la suite, sauf précision en cas d'ambiguïté, on confond les
notions de travail et de tâche, puisqu'un travail est
une instance de tâche.
2.1.2 Contraintes de ressources
Les tâches peuvent être vues comme des éléments du système qui
consomment la ressource processeur. D'autres ressources existent
au sein du système, qui peuvent être matérielles
(processeur(s), mémoire, réseau, capteurs, actionneurs par exemple),
ou logiques (sémaphores, files de messages par exemple). Le
système d'exploitation a pour rôle de gérer toutes les ressources,
c'est-à-dire d'arbitrer entre les demandes que les tâches de
l'application font, et les ressources effectivement disponibles dans
le système.
Dans le cas de ressources actives
[SL94], c'est à dire celles qui permettent aux travaux de
progresser dans leur exécution, telles que les processeurs dans le
domaine du temps-réel, et le réseau dans le domaine des communications
par réseau, cet arbitrage consiste en un partage temporel (i.e. multiplexage) de l'accès aux ressources. Les décisions de
partage sont faites suivant un ordonnancement (détaillé en 3
dans le cas de la ressource processeur).
Dans le cas des autres ressources (les ressources passives), l'objectif est de restreindre
le nombre et les types d'accès (lecture/écriture) afin de maintenir la
cohérence : c'est le rôle des mécanismes de synchronisation (verrous,
sémaphores, conditions, moniteurs, files de messages par exemple), qui
par extension permettent également aux tâches d'échanger des
informations ou de se synchroniser sans qu'il y ait nécessairement de
ressource à protéger (comme avec les rendez-vous par exemple).
La phase de conception devra définir les profils d'accès aux
ressources passives. On peut distinguer (voir la
figure 2.5 pour une illustration) :
[Attente active]
[Consultation périodique]
[Commandé par événement]
Figure 2.5 : Profils d'accès aux ressources
-
l'attente active
- (busy waiting en anglais) qui consiste
à tenter d'accéder à la ressource en boucle jusqu'à ce que celle-ci
soit disponible.
- la consultation périodique
- (polling en anglais),
ou traitement commandé par le temps (time-driven en
anglais) qui consiste à tenter d'accéder périodiquement à la
ressource. L'attente active est un cas particulier de ce profil
d'accès.
- la signalisation par événement
- (event-driven en
anglais) où la tâche demandeuse de la ressource est mise en sommeil
en attente qu'un événement extérieur (via le système
d'exploitation) ou qu'une autre tâche la réveille, pour lui signaler
que la ressource est disponible.
La palette des choix possibles dépend de ce que permet le système
d'exploitation. Suivant le profil choisi, la réactivité du système
sera plus ou moins bonne, et le comportement temporel du système plus
ou moins facile à caractériser : il sera d'autant plus facile de
garantir que le système respectera toutes ses contraintes temporelles
que le comportement de ses tâches est déterministe (en particulier en
ce qui concerne la loi d'arrivée et les temps d'exécution).
Lorsque les tâches ne sont soumises ni à des contraintes de
ressources, ni à des contraintes de précédence, elles sont dites indépendantes.
2.1.3 Autres contraintes
En dehors des contraintes de temps ou d'accès aux ressources, la
spécification de systèmes temps-réel introduit parfois d'autres
contraintes. Les plus courantes sont les contraintes de :
-
localisation ou localité :
- précisent si les tâches
doivent s'exécuter sur un processeur donné (par exemple pour accéder
à un capteur disponible uniquement sur une machine donnée, ou pour
diminuer la quantité de messages réseau échangés) ;
- anti-localité :
- précisent si deux tâches doivent
s'exécuter sur des processeurs différents (par exemple quand il
s'agit d'introduire de la redondance spatiale dans les traitements
afin que le système soit tolérant aux fautes physiques).
2.2 Caractérisation du support d'exécution
La phase d'implantation d'une application temps-réel repose à la fois
sur les spécifications que nous venons de présenter, et sur les
caractéristiques des supports langage et système pour le temps-réel
sous-jacents. Ces dernières contraignent en partie la façon dont
l'application doit être modélisée. Il est donc important de connaître
ces supports langages et système dès la phase de conception. Nous
présentons ici quelques unes des caractéristiques à prendre en compte.
2.2.1 Perception du temps
Un système d'exploitation en général, et tout particulièrement un
système d'exploitation temps-réel, doit percevoir l'écoulement du
temps, notamment pour prendre ses décisions d'ordonnancement.
Couramment, un système informatique s'appuie sur une horloge matérielle spécialisée dans la
génération d'événements à intervalles réguliers, ce qui fournit
au système d'exploitation une base de temps rudimentaire afin
d'assurer au moins la vivacité du système. En contrepartie, la
résolution de l'échelle de temps, utile aux décisions d'ordonnancement
pour le temps-réel, est fonction de la fréquence de l'horloge. Mais,
puisque les coûts de traitement associés à la prise en compte de cette
horloge ne sont pas négligeables, cette fréquence n'est en pratique
pas très élevée (de l'ordre de 1 à 10ms).
Certains systèmes peuvent aussi consulter un compteur externe
ou interne au processeur, qui possède une résolution beaucoup plus
élevée (jusqu'à quelques fractions de nanoseconde). Pour les systèmes
temps-réel, cette fonctionnalité permet de prendre des décisions
d'ordonnancement de façon plus précise, et permet de prendre en compte
des contraintes temporelles beaucoup plus fines.
Dans ces deux cas, la perception du temps est locale à chaque
noeud. Ceci peut poser problème lorsque le système temps-réel est
distribué sur plusieurs noeuds : en général les horloges locales
dévient et se désynchronisent l'une par
rapport à l'autre, ce qui empêche de prendre des décisions relatives
au temps et qui sont globales au système. Dans ce cas, une perception
du temps cohérente entre les noeuds nécessite de connaître ou
d'établir les bornes sur les écarts entre les évolutions des horloges
locales aux noeuds du système. Le système doit alors soit se fonder
sur une horloge commune à tous les noeuds (par exemple utiliser le
système GPS), soit utiliser des mécanismes matériels ou logiciels de
synchronisation des horloges locales [AP97]. Dans tous les
cas, le respect des contraintes temps-réel en distribué imposent que
la précision de la synchronisation des horloges soit connue
lors de la conception.
2.2.2 Supports langage et système
2.2.2.1 Supports langage
Le modèle de système temps-réel sur lequel nous reposons fait
apparaître des notions que les langages de programmation savent
manipuler directement ou non.
Ainsi, quelques langages savent manipuler des tâches directement
(comme Ada ou occam2). D'autres langages (C, C++ par
exemple) imposent de recourir directement au système d'exploitation ou
au support d'exécution pour les gérer.
De la même manière, certains langages proposent des mécanismes de
synchronisation (par exemple : moniteurs en Modula-1, Concurrent
Pascal, Mesa ; objets protégés en Ada ; files de messages en occam2 et
Ada). Sinon, il est nécessaire de faire directement appel aux services
du système d'exploitation et/ou du matériel.
Enfin, il serait désirable que le langage fournisse tous les éléments
qui permettent d'évaluer le comportement des tâches, ou, de façon plus
réaliste, qu'il permette de l'exprimer : les temps d'exécution (par
annotation du nombre d'itérations des boucles par exemple), les
ressources utilisées. Malheureusement, il existe peu de langages dans
l'industrie qui supportent cette fonctionnalité ; en général, il
s'agit d'une série de restrictions d'un langage courant1 (C, Ada)
et de syntaxes d'annotation (par exemple : annotation du nombre
d'itérations d'une boucle) qui sont non standards et spécialisées pour
un secteur ou une entreprise particulière (par exemple SPARK Ada pour
l'avionique anglaise [Bat98]). Ceci amène en pratique à
séparer l'implantation du système, de sa caractérisation, ce qui peut
être source d'erreur (le modèle de comportement ne correspond pas à la
réalité).
2.2.2.2 Supports système
Quantité de supports d'exécution pour le temps-réel existent tant dans
l'industrie (VxWorks, pSos, VRTX, OSE, OS9, LynxOS/LynuxOS, RTEMS,
eCos par exemple) qu'au sein de la communauté scientifique (Mars
[KFG+92], Maruti [SdSA95], Spring
[SRN+98], Hades [CPC+00], RTMach
[TNR90], DIRECT [SG97a], Emeralds
[Zub98], MaRTE [RH01], DICK [But97],
Hartik/S.Ha.R.K. [GAGB01], variantes RTLinux
[1][Bar97, WL99b, DFW02, Heu01]
par exemple). Des normes pour les interfaces de programmation système
existent également qui sont plus ou moins respectées par les systèmes
d'exploitation (normes POSIX1003.1b et 1003.1c [fIT93] ou
ITRON [6] par exemple).
Nous présentons ici quelques unes des fonctionnalités qu'on retrouve
couramment dans les supports d'exécution temps-réel :
-
Interface de création des tâches.
- Certains systèmes proposent
des mécanismes pour associer la création de tâches à l'occurrence
d'événements de l'environnement (création orientée événements, ou
event-driven). D'autres ne permettent d'implanter que des
tâches périodiques (exécution commandée par le temps, ou time-driven). Dans tous les cas, il est possible à une tâche
d'en créer d'autres.
- Gestion des délais.
- Le système peut proposer une fonctionnalité
d'alarme différée relativement au temps processeur occupé par la
tâche (indépendamment des préemptions), ou de sommeil pendant une
durée donnée relativement à la date de début de la mise en sommeil
(délai relatif qui accumule les erreurs dues à la résolution
de l'horloge système), ou jusqu'à une date absolue (délai
absolu). L'implantation des tâches périodiques par exemple
dépend des méthodes de mise en sommeil disponibles.
- Primitives de synchronisation.
- Les systèmes d'exploitation
proposent en général des mécanismes de synchronisation basiques
identiques, à savoir les sémaphores valués ou les verrous. Au delà,
les systèmes peuvent adhérer à une norme, totalement ou
partiellement, dans laquelle figurent une série de mécanismes de
synchronisation supplémentaires (eventflag2, boîte aux lettres,
files de messages, verrous en lecture/écriture). Les systèmes
peuvent également proposer leurs propres mécanismes de
synchronisation, à la place ou en plus de ceux recommandés par les
normes auxquelles ils peuvent décider de se conformer (par exemple
les CABs de DICK, ou Cyclical Asynchronous Buffers, qui sont
des boîtes aux lettres limitées à un seul élément).
- Politique d'ordonnancement.
- Pour définir la prochaine tâche à
élire, le support d'exécution peut reposer sur un calendrier, ou
plan défini lors de la phase de conception, ou sur un
ordonnancement en-ligne reposant sur des priorités relatives
entre les tâches, ou en fonction de l'ordre d'activation (politique
du premier arrivé, premier servi, ou FIFO, par exemple). Le chapitre
3 détaille plus en détails les politiques
d'ordonnancement temps-réel les plus courantes.
- Profil d'appel à l'ordonnanceur.
- Le système d'exploitation peut
prendre ses décisions d'ordonnancement lors de chaque événement
système (blocage sur ressource, interruption matérielle), ou ne les
prendre que lors d'une interruption d'horloge (tick
scheduling). Dans le premier cas, les surcoûts système sont
plus élevés, et dans le second cas les gigues d'activation sont plus
importantes.
Dans le cas de l'implantation de systèmes temps-réel strict, il est
nécessaire de disposer de suffisamment d'informations sur le
comportement temporel du système d'exploitation sur lequel on repose.
Cela suppose soit de disposer du code source du système d'exploitation
et d'être capable de l'analyser [CP01a, CP01b] pour en
extraire les caractéristiques temporelles pertinentes ou pour en
déduire le comportement de l'application dans son ensemble ; soit de
disposer des caractéristiques temporelles pertinentes fournies
avec le système d'exploitation (le plus souvent obtenues par test et
mesure, ou benchmark) ; soit que l'utilisateur détermine les
caractéristiques temporelles en évaluant lui-même le système
d'exploitation ou l'application dans son ensemble.
Parmi les caractéristiques temporelles couramment évaluées, on trouve
[fIT93] les coûts liés aux appels système explicites :
-
Délai de prise de ressource
- lorsqu'une tâche acquiert un
sémaphore, un verrou, un moniteur ou tout autre mécanisme d'exclusion
non encore pris par une autre tâche.
- Coût de changement de paramètre d'ordonnancement
- lorsqu'une
tâche décide de changer de priorité (développé
en 3) par exemple.
- Coûts temporels d'autres services système
- tels que ceux de la
création, suppression et terminaison de tâche, ou ceux liés au
service d'ordonnancement.
D'autres coûts systèmes implicites sont également évalués :
-
Caractéristiques du service d'horloge système
- telles que sa
résolution, ses paramètres de déviation ou d'irrégularité par
rapport à une horloge de référence, les coûts temporels liés à
l'appel des primitives de consultation et de modification, ainsi que
ceux des primitives de programmation d'un réveil (timeout).
- Délai de propagation d'un événement de réveil
- lorsqu'une tâche
libère une ressource, signale une condition, ou envoie un événement
(signal POSIX par exemple) à une autre tâche.
- Coûts temporels des changements de contexte.
- C'est le temps
nécessaire à la préemption d'un travail au profit d'un autre. Il
s'agit d'une durée essentiellement dépendante de la configuration
matérielle (type de processeur, cadence, taille des caches
d'instructions, de données, et de traduction d'adresses par
exemple).
- Surcoûts temporels liés à la gestion des interruptions
matérielles.
- Ce sont les temps nécessaires au passage de la tâche
ou du traitant d'interruption en cours, vers le code de traitement
de l'interruption levée ; et inversement. Il s'agit encore d'une
donnée essentiellement dépendante de la configuration matérielle.
- Autres coûts système.
- Les normes (comme POSIX1003.1b par
exemple) proposent en plus de mesurer les coûts de services plus
sophistiqués du système d'exploitation ou du support d'exécution,
tels que ceux des services de gestion de fichiers ou d'allocation
dynamique de mémoire par exemple.
La connaissance de majorants aux caractéristiques temporelles du
système d'exploitation est un des paramètres d'entrée essentiels afin
de garantir, avant exécution, qu'un système temps-réel strict
respectera toutes ses contraintes temporelles en cours de
fonctionnement. Or, certains services du système d'exploitation
peuvent avoir des caractéristiques temporelles (telles que le temps
d'exécution par exemple) pire-cas déraisonnables, comme par exemple
l'allocation dynamique de mémoire [Pua02] ou le service de
pagination par zone d'échange (swap en anglais), ou de gestion
de fichiers sur disque. Ces services ont peu de chances d´être adaptés
aux contraintes temporelles de l'ordre de la milliseconde (ce qui est
courant en temps-réel), ce qui explique pourquoi ce type de service
est rarement utilisé dans le contexte du temps-réel strict.
- 1
- En
général : pas de boucles infinies, récursivité contrôlée.
- 2
- une variante des
conditions sous forme d'un bitmap.