Ordonnancement temps réel

Ordonnancement centralisé

par

Francis COTTET

Professeur d’université (ENSMA, Poitiers Futuroscope) Ingénieur de l’Institut national polytechnique de Grenoble Docteur ès sciences

Joëlle DELACROIX

Maître de conférences (Conservatoire national des arts et métiers, Paris) Docteur en informatique de l’université Pierre-et-Marie-Curie

Claude KAISER

Professeur (Conservatoire national des arts et métiers, Paris) Ingénieur de l’École polytechnique, ingénieur du génie maritime Docteur ès sciences

et

Zoubir MAMMERI

Professeur d’université (université Paul-Sabatier, Toulouse) Ingénieur, docteur en informatique

Habilité à diriger des recherches

es applications temps réel sont celles où le facteur temps est la principale contrainte à respecter et où ce facteur est prépondérant pour évaluer la qua- lité du service. Elles concernent un large spectre d’activités et se rencontrent dans la commande de procédés, les systèmes embarqués, le guidage de mobi- les, la surveillance des centrales nucléaires, la conduite d’expériences scienti- fiques, la robotique, la fourniture d’images et de son pour le multimédia, le suivi opératoire en milieu médical et, même, le suivi d’informations boursières.

Dans un système informatique temps réel dont le fonctionnement est assujetti à l’évolution dynamique d’un procédé à contrôler, l’ordonnancement des tâches chargées de la surveillance et de la commande de ce procédé joue un rôle capi- tal. C’est cet ordonnancement qui fait l’objet de cet article.

1. Contexte... — 2

1.1 Applications temps réel ... — 2

1.2 Contraintes temps réel pour l’ordonnancement des tâches et des messages ... — 2

2. Définitions et notions générales... — 4

2.1 Architecture des applications temps réel ... — 4

2.2 Caractéristiques des tâches ... — 7

2.3 Ordonnancement temps réel... — 9

3. Ordonnancement monoprocesseur... — 11

3.1 Approches et techniques classiques pour l’ordonnancement de tâches — 11 3.2 Ordonnancement pour la résolution des contraintes temporelles ... — 13

3.3 État de la technologie... — 22

4. Ordonnancement multiprocesseur... — 23

4.1 Position et formulation du problème... — 23

4.2 Premiers résultats et comparaison avec l’ordonnancement monoprocesseur... — 23

4.3 Anomalies de l’ordonnancement multiprocesseur ... — 24

4.4 Conditions d’ordonnançabilité ... — 24

4.5 Heuristiques en ligne... — 26

4.6 Conclusion... — 27

Références bibliographiques... — 27

L

1. Contexte

1.1 Applications temps réel

La nature des contraintes temporelles des applications temps réel conduit à distinguer les contraintes strictes et les contraintes relati- ves.

Le temps réel est à contraintes strictes quand une faute tempo- relle (non-respect d’une échéance, arrivée d’un message après les délais, irrégularité d’une période d’échantillonnage, dispersion tem- porelle trop grande dans un lot de mesures « simultanées ») est intolérable parce qu’elle peut entraîner une catastrophe humaine, économique ou écologique.

Le temps réel est à contraintes relatives lorsque des fautes tempo- relles sont tolérables dans une certaine mesure.

Les applications déclenchent des événements à occurrence pério- dique ou aléatoire et imposent au système informatique qui leur est associé de réagir avant un délai fixé ou à une date donnée. De plus, cette réaction n’est créditée que d’une faible marge temporelle, parce qu’il faut recueillir des données fugaces, lancer ou clore rapi- dement des actions, envoyer ponctuellement des réponses ou des commandes.

L’échelle du temps peut varier selon les applications : la microse- conde dans un radar, la seconde dans une interface homme- machine, une minute dans une chaîne de fabrication, une heure pour une réaction chimique.

Le temps réel est un défi important pour les systèmes informati- ques et est souvent mal connu. Les systèmes temps réel, quelle que soit leur taille, sont d’abord caractérisés par la présence de contrain- tes temporelles. Leur gestion est l’aspect fondamental et spécifique qui les distingue des systèmes classiques. La validité des réactions ne dépend pas seulement de la justesse des calculs, mais aussi de l’instant de production des résultats. Pour une application temps réel, un résultat juste mais hors délai est un résultat faux [38] [62].

Un système informatique temps réel peut être construit :

— comme un générateur cyclique d’actions qui captent la dyna- mique du procédé par échantillonnage périodique et qui lui envoient des commandes au même rythme (on parle aussi de sys- tème synchrone) ;

— comme un système réactif qui répond instantanément aux sti- mulus provenant du procédé selon la dynamique de celui-ci ;

— comme une organisation qui couvre ces deux aspects en ordonnançant l’exécution de tâches périodiques ou apériodiques ; on parle alors de système asynchrone.

1.2 Contraintes temps réel

pour l’ordonnancement des tâches et des messages

Dans un système asynchrone, l’ordonnancement des tâches devient un élément majeur, chargé de faire respecter les échéances des requêtes du procédé, mais aussi de résorber les surcharges ou les conséquences des pannes. Dans ce cas, il doit protéger, en prio- rité, contre les fautes temporelles, les tâches primordiales pour le procédé.

On qualifie de temps réel tout système informatique dont le fonctionnement est assujetti à l’évolution dynamique de l’état de l’application temps réel. On distingue dès lors deux parties dans l’application : le système informatique temps réel et le pro- cédé auquel ce système informatique est connecté et dont il doit commander et contrôler le comportement (figure 1).

Figure 1 – Application temps réel Observations

Capteurs passifs ou actifs

Actionneurs passifs ou actifs Système informatique de contrôle Procédé à contrôler

Interfaces de communications

(série, parallèle)

Mesures Événements Commandes

Affichages Interface d'entrées / sorties numériques et analogiques

Actions

Organe de dialogue

Opérateur

Base de données Réseaux

Affichage Consignes

Sauveg arde de l'état du procédé

Procédé physique externe Calculateur

Systèmes d'affichage Commandes directes

1.2.1 Exemple 1 : l’ordonnancement des tâches doit faire respecter les échéances

Le robot mobile déposé sur la planète Mars en juillet 1997 par la mission Pathfinder a rempli avec succès sa mission, en particulier l’envoi de vues panoramiques de la planète. Mais, au bout de quel- ques jours, au moment d’envoyer des données météorologiques, le calculateur embarqué est tombé en panne et s’est entièrement réini- tialisé à plusieurs reprises. La presse a rendu compte de ces pannes en rapportant que le calculateur essayait de faire trop de choses à la fois. En fait, l’analyse détaillée de ces ennuis a montré qu’ils prove- naient d’une erreur d’ordonnancement causée par un phénomène connu, l’inversion de priorité, que l’exécutif temps réel utilisé possé- dait le mécanisme qui permettait de le circonscrire, à savoir l’héri- tage de priorité, mais que les ingénieurs chargés de la mission ne l’avaient pas utilisé par crainte du surcoût temporel entraîné par ce mécanisme.

