Précédent Index Suivant

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.

Précédent Index Suivant