Le scénario exact fut le suivant. La tâche préparant les données météorologiques à envoyer se déroulait à faible priorité et utilisait en exclusion mutuelle la voie d’accès aux données stockées ; pen- dant son exécution, la tâche d’acquisition de nouvelles données, très prioritaire, s’est déclenchée et a pris la main jusqu’au moment où elle a buté sur la voie d’accès aux données stockées, déjà utilisée et non réquisitionnable ; elle s’est donc bloquée en attente de libéra- tion de cette voie d’accès. Ce comportement était prévu, mais la suite n’avait pas été rencontrée lors de tests et avait été jugée improbable. En effet, c’est une troisième tâche déclenchée, de prio- rité moyenne car consacrée à l’enregistrement de données météo- rologiques, que l’ordonnancement a activée pour une longue durée, et non pas la tâche qui occupait la voie d’accès. Comme, en consé- quence, l’échéance de la tâche d’acquisition, très prioritaire et très importante pour la mission, n’a pas été respectée, une alerte s’est déclenchée ; le module de contrôle a cru déceler une panne grave et a lancé la réinitialisation du système.

Cet exemple montre que l’objectif d’un ordonnancement temps réel n’est pas de gagner du temps mais de savoir faire respecter par les tâches les échéances posées par le problème. On verra plus loin ce que sont l’inversion de priorité et le mécanisme d’héritage de priorité.

1.2.2 Exemple 2 : l’ordonnancement des tâches doit tenir compte de l’importance des tâches en cas de surcharge

La manœuvre automatisée de mobiles, que ce soit un bateau arri- vant à quai ou un train devant s’arrêter avant un butoir, est rendue difficile par l’existence d’une forte inertie à vaincre avant de pouvoir arrêter le mobile. La tâche chargée du freinage doit avoir alors une grande importance, plus grande que toute autre, y compris la tâche de blocage de la fermeture des portes. Cependant en haute mer ou entre deux gares, il est plus vital de maintenir les portes fermées. On doit pouvoir spécifier des priorités d’actions en fonction du contexte observé.

L’aide aux décisions prises par des pompiers relève du même besoin de spécifier dynamiquement l’importance des interventions.

En général, il est moins urgent de délivrer une personne bloquée dans un ascenseur que de dégager une route coupée par des arbres qui viennent d’être abattus par un orage et qui empêchent le pas-

sage des ambulances ou des véhicules de secours. C’est vrai tant que la personne n’est pas bloquée au sous-sol d’un immeuble qui est envahi par les eaux d’un torrent gonflées par l’orage.

1.2.3 Exemple 3 : l’ordonnancement des tâches doit, en cas de panne, contrôler

la dégradation de performances

Le pilotage d’un mobile se fait par quatre moteurs commandés par asservissement échantillonné. Le système temps réel est com- posé de quatre tâches périodiques qui ont des échéances strictes et qui tournent sur quatre processeurs en utilisant chacune 60 % du temps de chaque processeur. En cas de panne d’un processeur, on ne peut ni faire tourner deux tâches sur un même processeur ni changer la fréquence d’échantillonnage. La seule solution, dans ce cas, consiste à supprimer un échantillon sur quatre pour chacune des quatre tâches à tour de rôle et à faire migrer l’une des tâches d’un processeur à un autre pour y exécuter ses échantillons dans le temps libéré. Le mobile reste pilotable, même si le confort des pas- sagers est moins bon parce que le mobile est moins manœuvrable.

1.2.4 Exemple 4 : l’ordonnancement des tâches doit pouvoir résorber les surcharges

Une gestion de trafic urbain repose sur trois processeurs qui déroulent périodiquement, toutes les 0,3 secondes, trois tâches d’analyse occupant chacune jusqu’à 60 % du temps de chaque pro- cesseur. Devant le succès de cette gestion du régime permanent et la charge raisonnable des processeurs, on souhaite l’étendre à la gestion de situations de surcharge causées par des cas urgents (police, pompiers, officiels) ou par des pointes de trafic. Pour cela, il faut ajouter une tâche de recherche d’itinéraire, une tâche de com- mande des feux et une tâche de suivi des voitures de pompiers. Ces tâches ajoutées font passer la charge totale à 275 % (pour trois pro- cesseurs, on est au-dessous de 300 %), mais les contraintes de période et d’échéance sont telles qu’on ne peut trouver un place- ment statique des tâches et qu’on ne peut s’en sortir qu’en plaçant dynamiquement sur des processeurs différents les requêtes succes- sives des tâches ajoutées. Cette adaptation aux surcharges n’est possible que si l’on dispose d’un exécutif qui sache gérer le place- ment dynamique des requêtes.

1.2.5 Exemple 5 : l’ordonnancement des messages doit prendre en compte les contraintes de temps

Le mélange de scènes actuelles et de scènes d’archives dans une émission de télévision interactive entraîne l’appel, à la demande des auditeurs, d’images vidéo stockées dans une médiathèque. Cette banque d’images est située sur un site serveur qui doit envoyer au site pilote de l’émission un flux régulier d’images accompagnées par leur son bien synchronisé. Les flux de messages pour le son et l’image ont des contraintes de délai, de régularité et de synchro- nisme qui doivent être prises en considération par l’ordonnance- ment temps réel des messages.

2. Définitions et notions générales

2.1 Architecture des applications temps réel

2.1.1 Démarche d’analyse et de construction

Il est habituel de dégager des étapes pour analyser et construire une application. On distingue souvent :

— l’établissement du cahier des charges et des spécifications fonctionnelles et temporelles qui sont à l’origine d’une organisation fonctionnelle (on essaie de répondre à la question : que faire ?) ;

— l’analyse opérationnelle accompagnée du choix des unités logiques, ce qui aboutit à une architecture logique (c’est la question : comment faire ?) ;

— l’analyse organique et le choix des matériels qui débouchent sur une architecture physique (la question : avec quels moyens ?).

Une fois définies les architectures logique et matérielle se pose alors la politique de répartition du logiciel sur le matériel, ce qu’on appelle le placement. Dans les systèmes temps réel répartis, nous serons concernés par le placement des tâches et par leur éventuelle migration.

L’analyse opérationnelle doit déterminer des entités logiques de base pour traduire le découpage des charges et, ce qui nous con- cerne ici, pour exprimer la concurrence entre les actions réalisant

les fonctions demandées. Le comportement opérationnel de l’appli- cation résulte de leur exécution concurrente.

Les principales entités informatiques de base sont souvent clas- sées en :

— objets passifs : ressources physiques (matériels informati- ques, capteurs, commandes des actionneurs) et ressources logi- ques (zones de mémoire, fichiers, logiciels de base) ;

— objets de communication : messages ou variables partagées, porte (« port »), canaux, réseaux ;

— objets de synchronisation : événements, sémaphores, condi- tions, moniteurs (Modula), rendez-vous et objets protégés (Ada) ;

— objets actifs : processus (process), activités (thread), tâches (task) ;

— objets de structuration, de composition ou de regroupement d’entités : module, paquetage (Ada), acteur (Chorus), processus (Unix, Mach).

Le terme de tâche est le plus souvent utilisé dans le domaine du temps réel comme unité de représentation des activités concurren- tes de l’architecture logique.

Pour découper une application en tâches concurrentes, on exa- mine habituellement le parallélisme physique présent dans l’archi- tecture support et le parallélisme logique de l’application. On peut ainsi associer une tâche à chaque processeur et à chaque organe d’entrée ou sortie : lecteur de disque, imprimante, clavier, écran, actionneur, capteur. On peut encore associer une tâche à chaque activité de fonctionnalité différente : calcul, acquisition, présenta- tion, client, serveur, gestionnaire d’objets, ou à chaque activité de comportement différent : périodique, apériodique, réactive, cycli- que, selon échéance ou importance.

Figure 2 – Architecture physique monoprocesseur de Mars Pathfinder

Processeur Mémoires Interface 1 Interface 2

Interface bus

Coupleur Interface 1

Interface 5

Coupleur Interface 6 Interface 7

Moteurs Vannes Capteur

solaire Analyseur étoiles Interface 2 Interface 3 Interface 4 Module satellisé autour de MARS

Module posé sur MARS

Caméra

Radio

Accéléromètre

Enregistreur météo (ASI/MET) Altimètre

Bus VME

Bus 1 553

Bus 1 553

2.1.2 Architecture physique

Les architectures matérielles pour le temps réel sont caractérisées par l’importance des entrées-sorties pour le temps réel (par exem- ple, le bus VME sur les figures 2 et 3).

Nous avons cité au paragraphe 1.2 le cas du robot mobile de la mission Pathfinder. Le calculateur embarqué avait la configuration donnée sur la figure 2.

La figure 3 représente une architecture multiprocesseur à mémoire commune [3].

Les architectures distribuées en réseau se développent de plus en plus. L’article [S 8 056] Ordonnancement temps réel réparti de ce traité les prend en compte. On utilise le terme de sites interconnec-

tés. La figure 4 donne le schéma d’une architecture de plusieurs sites interconnectés par un réseau local.

2.1.3 Architecture logique et systèmes informatiques temps réel

2.1.3.1 Systèmes informatiques

Afin de situer les systèmes temps réel, nous faisons un très bref rappel sur les systèmes informatiques que l’on peut classer, comme dans l’encadré 1, en systèmes transformationnels, interactifs et réactifs, ces derniers incluant le temps réel asynchrone.

Figure 3 – Architecture multiprocesseur Dune 3000

Figure 4 – Architecture répartie pour temps réel

Activation processeur Interruptions VME

BUS VME

BUS MÉMOIRE C

P U 1

C P U 4

M E M 1

M E M 6

I N T E R

V M E B D

I / O B D

... ...

V M E B D

CPU1...CPU4 : processeurs MEM1...MEM6 : mémoires partagées VMEBD, I/OBD : coupleurs

INTER : centrale d'interruption

Machines-outils Machines-outils

Machines-outils Site

de calculs

Site

réseau Site

stocks Site

archivage Site procédé

Site procédé

Site procédé Site

produits Camions de livraison

Réseau local

Base de données techniques

Manipulateur et convoyeur

Postes opérateurs pour présentation

synoptique

On dira qu’un système est centralisé lorsque les décisions, la ges- tion des ressources, l’algorithmique et la cohérence des données sont déterminées par l’existence d’informations dans une mémoire commune accessible à toutes les tâches du système. Cette défini- tion est indépendante de l’architecture matérielle support. Cela s’applique à une architecture monoprocesseur ou multiprocesseur à mémoire commune, mais aussi à une architecture répartie où toutes les décisions sont prises sur un seul site. On dira qu’un système est réparti lorsque les décisions sont prises après concertation par envoi de messages entre sites. L’algorithmique répartie doit s’adap- ter à un univers incertain qui n’a ni mémoire ni horloge communes à tous les sites, où le délai de propagation des messages est varia- ble d’un site à un autre et d’un message à un autre, où le risque de défaillance est important. Les sites n’ont jamais les mêmes informa-

tions disponibles simultanément, et, comme la date est une de ces informations, ils ne sont pas capables de déterminer instantané- ment, en consultant une horloge, s’ils sont « à la même date ». On retrouvera plus en détail ces points dans l’article [S 8 056] sur l’ordonnancement réparti de ce traité.

Les systèmes informatiques sont structurés en couches de manière à faciliter leur évolution. Ils comportent tous un noyau exé- cutif comme le montre la figure 5. Ce noyau comprend les mécanis- mes pour la gestion de base du processeur, de la mémoire virtuelle, des interruptions et des communications. Les politiques de gestion plus élaborées pour l’allocation globale de ces ressources, la ges- tion des autres ressources, se retrouvent dans les couches supérieu- res.

Les systèmes informatiques classiques prennent des décisions d’allocation de ressource et, en particulier, d’ordonnancement des tâches, en appliquant des politiques globales en vue d’optimiser l’utilisation des ressources ou de favoriser le temps de réponse de certaines catégories de tâches, comme les tâches interactives. Tou- tes les tâches sont considérées comme apériodiques ; ni leurs dates d’arrivées, ni leurs durées ne sont connues et elles n’ont pas d’échéances.

Dans un système classique, les ressources partagées allouées dynamiquement aux tâches sont principalement la mémoire princi- pale et le processeur. Les études de comportement de programme ont montré que la ressource sensible était la mémoire centrale (c’est encore plus sensible dans un système paginé avec va-et-vient entre mémoire principale et disque). Aussi alloue-t-on d’abord la mémoire selon des algorithmes d’allocation souvent compliqués ; le processeur est alloué en dernier. Cet ordre d’allocation entraîne la relative simplicité de l’ordonnancement du processeur qui ne porte que sur le petit nombre de tâches déjà servies en mémoire [5] [64].

2.1.3.2 Les exécutifs temps réel

Dans un système temps réel, les ressources, autres que le proces- seur, sont souvent attribuées statiquement aux tâches, au moment de leur création. En particulier, on ne peut accepter la perte de temps que cause l’allocation dynamique de la mémoire. Les fichiers temps réel et les bases de données temps réel sont en mémoire cen- trale. Le principal paramètre d’allocation est le temps processeur, ce qui explique que le noyau prend une grande importance dans les schémas de présentation et que l’on utilise plutôt le terme d’exécutif temps réel (figure 6).

Figure 5 – Architecture d’un système informatique

Programmes et tâches de l'application Plate-forme professionnelle

Services du système d'exploitation

Noyau exécutif

Matériel

Bibliothèques de programmes Base de données Messagerie

Gestion des tâches

Sémaphores

Gestion de l'horloge Gestion MMU Pilotes périphériques Pilotes réseaux Gestion des interruptions Ordonnancement des processeurs

Gestion de mémoire Gestion de fichiers Gestion d'objets Service de noms Interfaces Homme-machine

API spécifiques plate-forme

API systèmes spécifiques

API systèmes standardisées (POSIX...)

MMU : Memory Management Unit API : Application Programming Interface

Encadré 1 − Classes de systèmes informatiques Systèmes transformationnels

Ils gèrent des programmes dont :

— les résultats sont calculés à partir de données disponibles dès l’initialisation du programme ;

— les instants de production des résultats ne sont pas con- traints.

Systèmes interactifs

Ils gèrent des programmes dont :

— les résultats sont fonction de données produites par l’envi- ronnement du programmeur ;

— les instants de production des résultats ne sont pas contraints :

•temps partagé : assurer un temps de réponse court pour des demandes indépendantes (édition, compilation, calcul, consultation multimédia),

•transactionnel : garantir le contrôle et la cohérence d’accès à des « fichiers » partagés (bases de données) en consultation et mise à jour.

Systèmes réactifs

Ils gèrent des programmes dont :

— les résultats sont fonction de données produites par l’envi- ronnement (le procédé à contrôler) ;

— les instants de production des résultats sont contraints par la dynamique du procédé contrôlé :

•temps réel : contrôle de processus industriels, de trafic, de production.

2.2 Caractéristiques des tâches

2.2.1 Modèle canonique des tâches temps réel

Les tâches sont les entités de base de l’ordonnancement temps réel et elles sont périodiques ou apériodiques, à contraintes tempo- relles strictes ou relatives. Aussi a-t-on défini un modèle canonique qui regroupe les principaux paramètres temporels qui peuvent caractériser les tâches temps réel et guider l’ordonnancement temps réel. Dans ce modèle, une tâche (figure 7) est définie par des paramètres chronologiques qui dénotent des délais et des paramè- tres chronométriques qui indiquent des dates, soit :

r, sa date de réveil, c’est-à-dire le moment de déclenchement de la requête d’exécution ;

C, sa durée d’exécution maximale quand elle dispose du proces- seur pour elle seule ;

R, son délai critique, c’est-à-dire le délai maximal acceptable pour son exécution ;

P, sa période lorsqu’il s’agit d’une tâche périodique.

Pour une tâche à contraintes strictes, le délai critique permet de calculer l’échéance d = r + R ; c’est la date dont le dépassement entraîne une faute temporelle.

Quand la tâche est à contrainte relative, le délai critique R est par- fois omis.

Pour une tâche apériodique, le paramètre P n’est pas donné.

Lorsque la tâche est périodique, les quatre paramètres sont pré- sents. Chaque réveil déclenche une requête de la tâche périodique.

Ses dates de réveil successives, celles de chaque requête, sont : rk = r0 + kP

avec r₀ premier réveil, rk k^e réveil.

Ses échéances successives sont : dk = rk + R

Si R = P, la tâche périodique est à échéance sur requête.

Une tâche est bien formée quand :

La qualité de l’ordonnancement sera d’autant meilleure que les valeurs de ces paramètres seront exactes ; aussi la détermination de ces paramètres est-elle souvent un aspect important de l’analyse et de la conception d’une application temps réel. En particulier, il faut savoir si l’on néglige ou non les temps de commutation de tâches, les durées d’utilisation des primitives du système d’exploitation, les durées de prise en compte des interruptions et les durées d’exécu- tion de l’ordonnanceur. Si l’on ne peut les négliger, l’analyse con- ceptuelle doit les estimer et les inclure dans la durée d’exécution de la tâche.

C’est pourquoi on demande à un noyau exécutif temps réel d’avoir un comportement prédictible, ce qui se traduit en exigence de valeurs maximales garanties pour le temps de commutation de tâches, le temps de prise en compte d’une interruption et le temps d’exécution des services du système (les primitives ou les API).

D’autres paramètres, dérivés des paramètres de base, servent à suivre l’exécution de la tâche :

u = C/P est le facteur d’utilisation du processeur pendant la période ; on doit avoir ;

ch = C/R est le facteur de charge du processeur ; on doit avoir ;

s est la date du début de l’exécution de la tâche ;

e est la date de la fin de l’exécution de la tâche ; on a ; R(t) = d − t est le délai critique résiduel ou délai critique dynami- que à la date t ; on a ;

C(t) est la durée d’exécution résiduelle à la date t ; on a ;

LN = R − C est la laxité nominale de la tâche et indique le retard maximal pour son début d’exécution s quand la tâche s’exécute seule ;

LN(t) = R(t) − C(t) est la laxité nominale résiduelle ou laxité dynamique ; c’est le retard maximal pour reprendre l’exécution quand la tâche s’exécute seule ; on a encore LN(t) = R + r − t − C(t) ; TR = e − r est le temps de réponse de la tâche ; on a

;

CH(t) = C(t)/R(t) est la charge résiduelle ; on a (par définition si e = d, CH(e) = 0).

Figure 6 – Application temps réel Procédé

Tâches

Système informatique temps réel Système de contrôle

Exécutif temps réel Gestion des tâches, des interruptions,

des messages, ordonnanceur

Actionneurs Capteurs

Figure 7 – Modèle canonique des tâches 0 B C B R B P

u B 1 ch B 1

e b s+C 0 B R t( ) B R

0 B C t( ) B C

C B TR B R

0 B CH t( ) B u

Temps

Une tâche est définie par :

r Date de déclenchement de la requête Déclenchement

Échéance r + R r + P

r

C Durée d'exécution R Délai critique P Période de la tâche

0< C < R < P C

P R

Les tâches périodiques sont déclenchées à la date de réveil des requêtes successives et redeviennent passives une fois la requête terminée. Les tâches apériodiques peuvent avoir le même compor- tement si elles peuvent se déclencher plusieurs fois ; elles peuvent aussi plus rarement être créées au moment du réveil. Une tâche créée évolue entre deux états : passive et déclenchée.

Le partage du processeur et des ressources introduit plusieurs états pour une tâche déclenchée (figure 8) :

élue : un processeur est alloué à la tâche et elle exécute son programme ; C(t) diminue ;

bloquée : la tâche attend une ressource, un message ou un signal de synchronisation ;

prête : la tâche attend d’être élue.

2.2.2 Autres caractéristiques des tâches

En dehors des paramètres temporels du modèle canonique, d’autres caractéristiques des tâches permettent de les distinguer.

■Tâche préemptible ou non préemptible

Certaines tâches, une fois élues, ne doivent plus être arrêtées avant la fin de la requête. Elles sont non préemptibles. C’est le cas de tâches qui s’exécutent sous le contrôle du mécanisme d’interrup- tion ou de tâches qui effectuent des entrées et sorties directement sur un bus sans passer par un organe intermédiaire appelé DMA. Ce sont des tâches, souvent appelées immédiates, dont l’exécution doit être atomique. Au contraire, quand la tâche élue peut être arrêtée et remise à l’état prêt pour réquisitionner le processeur au profit d’une autre tâche, on dit que la tâche est préemptible.

■Dépendance et indépendance des tâches

Les tâches peuvent interagir selon un ordre partiel prédéterminé ou induit par la communication de message ou par une relation explicite de synchronisation. Il peut alors en résulter une relation de précédence entre tâches. Cette relation est dite statique, car elle est connue a priori et n’évolue pas. Elle est représentée par un graphe de dépendance.

Les tâches peuvent partager d’autres ressources que le proces- seur et certaines ressources, dites exclusives ou critiques, imposent aux tâches de les utiliser en exclusion mutuelle. La suite des instruc- tions d’une tâche pendant laquelle cette exclusion mutuelle doit être respectée est appelée une section critique. Une seule tâche peut se

trouver en section critique pour une ressource donnée. Ce partage de ressources induit une relation dynamique lorsque l’ordre d’utili- sation de la ressource dépend de l’ordre d’exécution des diverses tâches. La relation peut être représentée par un graphe d’allocation.

Lorsque des tâches ont des dépendances statiques ou dynami- ques qui les sérialisent, on introduit la notion de temps de réponse global, appelé aussi délai de bout en bout dans le cas des messa- ges. Il correspond au délai écoulé entre le date de réveil de la tâche qui reçoit le stimulus envoyé par le procédé et la fin de la dernière tâche de la série qui envoie la commande en réaction à ce stimulus.

Les tâches sont dites indépendantes lorsqu’elles n’ont entre elles ni relation de précédence ni partage de ressource critique.

■Priorité externe

On introduit parfois à la conception une priorité fixe dite priorité externe. C’est une forme primitive d’ordonnancement temps réel où tout est déterminé dès la conception par un ordonnancement hors ligne ou par des règles qui imposent un ordre a priori (par exemple, la tâche de gestion d’horloge ou la tâche de sauvegarde en cas de chute de courant sont à exécuter toutes affaires cessantes).

■Gigue maximale

L’exécution de tâches périodique est parfois soumise à des con- traintes de régularité pour le début de leur exécution. C’est le cas dans l’acquisition de données par échantillonnage périodique, ou dans une régulation par PID ou dans l’envoi continu de son et d’ima- ges pour le multimédia. La variation entre le début d’exécution de deux requêtes successives est appelée gigue et on définit pour ces applications une gigue maximale à ne pas dépasser :

Nota : PID : Proportionnel Intégral Dérivé.

■Importance

Lorsque qu’on veut introduire, pour un ensemble de tâches, la capacité de résister aux fautes temporelles de certaines d’entre elles, en évitant, en particulier, que les fautes temporelles ne se pro- pagent, le système de contrôle doit pouvoir supprimer l’exécution de certaines tâches. Il faut lui indiquer quelles tâches il peut suppri- mer en premier ou, au contraire, quelles sont les tâches, primordia- les pour l’application, à ne pas supprimer. On introduit un paramètre d’importance qui traduit la gravité ou la priorité opéra- tionnelle de la tâche. Ainsi deux tâches de même échéance peuvent être distinguées par des importances différentes.

2.2.3 Modèles de tâches pour la tolérance aux fautes temporelles

Plusieurs modèles de tâches ont été introduits pour éviter qu’en cas de faute temporelle tout le travail réalisé par la tâche avant la panne ne soit perdu.

■Dans le plus ancien modèle proposé [9], chaque tâche a deux ver- sions, une version primaire qui fournit le service demandé mais dont l’exécution peut entraîner une faute temporelle parce que la durée d’exécution peut varier considérablement, et une version secondaire qui fournit un service dégradé mais acceptable et sans faute temporelle. Selon les politiques d’ordonnancement, on essaie d’abord l’une ou l’autre version mais, dans tous les cas, il faut que la version secondaire s’exécute sans faute.

■Une autre approche est celle du calcul imprécis (ou progressif ou par contrat) où chaque tâche est décomposée en deux parties, la partie mandataire et la partie optionnelle. La partie mandataire doit obligatoirement s’exécuter dans le respect de son échéance et elle fournit un résultat approché. La partie optionnelle affine ce premier résultat et est exécutée pendant le temps restant avant l’échéance.

Figure 8 – États d’une tâche

Inexistante

Passive

Bloquée Prête

f Élue f

f : cas où la requête est interrompue à son échéance

max B

(

s_i+1Ð(s_i+P)

)

^{B max}

Ð

■Dans une approche récente, une tâche présente plusieurs modes de fonctionnement, un mode normal et un mode de survie qui est exécuté quand une requête est supprimée, soit parce que son échéance est arrivée, soit parce qu’elle a été sacrifiée au profit d’une autre tâche plus importante. Le mode de survie a une durée très courte mais il permet à la tâche de rendre une ressource partagée ou de terminer un calcul dans un état exploitable. L’échéance de la tâche est fixée pour permettre l’exécution du mode normal et du mode de survie [23].

2.3 Ordonnancement temps réel

2.3.1 Configuration de tâches

L’application met en jeu un ensemble de n tâches qu’on appelle une configuration de tâches.

■Départ simultané ou échelonné

Les tâches d’une configuration sont dites à départ simultané si elles ont toutes la même première date de réveil, sinon elles sont à départ échelonné.

■Facteur d’utilisation du processeur

Le facteur d’utilisation du processeur par une configuration est : U =

Σ

^(ui), pour tout i

■Facteur de charge du processeur

Le facteur de charge du processeur par une configuration est : CH =

Σ

^(chi), pour tout i

■Laxité du processeur pour une configuration donnée

À cause des contraintes d’échéances, ni le facteur d’utilisation, ni le facteur de charge ne sont suffisants pour connaître l’incidence d’une surcharge sur le respect des contraintes. On introduit LP(t), la laxité du processeur à l’instant t comme l’intervalle de temps maxi- mal pendant lequel le processeur peut rester inactif à partir de la date t, sans perdre le respect des échéances des tâches de la confi- guration.

LP(t) varie en fonction de t. Il faut que l’on ait : , pour tout t

Pour calculer cette laxité, il faut connaître la séquence de planifi- cation des tâches et, dans le contexte de cette séquence, calculer la laxité conditionnelle LC_i(t) de chaque tâche i ;

LC_i(t) = R_i −

Σ

^Cj(t)

où la somme en j se fait sur toutes les tâches qui sont déclenchées à la date t et qui sont devant la tâche i dans la séquence de planifica- tion, et prendre LP(t) comme la plus petite des laxités conditionnel- les LCi(t).

■Temps creux du processeur

On dénote la suite des intervalles de temps où la laxité du sys- tème reste strictement positive comme la suite des temps creux.

Cette suite dépend de la configuration de tâches et de son ordon- nancement.

2.3.2 Définition du problème d’ordonnancement des tâches

Le système de conduite d’une application temps réel doit piloter le procédé en ordonnançant les tâches avec deux objectifs majeurs :

— en fonctionnement nominal, assurer le respect des contraintes temporelles spécifiées ;

— en fonctionnement anormal dû à des pannes matérielles ou à d’autres événements imprévus, atténuer les effets des surcharges temporelles et maintenir le procédé dans un état cohérent et sécuri- taire.

Ordonnancer les tâches d’une application temps réel consiste alors à planifier l’exécution de requêtes de façon que soient respec- tées les contraintes de temps :

— de toutes les requêtes en fonctionnement nominal ;

— d’au moins les requêtes les plus importantes, c’est-à-dire cel- les qui sont nécessaires à la sécurité du procédé, en fonctionnement anormal.

Selon les applications, on cherche en plus à satisfaire certains cri- tères de performance comme minimiser le temps de réponse ou réduire la gigue de certaines tâches, équilibrer la charge des sites, minimiser la charge de communication, minimiser le nombre ou le retard cumulé des tâches ou des messages tardifs.

Cette planification est faite par un algorithme d’ordonnancement qui fournit une description de la séquence à effectuer par les tâches, appelée séquence de planification.

2.3.3 Nature des algorithmes d’ordonnancement

■En ligne ou hors ligne

On distingue les algorithmes hors ligne et les algorithmes en ligne.

Un algorithme d’ordonnancement hors ligne construit une séquence complète de planification sur la base de tous les paramè- tres temporels de tâches. Cette séquence est connue avant l’exécu- tion des tâches et peut être mise en œuvre très efficacement.

Toutefois, cette approche statique est très rigide ; elle suppose que tous les paramètres, y compris les dates de réveil, soient figés et ne peut s’adapter aux changements de l’environnement.

Un algorithme d’ordonnancement en ligne est capable, à tout ins- tant de l’exécution de l’application, de choisir la prochaine tâche à ordonnancer et il utilise comme informations les paramètres tempo- rels des tâches déclenchées à cet instant. Ce choix peut être remis en cause lors de l’occurrence d’un événement nouveau sans que la date de cette occurrence n’ait à être connue à l’avance. Cette appro- che dynamique donne des solutions qui sont moins bonnes que cel- les de l’approche statique puisqu’on utilise moins d’information et les surcoûts de mise en œuvre sont plus importants. Mais elle per- met l’arrivée imprévisible de tâches et elle autorise la création pro- gressive de la séquence d’ordonnancement.

Pour pouvoir traiter les tâches apériodiques et les surcharges anormales, l’ordonnancement temps réel se fait en ligne le plus sou- vent.

■Préemptif ou non préemptif

Un algorithme d’ordonnancement est soit préemptif soit non préemptif.

Dans le premier cas, une tâche élue peut perdre le processeur au profit d’une autre tâche jugée plus urgente ou plus prioritaire ; elle passe à l’état prêt pour attendre d’être élue ultérieurement sur le même processeur ou sur un autre. Un algorithme préemptif n’est utilisable que si toutes les tâches sont préemptives.

Les ordonnanceurs non préemptifs n’arrêtent pas l’exécution des tâches élues. Il peut en résulter des temps de réponse plus longs qu’avec un ordonnancement préemptif. En architecture monopro- cesseur, la gestion des ressources critiques est simplifiée car elle ne nécessite plus de mécanisme de gestion de concurrence d’accès aux ressources (mécanismes d’exclusion mutuelle et de file d’attente) ; toutefois cette simplification n’est plus vraie en architec- ture multiprocesseur.

LP t( ) b 0

■Meilleur effort ou inclémence aux fautes temporelles

Pour une application à contraintes temporelles relatives, on dit que la stratégie d’ordonnancement est celle du meilleur effort : elle essaie de faire au mieux avec les processeurs disponibles. L’applica- tion a des facultés de tolérance aux fautes temporelles.

Pour une application à contraintes strictes, la stratégie d’ordon- nancement doit garantir le respect des contraintes. Il y a obligation de réussite et inclémence aux fautes temporelles.

■Centralisé ou réparti

L’ordonnancement est centralisé s’il s’exécute sur une architec- ture centralisée ou sur un site privilégié de l’architecture distribuée qui contient l’ensemble des paramètres des tâches. L’ordonnance- ment est réparti lorsque des décisions d’ordonnancement sont pri- ses sur chaque site par un ordonnancement local après une éventuelle coopération pour effectuer un ordonnancement global.

Dans ce dernier cas peut intervenir le placement des tâches sur un site et leur migration d’un site à un autre.

2.3.4 Propriétés des algorithmes

■Séquence valide

Un algorithme d’ordonnancement délivre une séquence d’ordon- nancement pour une configuration de tâches données.

Cette séquence est valide si toutes les tâches de la configuration respectent leurs contraintes.

■Configuration ordonnançable

Une configuration de tâches est ordonnançable dès qu’il existe un algorithme au moins capable de fournir une séquence valide pour cette configuration.

■Algorithme optimal

Un algorithme est optimal s’il est capable de produire une séquence valide pour toute configuration de tâche ordonnançable.

■Test d’acceptabilité

Un algorithme en ligne crée ou modifie la séquence dynamique- ment à l’arrivée de nouvelles tâches ou à la suite de dépassement d’échéance. Une tâche nouvelle peut être ajoutée à la séquence déjà formée, ou en cours de modification à la suite de suppression, et être acceptée s’il existe au moins une séquence pour laquelle toutes les tâches précédemment acceptées et cette tâche nouvelle peuvent terminer leur exécution avant leur échéance. L’ensemble des condi- tions à satisfaire est appelé test d’acceptabilité. On dit parfois test de garantie car, si les tâches ne dépassent pas leurs durées d’exécu- tion (auxquelles s’ajoutent les durées d’attente pour obtenir les res- sources critiques), on peut garantir alors que les tâches ne font pas de faute temporelle.

Dans un ordonnancement réparti, le rejet d’une tâche par un test d’ordonnançabilité sur un site peut avoir comme conséquence d’essayer de faire migrer la tâche.

■Période d’étude

L’étude pour valider une configuration de tâches périodiques et apériodiques conduit à faire une analyse temporelle de l’exécution de cette configuration. Quand les tâches sont périodiques, cette exé- cution dure indéfiniment. En fait, le comportement de la configura- tion est périodique et il suffit d’en analyser une période dite période d’étude, ou pseudo-période ou période de validation [40].

La période d’étude commence à la première date de réveil d’une tâche de la configuration :

min(r0i) pour toutes les tâches i de la configuration.

Elle se termine à une date qui est fonction du plus petit commun multiple des périodes Pi :

— pour une configuration de tâches périodiques, c’est la date : max(r_0i) + PPCM(P_i)

pour toutes les tâches i de la configuration ;

— pour une configuration de tâches périodiques et apériodiques, c’est la date :

max(r0i, r0j + Rj) + 2 PPCM(Pi) pour toutes les tâches périodiques i et apériodiques j.

2.3.5 Typologie des techniques d’ordonnancement

La mise en œuvre de l’ordonnancement fait appel aux structures de données classiques en informatique.

■Table d’élection

Lorsque la séquence de planification est fixée avant le démarrage de la configuration, cas de l’ordonnancement hors ligne, cette séquence définitive peut être inscrite dans une table que l’ordon- nanceur consulte pour élire la prochaine tâche.

■Liste d’attente avec priorité

L’ordonnancement en ligne crée dynamiquement une séquence de planification dont le premier élément indique la tâche élue (dans une architecture à n processeurs, ce sont les n premiers éléments qui sont élus). Cette séquence est une liste ordonnée par une rela- tion d’ordre sur des clés où la recherche (et la suppression) se fait sur l’élément de clé minimal et où l’ajout d’un élément se fait par insertion dans la liste triée selon les clés. Cette structure est classi- quement appelée un tas ou une liste d’attente avec priorité [12].

■Priorité constante ou variable

La clé d’un élément, appelée priorité dans le cas des tâches, est un paramètre temporel du modèle de tâches ou une combinaison de paramètres. Elle reste constante si l’on prend un paramètre fixe comme la durée d’exécution, le délai critique, la période ou une priorité externe. Elle est variable si l’on prend un paramètre qui varie au cours de l’exécution d’une tâche comme le délai critique résiduel, la durée d’exécution résiduelle ou la laxité résiduelle, ou encore un paramètre qui varie d’une requête à une autre comme la date de réveil ou l’échéance.

La priorité ou clé de classement peut être la valeur du paramètre retenu ou, si l’ensemble des valeurs est trop grand, une fonction injective de cette valeur. C’est cela qu’on appelle usuellement la priorité.

L’ensemble des valeurs de la priorité peut être fixé a priori dans une architecture matérielle ou dans un noyau d’exécutif temps réel.

Cela permet d’accélérer la gestion des files d’attente en codant cette priorité avec un mot de taille fixée (de type octet ou entier) ou en uti- lisant des instructions machine spéciales.

■Ordonnancement à deux niveaux

Dans les ordonnanceurs complexes, l’ordonnancement est découpé en deux parties, l’une qui élabore la politique (décisions de haut niveau ou à long terme, choix de suppression de tâches en cas de surcharge, volonté de favoriser momentanément certaines tâches dans un ordonnancement hiérarchique), l’autre qui exécute les mécanismes finaux (élection d’une tâche dans le sous-ensemble défini par l’ordonnanceur de haut niveau, réorganisation de ce sous- ensemble par des choix à court terme).

Un cas particulier de découpage est celui de l’ordonnancement réparti où l’on distingue l’ordonnancement local qui traite les tâches présentes sur un site et l’ordonnancement global qui décide du pla- cement et de la migration des tâches. Dans ce cadre se pose encore le choix de l’ordre entre ordonnancement global et ordonnance- ment local et le coût de chaque choix : faut-il placer les tâches a priori puis les faire migrer si le site de placement est surchargé,

ou faut-il interroger les sites sur leur capacité d’accueil avant de pla- cer une tâche (ou une requête) déclenchée ?

2.3.6 Inversion de priorité

Dans un ordonnancement préemptif, la présence simultanée de priorités fixes et de ressources à accès exclusif peut entraîner un phénomène appelé inversion de priorité (figure 9) [36] [56].

Comme les utilisations de ressources critiques sont souvent imbriquées, toute solution à ce problème doit en tenir compte.

2.3.7 Interblocage

Supposons que les deux tâches T1 et T2 ont besoin chacune de deux ressources exclusives et et que ces ressources ne peu- vent pas être retirées à une tâche qui les utilise en section critique.

Si T1 demande successivement et et si T2, au contraire, demande puis , les deux tâches peuvent parfois s’attendre mutuellement indéfiniment comme dans le cas décrit sur la figure 10 a. C’est une situation d’interblocage, qui peut se générali- ser à tous les cas d’attente circulaire entre plusieurs tâches, et dont on ne peut sortir qu’en détruisant une ou plusieurs tâches.

Pour une application temps réel, c’est une situation inacceptable.

Une méthode, appelée la méthode des classes ordonnées, permet

d’éviter que l’interblocage puisse se produire, en programmant la demande des ressources selon le même ordre pour toutes les tâches [29]. Elle n’est applicable que si l’on connaît, dès la program- mation, toutes les ressources que les tâches vont appeler. C’est pourquoi on dit que c’est une méthode de prévention statique.

Dans l’exemple de la figure 10 b, l’interblocage ne peut jamais se produire si les deux tâches demandent puis .

3. Ordonnancement monoprocesseur

3.1 Approches et techniques classiques pour l’ordonnancement de tâches

3.1.1 Objectifs de l’ordonnancement dans un système classique

Dans un système multiprogrammé classique, les principaux rôles de l’ordonnancement sont au nombre de deux. Ce sont :

— maximiser le taux d’occupation du processeur, c’est-à-dire le rapport entre le temps où le processeur est actif et le temps total. En théorie, ce taux peut varier entre 0 % et 100 % ; dans la pratique, on peut observer un taux d’occupation variant entre 40 % et 95 % ;

— minimiser le temps de réponse des tâches, c’est-à-dire la durée séparant l’instant de soumission de la tâche au système de la fin d’exécution de la tâche. Au mieux, le temps de réponse peut être exactement égal au temps d’exécution de la tâche, lorsque la tâche a immédiatement été élue et s’est exécutée sans être préemptée.

L’obtention de ces deux résultats par une politique d’ordonnance- ment donnée peut être directement évaluée par le calcul du taux d’occupation et par le calcul des temps de réponse, mais il existe d’autres critères d’évaluation qui s’y rapportent également. Nous en citons quelques-uns ci-dessous :

Figure 9 – Inversion de priorité 5

5 Tâche T1

Tâche T2

Tâche T3

Tâche T4 Niveau de priorité

croissant

Délai ajouté par l'inversion

de priorité Faute temporelle

Tâche élue

Tâche élue occupant la ressource Tâche terminée

Déclenchement de tâche Échéance

Tâche demandant la ressource

Exemple : soit quatre tâches de priorité décroissantes, T1, T2, T3 et T4. À un instant donné seule T4 est déclenchée et a obtenu une res- source critique. Puis T1, T2 et T3 sont réveillées par un événement externe. L’ordonnanceur préemptif à priorités élit T1. Supposons que T1 réclame la ressource critique déjà allouée à T4. Comme cette res- source ne peut être réquisitionnée pour T1, cette tâche doit attendre que T4 la libère. L’ordonnanceur à priorité élit donc T2, puis T3, qui s’exécutent. Ce n’est qu’après leur exécution que l’ordonnanceur peut élire T4 qui peut alors finir d’utiliser la ressource critique et, enfin, la libérer. Et seulement alors, T1, la tâche la plus prioritaire, peut s’exécu- ter. Le temps de réponse de T1 s’est rallongé du temps d’exécution de T2 et T3, moins prioritaires qu’elle. Cela peut parfois entraîner un dépassement d’échéance, comme on l’a vu dans l’exemple de Pathfin- der dans le paragraphe 1.2.

r1 r2 r1 r2 r2 r1

r1 r2

— évaluation du temps d’attente des tâches, c’est-à-dire du temps passé dans l’état prêt ;

— évaluation de la capacité de traitement ou du débit du proces- seur, c’est-à-dire du nombre moyen de tâches traitées par unité de temps ;

— temps de traitement total d’un ensemble de tâches donné ;

— temps de réponse moyen d’un ensemble de tâches donné, c’est-à-dire la moyenne des temps de réponse de chacune des tâches de l’ensemble.

3.1.2 Principales politiques

La politique d’ordonnancement du processeur détermine quelle tâche présente dans la file des tâches prêtes est élue. Nous allons décrire ci-dessous les principales politiques mises en œuvre dans les systèmes classiques.

■Politique d’ordonnancement « premier arrivé, premier servi » C’est une politique à l’ancienneté, sans réquisition ; l’unité cen- trale est allouée selon l’ordre de soumission des tâches. Dans cette politique, des tâches de faible temps d’exécution peuvent être péna- lisées parce qu’une tâche de longue durée les précède dans la file.

■Politique d’ordonnancement « plus court d’abord »

Cette politique tente de remédier à l’inconvénient mentionné pour la politique précédente. Maintenant, l’unité centrale est allouée à la tâche de plus petit temps d’exécution. Cette politique est également une politique sans réquisition. Elle a la propriété de minimiser le temps de réponse moyen pour l’ensemble des algorithmes d’ordon- nancement sans réquisition. Elle pénalise les travaux longs. Elle impose également d’estimer la durée des tâches, ce que l’on ne connaît pas habituellement.

Il existe une version avec réquisition de cette politique, appelée

« temps restant le plus court d’abord » : dans ce cas, la tâche en exé- cution restitue le processeur lorsqu’une nouvelle tâche de temps d’exécution inférieur à son temps d’exécution restant devient prête.

■Politique d’ordonnancement par tourniquet (Round Robin) On définit une tranche de temps appelée quantum qui peut varier de 10 ms à 100 ms. Chaque tâche présente dans la file des tâches prêtes acquiert le processeur à tour de rôle, et ce pour au maximum un temps égal au quantum de temps. Si la tâche a terminé son exé- cution avant la fin du quantum, elle libère le processeur et la tâche suivante dans la file des tâches prêtes est élue. Si la tâche n’a pas terminé son exécution avant la fin du quantum, elle perd le proces- seur et est réinsérée en fin de file des tâches prêtes. Cette politique du tourniquet est usuellement utilisée dans les systèmes en temps partagé. Sa performance dépend largement de la taille du quantum.

Un quantum trop grand augmente les temps de réponse alors qu’un quantum trop petit multiplie les commutations de contexte jusqu’à les rendre non négligeables.

■Politique d’ordonnancement par priorités constantes

Un niveau de priorité constant est affecté à chaque tâche et, à un instant donné, la tâche élue est toujours celle de plus forte priorité.

Cet algorithme présente une version sans réquisition et une version avec réquisition. Le défaut de cette politique est le risque de

« famine » encouru par les tâches de faible priorité. Une solution à ce problème est de faire « vieillir » la priorité des tâches en attente, c’est-à-dire d’augmenter celle-ci en fonction du temps d’attente. La priorité des tâches devient ainsi variable.

■Politique d’ordonnancement par files de priorités constantes multiniveaux avec ou sans extinction de priorité

Les politiques présentées jusqu’à présent utilisent une seule file d’attente des tâches prêtes. On choisit ici de définir plusieurs files de tâches prêtes, chaque file correspondant à un niveau de priorité ; on peut alors avoir n files de priorités différentes variant de 0 à n − 1.

Dans une file donnée, toutes les tâches ont la même priorité et sont servies soit selon une politique à l’ancienneté sans préemption, soit selon une politique de tourniquet. Le quantum peut être différent selon le niveau de priorité de la file. L’ordonnanceur sert d’abord toutes les tâches de la file de priorité n, puis ceux de priorité n − 1 dès que la file de niveau n est vide et ainsi de suite...

On peut définir deux variantes de l’algorithme, fonctions de l’évo- lution de la priorité des tâches :

— les priorités des tâches sont constantes tout au long de leur exécution. À ce moment-là, une tâche en fin de quantum est tou- jours réinsérée dans la même file d’attente, celle correspondant à son niveau de priorité ;

— les priorités des tâches évoluent dynamiquement en fonction du temps de service dont a bénéficié la tâche. Ainsi une tâche de priorité n, à la fin du quantum de la file n, si elle n’a pas terminé son exécution, n’est pas réinsérée dans la file de priorité n, mais dans la file de priorité n − 1. Et ainsi de suite... On cherche ici à minimiser les risques de « famine » pour les tâches de faible priorité, en faisant petit à petit baisser la priorité des tâches de plus forte priorité.

3.1.3 Objectifs de l’ordonnancement dans un système temps réel

Dans un système temps réel, les tâches sont soumises à des con- traintes temporelles plus ou moins fortes, c’est-à-dire que leur exé- cution est assujettie à un délai maximal qui doit être respecté impérativement ou le plus souvent possible.

Le but principal de l’ordonnancement est alors de permettre le respect de ces contraintes temporelles, lorsque l’application s’exé- cute dans un mode courant. L’ordonnancement, de plus, doit être certifiable, c’est-à-dire qu’il doit être possible de prouver a priori le respect des contraintes temporelles des tâches de l’application dans le régime « courant ». Par suite d’incidents, des anomalies au sein du procédé contrôlé peuvent entraîner des réveils de tâches d’alarme ou des variations de temps d’exécution qui font basculer l’application dans un régime de surcharge, marqué par l’occurrence de fautes temporelles. Dans ce régime de surcharge, le but de Figure 10 – Interblocage

52

52

52

52 51

51

51

51

Interblocage Tâche T1

Tâche T1 Tâche T2

Tâche T2

a interblocage

b classes ordonnées Tâche élue

Tâche élue utilisant 51

Tâche élue utilisant 52 Tâche terminée Tâche élue utilisant 51 et 52

l’ordonnancement est alors d’offrir une certaine tolérance aux sur- charges, c’est-à-dire de permettre une exécution des tâches garan- tissant un suivi dégradé mais sécuritaire du procédé.

Il est clair qu’aucune des politiques présentées précédemment ne permet de remplir les deux objectifs d’un ordonnancement temps réel, notamment parce qu’aucune de ces politiques n’intègre la notion d’urgence de la tâche, notion représentée par le délai critique dans le modèle canonique des tâches temps réel.

3.2 Ordonnancement pour la résolution des contraintes temporelles

Les tâches de l’application peuvent être indépendantes ou non les unes des autres. Lorsque les tâches ne sont pas indépendantes, nous considérons deux types de relations : les relations de précé- dence qui conditionnent des débuts d’exécution de tâches par rap- port à des fins d’exécution d’autres tâches et des relations de partage de ressources critiques qui sérialisent les exécutions sur le code des sections critiques.

3.2.1 Ordonnancement de tâches périodiques indépendantes

Les algorithmes d’ordonnancement temps réel sont classés selon la somme des informations qu’ils requièrent pour effectuer la plani- fication des tâches.

On distingue ainsi les algorithmes hors ligne et les algorithmes en ligne.

Un algorithme hors ligne, sur la base de tous les paramètres des tâches à ordonnancer, construit une séquence de planification rigide qui vérifie les contraintes temporelles associées.

Un algorithme en ligne, au contraire, choisit, au cours de la vie du système, la prochaine tâche à ordonnancer. Ce choix se fait sur la base d’une priorité, qui peut avoir été définie soit par le concepteur de l’application (priorité empirique ou externe), soit à partir d’un paramètre temporel de la tâche tel que la période ou le délai criti- que. Dans ce dernier cas, la priorité peut être constante ou variable, c’est-à-dire évoluant en fonction du temps.

3.2.1.1 Algorithmes en ligne à priorité constante

Une priorité constante est une priorité qui ne varie pas au cours de la vie de la tâche. Ce principe est simple mais il réduit les possi- bilités d’adaptation de la politique d’ordonnancement à l’évolution du système contrôlé. Les algorithmes les plus courants sont Rate Monotonic [41] et Inverse Deadline [40].

■Rate Monotonic

Cet algorithme attribue une priorité constante fonction de la période de la tâche, de telle sorte que la tâche de plus petite période est la tâche la plus prioritaire. Cet algorithme est optimal dans la classe des algorithmes à priorité constante pour les configurations de tâches à échéance sur requête et, dans ce cas, on connaît une borne minimale pour l’acceptation d’une configuration de n tâches (condition suffisante) :

Cette borne théorique correspond au pire des cas et tend vers ln 2 (69 %) lorsque n est grand. Elle peut souvent être dépassée et une étude montre qu’en moyenne la borne supérieure avoisine 88 %.

L’exploitation comme critère d’ordonnancement de la période, paramètre évidemment non défini pour les tâches apériodiques,

limite l’utilisation de Rate Monotonic aux seules tâches à échéance sur requête.

La figure 11 donne l’exemple d’un ordonnancement Rate Mono- tonic pour deux tâches périodiques à échéance sur requête, Tp1 (r0 = 0, C = 1, P = 10) et Tp2 (r0 = 0, C = 3, P = 5). La tâche la plus prioritaire est la tâche Tp2. La séquence est étudiée sur la période d’étude, soit l’intervalle [0, 10]. Les deux tâches respectent leurs contraintes temporelles. La condition suffisante est vérifiée ; on a :

1/10 + 3/5 = 0,7 < 0,82

■Inverse Deadline

Cet algorithme attribue une priorité constante, fonction du délai critique de la tâche, telle que la tâche de plus petit délai critique est la tâche la plus prioritaire. Les performances de cet algorithme sont équivalentes à celles de Rate Monotonic dans le cas de tâches à échéance sur requête et meilleures dans le cas de configurations arbitraires. Une condition suffisante d’acceptabilité de tâches est la suivante :

La figure 12 donne l’exemple d’un ordonnancement Inverse Deadline pour deux tâches périodiques Tp1 (r₀ = 0, C = 4, R = 7, P = 10) et Tp2 (r₀ = 1, C = 3, R = 4, P = 5). La condition suffisante n’est pas vérifiée ; on trouve : 4/7 + 3/4 = 37/28 > 0,82.

La tâche la plus prioritaire est la tâche Tp2. On remarque qu’à l’instant t = 7, la tâche Tp1 commet une faute temporelle.

∑

n i=1

C_i P_i --- B n 2

1 n---

Ð1

 

 

Figure 11 – Ordonnancement Rate Monotonic

Figure 12 – Ordonnancement Inverse Deadline

∑

n i=1

C_i R_i --- B n 2

1 n---

Ð1

 

 

0 3 4 8 10

0 3 4 5 8 10

0 3 4 5 8 10

Tp1 (r₀ = 0, C = 1, P = 10)

Tp2 (r₀ = 0, C = 3, P = 5)

Temps creux

Réveil Échéance sur requête

0 1 4 6 7 8 10

0 1 3 4 5 6 8 10

Tp1 (r₀ = 0, C = 4, R = 7, P = 10)

Tp2 (r₀ = 1, C = 3, R = 4, P = 5)

Réveil Échéance