1 Cours STR 2012 v4 PDF

Historique
Ordonnancement de tâches indépendantes

Ordonnancement de tâches dépendantes
Ordonnancement dans des situations de surcharge
Ordonnancement conjoint tâches et messages
Systèmes temps réel et Ordonnancement - B. Sadeg
Université du Havre - UFR ST - LITIS - Équipe STI

LITIS-Université du Havre
UFR des Sciences et Techniques
25 rue Philippe Lebon - BP 540
76058 LE HAVRE CEDEX
bruno.sadeg@univ-lehavre.fr
Université du Havre - UFR ST - LITIS - Équipe STI Systèmes temps réel et Ordonnancement - B. Sadeg
Historique
- page 2/119
SOMMAIRE
1 Historique
2 Ordonnancement de tâches indépendantes
3 Ordonnancement de tâches dépendantes
4 Ordonnancement dans des situations de surcharge
5 Ordonnancement conjoint tâches et messages
Historique
- page 3/119
Introduction
le temps : rôle de + en + important dans les services et les applications

(informatique industrielle, télécommunications, ...)
Informatique industrielle : prémisses de l’informatique temps réel
En télécom, (1) débits élevés : la durée du trafic est bornée, (2) plusieurs flux
d’information : synchronisation nécessaire (multimédia).
Les services : à chaque service est liée une qualité de service (QoS) : temps
d’établissement d’une connexion, temps de réponse d’une requête, etc.
Historique
- page 4/119
Introduction (2)
Maîtrise du temps : d’abord, plus de puissance de calcul, puis apparition de

mécanismes “légers” (moins de temps gaspillé pour des parties non liées à
l’application), enfin méthodes pour prédire les comportements temporels
Plusieurs mécanismes à mettre en oeuvre dans un OS pour supporter
les applications temps réel, notamment l’ordonnancement des tâches
Historique
- page 5/119
Définition d’un système temps réel (STR)
système dont le comportement dépend non seulement de

l’exactitude des traitements effectués, mais également du temps
où les résultats de ces traitements sont fournis, c-à-d qu’un retard
dans la production d’un résultat est considéré comme une erreur
(pouvant entraîner de graves conséquences)
Historique
- page 6/119
En général
Observations
Système informatisue Procédé

mesures
de controle
− équipements élémentaires
− automate
événements − procédé complexe
− monoprocesseur
− multi−processeur commandes − ensemble d’équipements
− réseau local
affichages
Actions
F IGURE: Schéma d’une application temps réel

Historique
- page 7/119
Illustration
Système temps réel : calcul de la position d’un bateau en mouvement.

Même si le résultat fourni est exact, il est considéré comme erroné s’il
est fourni en retard (le bateau a changé de position)
Système non temps réel : gestion de notes des élèves. Si les moyennes
calculées sont exactes alors le système est correct (aux arrondis près)
Historique
- page 8/119
Exemples d’applications temps réel
Commandes de procédés, Systèmes embarqués, Guidage de mobiles,

Surveillance de centrales nucléaires,
Conduite d’expériences scientifiques, Robotique,
Fourniture d’images et son pour le multimédia, Suivi d’informations
boursières,
Suivi opératoire en milieu médical,
Historique
- page 9/119
Fonctionnement
Les applications déclenchent des événements à occurence périodique

ou aléatoire. Elles imposent au système informatique qui leur est
associé de réagir avant un délai fixé (ou à une date donné).
L’échelle de temps peut varier selon le contexte : la microseconde pour
un radar, la seconde pour une IHM, la minute dans une chaîne de
fabrication, l’heure pour une réaction chimique, ...
Historique
- page 10/119
Types d’échéances et de systèmes temps réel
échéance dure (hard) : le dépassement de l’échéance provoque une

exception dans le système (qui peut engendrer des dommages)
==> STR durs : les échéances ne doivent en aucun cas être dépassées
(sinon catastrophe humaine ou industrielle ou économique, ...)
échéance molle, lâche (soft) : un dépassement d’échéance ne
provoquie pas d’exception dans le système
==> STR mous : les échéances peuvent être dépassées
occasionnellement (ex. usine automatisée)
Historique
- page 11/119
Caractéristiques dun système temps réel(1)
La prévisibilité d’un STR : est un aspect important.

Un STR doit être conçu tel que ses performances soient définies dans
le pire cas (alors que dans les systèmes classiques, les performances
sont définies en termes de moyenne).
La prévisibilité : le fait de savoir à l’avance si un système va respecter
ses contraintes temporelles (C.T.). Pour cela, il est nécessaire de
connaître avec précision les paramètres des tâches : temps global de
calcul de chaque activité, périodicité, date de réveil, etc.
Ces éléments définissent le choix d’une politique d’ordonnancement
des activités telle que le système soit prévisible
Historique
- page 12/119
Caractéristiques (2)
Le déterminisme d’un STR : est le but à atteindre pour assurer la

prévisibilité : Pour qu’un système soit prévisible, il faut qu’il soit
déterministe. Donc enlever toute incertitude sur le comportement des
activités (individuelles et mises ensemble)
Dans un STR dur : on cherche à ce que toutes les échéances soient
respectées
Dans un STR mou : minimiser le retard moyen des activités par
exemple.
Historique
- page 13/119
Commentaires
L’organisation du système en couches facilite son évolution.

Dans ces syst. (classiques), les ressources sont allouées
dynamiquement aux tâches : principalement le processeur et la M.C.
Des études ont montré que la ressource sensible est la M.C. Celle-ci est
d’abord allouée avec des algos complexes. Le processeur est alloué en
dernier.
l’ordo. est simplifié. Il porte sur peu de tâches (celles déjà servies).
les algos cherchent à optimiser les ressources, mais pas de respecter
les priorités des tâches (différence avec les exécutifs temps réel)
dans un STR, les ressources autres que le processeur sont souvent
attribuées dynamiquement. Le principal param. d’allocation est le
processeur (on parle d’exécutif temps réel).
Historique
- page 14/119
Sources du non-déterminisme
Charge de calcul (durées d’exécution variées)

Entrées/sorties
Interruption : temps de réaction du système
Fautes et exceptions matérielles et logicielles
Historique
- page 15/119
Remarques
Le déterminisme absolu : difficile à atteindre

Mais, on améliore par des méthodes d’ordonnancement qui analysent a
priori le comportement temporel du système
Historique
- page 16/119
La fiabilité (reliability)
Est un autre aspect important des STR

CAR il est difficile de prédire le comportement d’un système dont les
composants ne sont pas fiables
DONC conception de systèmes tolérants aux fautes (fiables)
Ex : systèmes embarqués embedded systems
Historique
- page 17/119
Systèmes embarqués
Pas d’intervention humaine directe

ESSENTIEL : ils doivent être prévisibles (et fiables)
Ex : métro automatique, pilote automatique d’avion, contrôle de navette
spatiale, ...
Ce sont des systèmes dédiés : ”taillés spécialement” pour ...
Historique
- page 18/119
Exemples d’application
1. Le robot : doit prendre des objets qui défilent sur un tapis

le robot dispose d’une “fenêtre temporelle” pour agir.
S’il agit tard, il manquera l’objet
S’il agit tôt, il va bloquer l’objet (et les objets suivants)
Historique
- page 19/119
Exemples d’application (2)
2. Système de vidéo-conférence : sur un réseau local.

le système numérise l’image, puis la séquence. Il faut que soient
traitées 30 images/sec pour une image acceptable.
Plusieurs opérations vont s’enchaîner dans le temps : numérisation,
compression, transmission. La durée de ces opérations = temps de
latence du système.
La voix doit également être numérisée, compressée et transmise. Il faut
qu’il y ait synchronisation son/image. Un retard léger est acceptable. S’il
est trop long, la scène devient incompréhensible. (temps réel mou, ou
échéances molles, relatives)
Historique
- page 20/119
Systèmes d’exploitation classiques
non déterministes
l’ordonnanceur vise l’équité
+ d’autres inadaptations
Historique
Plate−forme professionnelle : IHM :
Service de noms ...
Services de l’OS :
Biblio. de pgms Gestion d’objets
Bases de donnees Noyau :

gest. fichiers ordonnanceur
gest. M.V.
gest. horloge pilotes priphriques

messagerie gest. memoire
gest. it. pilotes rseau
gest. de taches gest. semaphores Materiel
F IGURE: Structure d’un syst. d’expl. classique
Historique
- page 22/119
Limites des systèmes classiques pour le temps réel
Reposent sur un OS qui offre des mécanismes mal adaptés au temps

réel
politiques d’ordonnancement visent le partage équitable du temps
d’exécution. Pas adaptées à des tâches plus critiques que d’autres.
les mécanismes d’accès aux ressources partagées sont à adapter pour
éliminer les incertitudes temporelles
la gestion des E/S engendre de longues attentes (parfois non bornées)
la gestion des interruptions n’est pas optimisée
les mécanismes de gestion de la mémoire virtuelle sont à revoir
(swapping, ...)
les temporisateurs qui organisent le temps n’ont pas une résolution
assez fine (pour beaucoup d’applications temps réel)
Historique
- page 23/119
Sources d’incertitude
On ne dispose pas de moyens pour indiquer à l’OS le degré d’urgence

d’une tâche
le temps de réponse des événements externes n’est pas prévisible : le
système n’indique rien sur la durée de prise en compte d’une
interruption
Historique
- page 24/119
Terminologie
Noyau : rend l’ensemble des services de base nécessaires à l’exécution

d’une application (gestion mémoire, processeur, adressage,
interruptions, ...)
Exécutif : rend les sevices du noyau plus d’autres sans toucher à
l’interface utilisateur (surtout pour les systèmes embarqués)
Système d’exploitation : noyau+exécutif+intéraction avec l’utilisateur
Historique
- page 25/119
Ordonnancements classiques : multiprogrammation
Objectifs : maximiser le taux d’utilisation du processeur 1 et minimiser le

temps de réponse des tâches (durée séparant l’instant de soumission
au système de l’instant de fin d’exécution)
Autres critères : temps d’attente des tâches (état prêt), débit du
processeur (nbre de tâches traitées par unité de temps), moyenne du
temps de réponse d’un ensemble de tâches), ...
1. temps où le processeur est actif/temps total. En théorie : 0-100%, en pratique :40-95%

Historique
- page 26/119
Principales politiques (1)
→ déterminer quelle tâche prête doit être élue

1. Premier arrivé, premier servi (les tâches de faible temps d’exécution
sont pénalisées si elles sont précédées dans la file par une tâches de
longue durée)
2. Plus court d’abord : remédie à l’inconvénient précédent. Minimise le
temps de réponse moyen. Pénalise les travaux longs. Elle impose
d’estimer les durées d’exécution des tâches (connues difficilement).
3. Temps restant le plus court d’abord : la tâche en exécution restitue le
processeur lorsqu’une nouvelle tâche ayant un temps d’exécution
inférieur à son temps d’exécution restant devient prête.
Historique
- page 27/119
4. Tourniquet (RoundRobin) : on définit un quantum de temps (10ms à

100ms). Chaque tâche de la file acquiert le processeur pendant au
maximum un quantum de temps, puis le cède à sa suivante dans la file,
etc. → utilisée souvent dans les système à temps partagé. Ses
performances dépendent du quantum de temps. Si trop grand :
augmente les temps de réponse, si trop petit : multiplication des
commutation de contextes.
Priorités constantes : des priorités sont affectées aux tâches et à un
instant donné, la tâche élue est celle qui a la plus forte priorité. Les
tâches de faible priorité peuvent ne pas disposer du processeur
(famine). Solution : faire “vieillir” la priorité des tâches en attente
(augmenter en fonction du temps d’attente). La priorité devient ainsi
variable (et donc non constante !)
Historique
Tourniquet
FIN
T3(3)
FIN
T2(7)
FIN
T1(2
0 3 4 6 8 9 11 12 15 18 21 24 30
Quantum = 4 unites
T1 (C1=20 unites) T2 (C2= 7 unites) T3 (C3= 3 unites)
Ordonnancement par Tourniquet (Round Robin)
F IGURE: Exemple : Tourniquet (Round Robin)
Historique
T1 3 7 T1
T2 1 1 T2
T3 3 T3
4
T4
T4 2 3
priorite Ci
T2 −− T4 −− T1 −− T3
Ordonnancement Files priorites constantes
T4
T1
T2
T3
temps
1 4 11 15
0
Priorites constantes
Historique
- page 30/119

Files de priorités constantes multiniveaux : on définit plusieurs files de
tâches prêtes. Chaque file correspond à un niveau de priorité (n files de
priorités variant de 0 à n-1 : file i, tâches de même priorité). Elles sont
gérées soit par ancienneté soit par touniquet. Le quantum peut être
différent selon la file. L’ordonnanceur sert d’abord les tâches de la file 0,
puis celles de la file 1 (dès que la 0 se vide), etc. Deux variantes :
les priorités des tâches sont constantes tout au long de leur exécution :
une tâche en fin de quantum est réinsérée dans la même file
les priorités des tâches évoluent dynamiquement en fonction des
services dont elles ont déjà bénéficié. Une tâche de la file i, qui n’a pas
terminé son exécution à la fin de son quantum est réinsérée dans la file
i + 1 (moins prioritaire), etc.
On minimise ainsi les risques de famine des tâches de faible priorité en
diminuant petit à petit les priorités des tâches ayant de fortes priorités
initiales.
Historique
priorite elevee
arrivee
FILE 0 q0
ELECTION
FILE 1 q1
FILE N−1 q N−1

faible priorite
Ordonnancement : Files multi−niveaux

q est le quantum / q0 < q1 < < qN−1
F IGURE: Exemple : Files multi-niveaux : priorités constantes/variables
Historique
- page 32/119
Remarques
Aucune des politiques présentées ne permet de remplir les 2 objectifs

d’un ordonnancement temps réel.
Notament : pas de prise en compte de l’urgence des tâches (délai
critque)
==> Ordonnancement spécifique aux tâches temps réel
Historique
- page 33/119
Terminologie pour l’ordonnancement des tâches temps réel
tâche = unité de base de l’ordonnancement temps réel. Sont

périodiques ou apériodiques. A contraintes temporelles strictes ou
relatives.
Modèle : paramètres chronologiques (délais) et chronométriques
(dates). Les paramètres de base d’une tâche sont :
r : sa date de réveil, moment de déclenchement de la 1ere requête
d’exécution
C : sa durée maximale d’exécution (si elle dispose du processeur à elle
seule)
D : son délai critique (délai maximal acceptable pour son exécution)
P : sa période (si tâche périodique)
Si tâche à contraintes strictes : l’échéance d = r + D, est la date dont le
dépassement entraîne une faute temporelle.
Historique
- page 34/119
Illustration : diagramme temporel d’exécution
P P
D
temps
r0 d0 r1 d1 r2
C
F IGURE: Modèle de tâches
Historique
- page 35/119
Commentaires
T (r0 , C, D, P) avec 0 ≤ C ≤ D ≤ P
r0 : date de réveil, C : durée max d’exécution,
D : délai critique, P : période
rk : date de réveil de la k eme requête de la tâche.
rk = r0 + k P, représentée par ↑
dk : échéance de la k eme requête de la tâche.
dk = rk + D, représentée par ↓
Rem : tâche à échéance sur requête quand
D = P, représentée par l
Historique
- page 36/119
Remarques
Tâche à contraintes relatives : D parfois omis

Tâche apériodique : pas de paramètre P
Plus les paramètres précédents sont exacts, plus la qualité de
l’ordonnancement est meilleure
Historique
- page 37/119
Autres paramètres déduits

u= CP
(doit être ≤ 1) : facteur d’utilisation du processeur par la tâche
ch = C
D
doit être (≤ 1) : facteur de charge du processeur
paramètres dynamiques (pour suivre l’exécution d’une tâche) :
s : date de début de l’exécution d’une tâche
e : date de fin d’exécution d’une tâche
D (t ) = d − t : délai critique résiduel à la date t
(0 ≤ D (t ) ≤ D)
C (t ) = durée d’exécution résiduelle à la date t
(0 ≤ C (t ) ≤ C)
L = D − C laxité nominale de la tâche, retard maximum pour son début
d’exécution s quand la tâche s’exécute seule.
L(t ) = D (t ) − C (t ) laxité nominale résiduelle, retard maximum pour
reprendre l’exécution d’une tâche si elle s’exécute seule (L(t ) égal aussi
D + r − t − C (t )).
TR = e − r : temps de réponse de la tâche
C (t )
CH (t )= D (t )
: charge résiduelle au temps t
Historique
- page 38/119
Plusieurs états d’une tâche
élue : un processeur est alloué à la tâche

bloquée : la tâche attend une ressource, un message ou un signal de
synchronisation
prête (éligible) : la tâche attend d’être élue
passive : la tâche n’a pas de requête en cours
inexistante : la tâche n’est pas créée
Historique
- page 39/119
Etats d’une tâche
ELUE
BLOQUEE PRETE
faute
faute temporelle temporelle
PASSIVE
INEXISTANTE
F IGURE: Etats d’une tâche

Historique
- page 40/119
Exemples de tâches
acquisition de données depuis des capteurs

affichage de résultats sur un écran
capture de la température dans une centrale
envoi d’une scène (image+son) sur un moniteur, ...
Historique
- page 41/119
Autres caractéristiques d’une tâche
préemptible : tâche élue qui peut être arrêtée et remise à l’état prêt,
pour allouer le processeur à une autre tâche
non préemptible : une fois élue, la tâche ne doit plus être interrompue
jusqu’à la fin de la requête (tâches atomiques, à exécution immédiate).
Ex : tâche qui s’exécute sous le contrôle d’une interruption
Historique
- page 42/119
Autres caractéristiques d’une tâche (2)
tâches indépendantes : lorsqu’elles n’ont pas de relations de

précédence, ni ne partagent des ressources critiques
tâches dépendantes :
Par une relation de précédence statique : si elles agissent selon un ordre
prédéterminé, ou induit par la communication par messages ou par une
relation explicite de synchronisation. Elle est statique car connue a priori.
On peut construire le graphe de dépendance.
Par une relation de précédence dynamique : si elles partagent des
ressources critiques (accès en exclusion mutuelle). La relation est
dynamique car l’utilisation de la ressource dépend de l’ordre d’exécution
des tâches.
Historique
- page 43/119
Autres caractéristiques d’une tâche (3)
Priorité externe (fixe) : forme primitive d’ordonnancement temps réel.

Tout est détérminé par un ordonnancement hors ligne ou par des règles
qui imposent un ordre a priori (ex : tâche de gestion de l’horloge, tâche
de sauvegarde en cas de chute de tension)
Urgence : tâches de même urgence → même échéance.
Importance : tâches pouvant être supprimées en premier dans certains
cas pour permettre aux autres (plus importantes) de respecter leurs
contraintes. 2 tâches de même urgence peuvent avoir des importances
différentes.
Historique
- page 44/119
Ordonnancement temps réel
Son but est de permettre le respect des contraintes temporelles des

tâches d’une application quand elle s’exécutent en mode courant
Il doit être certifiable, c-à-d prouver a priori le respect des C.T. des
tâches d’une application (en régime courant)
En régime de surcharge (tâches supplémentaires suite à des
anomalies : alarmes, variations des temps d’exécution, → fautes
temporelles...) : l’ordonnancement doit offrir une tolérance aux
surcharges (permettre une exécution dégradée mais sécuritaire du
système)
Historique
- page 45/119
Définitions
Configuration de tâches : mise en jeu d’un ensemble de n tâches qui
s’exécutent
Départ simultané : même date de réveil (sinon départ échelonné)
Facteur d’utilisation du processeur pour n tâches périodiques : U =
Ci
∑ii =n
=1 Pi
Facteur de charge du processeur pour n tâches périodiques : CH =
C
∑ni=1 Dii
Laxité du processeur à l’instant t, LP (t ) = intervalle de temps à partir de
t pendant lequel le processeur peut rester inactif sans remettre en
cause le respect des échéances (LP (t ) ≥ 0, ∀ t). LP (t ) est égale au
minimum des laxités conditionnelles LCi (t ) des tâches i
LCi (t ) = Di - ∑j Cj (t ). Les tâches j sont celles qui sont déclenchées à
l’instant t et qui devancent i dans la séquence de planification.
Historique
- page 46/119
Définition du problème d’ordonnancement
Le système de conduite d’une application temps réel doit piloter le

procédé en ordonnançant les tâches avec 2 objectifs :
assurer le respect des C.T. en fonctionnement nominal
atténuer les effets des surcharges et maintenir le procédé dans un état
cohérent et sûr en fonctionnement anormal (pannes matérielles ou
logicielles) → respecter au moins les CT des requêtes vitales pour le
procédé
L’algorithme d’ordonnancement fournit une description de la séquence

de planification de tâches à effectuer de manière à respecter les CT.
Historique
- page 47/119
Typologie des algorithmes d’ordonnancement

Hors ligne : l’algorithme construit la séquence complète de planification
des tâches sur la base de tous les paramètres temporels des tâches.
Séquence connue avant l’exécution. Très efficace Mais cette approche
statique est rigide car elle suppose que tous les paramètres, y compris
les dates de réveil, sont figées → ne s’adapte pas aux changements de
l’environnement
En ligne : capable à tout instant de l’exécution d’une application de
choisir la prochaine tâche à ordonnancer, en utilisant les informations
des tâches déclenchées à cet instant. Ce choix peut être remis en
cause par l’occurence d’un nouvel événement. Cette approche
dynamique offre des solutions moins bonnes (car elle utilise moins
d’informations) et entraîne des surcoûts de mise en oeuvre. Les
avantages : permet l’arrivée imprévisible des tâches, autorise la
construction progressive de la séquence d’ordonnancement.
Historique
- page 48/119
Typologie des algorithmes d’ordonnancement (2)
Pour pouvoir traiter les tâches apériodiques (et les surcharges

anormales), l’ordonnancement se fait souvent en ligne.
Algorithme préemptif : permet à l’ordonnanceur de déposséder la tâche
élue du processeur au profit d’une autre tâche jugée plus prioritaire.
N’est utilisable que si toutes les tâches sont préemptibles. La tâche
ayant perdu le processeur passe à l’état prêt pour être élue
ultérieurement sur le même processeur ou sur un autre.
Algorithme non préemtif : n’arrête pas l’exécution d’une tâche élue. Peut
en résulter des fautes temporelles qu’un algorithme préemtif aurait
évitées.
Historique
- page 49/119
Best effort - Strict
Meilleur effort (Best effort) : pour une application à contraintes relatives,

la stratégie d’ordonnancement est celle du meilleur effort : elle essaie
de faire au mieux avec les processeurs disponibles.
Pour une application à contraintes strictes : l’ordonnanceur doit garantir
le respect des CT. Il y a obligation de réussite et non tolérance aux
fautes temporelles.
Historique
- page 50/119
Centralisé - Distribué
Centralisé : si l’algorithme d’ordonnancement s’exécute sur une

architecture centralisée (ou sur un site privilégié d’une architecture
distribuée, qui contient tous les paramètres des tâches).
Distribué : lorsque les décisions d’ordonnancement sont prises sur
chaque site par un ordonnanceur local après une éventuelle
coopération pour effectuer un ordonnancement global (Si global :
peuvent intervenir le placement des tâches sur un site et la migration
des tâches d’un site à un autre)
Historique
- page 51/119
Propriétés des algorithmes d’ordonnancement
Séquence valide : un algorithme d’ordonnancemnt délivre une

séquence d’ordonnancement valide pour une configuration de tâches
donnée si toutes les tâches respectent leur CT.
Une configuration est ordonnançable dès qu’il existe au moins un
algorithme capable de fournir une séquence valide pour cette
configuration.
Algorithme optimal : s’il est capable de produire une séquence valide
pour toute configuration de tâches ordonnançables.
Historique
- page 52/119
Tests
Test d’ordonnançabilité : vérifie qu’une configuration de tâches

périodiques donnée soumise à un algorithme d’ordonnancement peut
être ordonnancée selon une séquence valide.
Test d’acceptabilité : un algorithme en ligne modifie dynamiquement la
séquence d’ordonnancement à l’arrivée de nouvelles tâches (ou à la
suite de dépassement d’échéances). Une tâche nouvelle peut être
ajoutée à la configuration s’il existe au moins une séquence valide avec
la nouvelle configuration (tâches existantes + celle ajoutée). L’ensemble
des conditions à satisfaire est le test d’acceptabilité (routine de
garantie).
Dans un ordonnancement réparti, le rejet d’une requête par ce test peut
être résolu en essayant de migrer la tâche sur un autre site.
Historique
- page 53/119
Propriétés (2)
Période d’étude : Pour valider une configuration de tâches périodiques

et apériodiques, on effectue une analyse temporelle de l’exécution de la
configuration.
Pour les tâches périodiques : il suffit d’effectuer l’analyse sur une
période (car la configuration est périodique, et se répète indéfiniment)
Début de la période d’étude : t = Min{ri0 }, c-à-d date de réveil de la
premiere requête de la première tâche de la configuration.
Fin de la période d’étude : Max{ri , 0, rj , Dj } + 2*PPCM(Pi ), i : tâches
périodiques, j : tâches apériodiques (PPCM(Pi ) seulement, si
périodiques).
Historique
- page 54/119
Mise en oeuvre d’un ordonnanceur
Table d’élection : lorsque la séquence est connue a priori

(ordonnancement hors ligne), cette séquence est inscrite dans une table
consultée par l’ordonnanceur pour élire les tâches.
Liste d’attente avec priorités : l’ordonnancement en ligne → création
dynamique d’une séquence de planification. Le 1er élément indique la
tâche élue (si monoprocesseur), les n 1ers , si n processeurs.
La liste est ordonnée selon les clés (priorités).
Priorité fixe : Dans la liste d’attente : la clé (priorité) est fixe si on prend
un paramètre fixe comme clé (durée d’exécution, délai critique, période).
Priorité variable : si on prend comme clé un paramètre variable (date de
réveil, échéance, ...)
Historique
- page 55/119
Algorithme En ligne, à priorité constante
RateMonotonic (RM)
InverseDeadline (ID) ou DeadlineMonotonic (DM)
Historique
- page 56/119
Algorithme En ligne, à priorité variable)
Earliest Deadline (ED) ou Earliest Deadline First (EDF )

Least Laxity (LL) ou Least Laxity First (LLF )
Historique
- page 57/119

Algorithme En ligne, à priorité constante (où D=P)
Rate Monotonic (ou RM) : priorité d’une tâche = f(sa période). La tâche
de plus petite période est la plus prioritaire. L’algorithme est optimal
dans la classe des algorithmes à priorité constante pour une
configuration de tâches à échéances sur requête. Dans ce cas, on
connaît une condition suffisante d’existence d’une borne minimale
pour l’acceptation d’une configuration de n tâches :
C 1
∑ni=1 Pii ≤ n(2 n − 1)
Cette borne = pire cas et tend vers ln 2 quand n très grand (c-à-d 69%).
Elle peut être dépassée (en moyenne elle est de 88%)
Historique
- page 58/119
Exemple d’ordonnancement avec RM
la figure 8 montre l’exemple d’un ordonnancement “Rate Monotonic”

pour 3 tâches périodiques à échéance sur requête (échéance=période).
T1 (r0 = 0, C = 3, P = 20), T2 (r0 = 0, C = 2, P = 5),
T3 (r0 = 0, C = 2, P = 10). Tâche de plus haute priorité : T2 , tâche de
plus basse priorité : T1 .
La période d’étude est l’intervalle [0, 20] 2 .
Les 3 tâches respectent leur CT car la condition suffisante est vérifiée :

3
on a bien 20 + 52 + 10
2
≤ 0.779 (0.15+0.4+0.2=0.75 ≤ 0779).
Rmq : l’utilisation de la période comme critère d’ordonnancement limite
l’application de “Rate Monotonic” aux seules tâches où l’échéance est
égale à la période (échéances sur requête).
2. Configuration à départ simultané, période d’étude [0, PPCM(Pi )]

Historique
- page 59/119
Chronogramme de ces tâches avec ’Rate Monotonic’
T1 (r1=0, C=3, P=20)
temps
0 4 5 7 9 20
T2 (r2=0, C=2, P=5)
temps
0 2 5 7 10 12 15 17 20
T3 (r3=0, C=2, P=10)
temps
0 2 4 10 12 14 20
F IGURE: Ordonnancement “Rate Monotonic”
Historique
- page 60/119

Algorithme En ligne, à priorité constante (où D <> P)
Inverse Deadline ou Deadline Monotonic : priorité d’une tâche = f(son

délai critique). La tâche la + prioitaire est celle de + petit délai critique.
Cet algo est égal en performances à “Rate Monotonic” pour les tâches à
échéances sur requête, et meilleur pour les autres types de
configurations de tâches. Condition suffisante d’acceptabilité :
C 1
∑ni=1 Di ≤ n(2 n − 1) (facteur de charge)
i
Historique
- page 61/119
Exemple d’ordonnancement avec ’DM’ (ou ’ID’)
la figure 9 montre l’exemple d’un ordonnancement “Deadline Monotonic”

pour 3 tâches périodiques.
T1 (r0 = 0, C = 3, D = 7, P = 20), T2 (r0 = 0, C = 2, D = 4, P = 5),
T3 (r0 = 0, C = 2, D = 9, P = 10). Tâche de plus haute priorité : T2 ,
tâche de plus basse priorité : T3 .
La condition suffisante n’est pas vérifiée : 73 + 24 + 29 = 1.14 > 0.77.
Cependant, le chronogramme construit sur la période d’étude montre
qu’elles sont ordonnançables sans faute temporelle.
Historique
- page 62/119
Chronogramme de ces tâches avec ’Deadline Monotonic’
T1 (r0=0, C=3, D=7, P=20)

temps
0 2 5 7 20
T2 (r0=0, C=2, D=4, P=5)
temps
0 2 4 5 7 9 10 12 14 15 17 19 20
T3 (r0=0, C=2, D=9, P=10)

temps
0 4 5 7 9 10 12 14 19 20
F IGURE: Ordonnancement “Inverse Deadline ou Deadline Monotonic”
Historique
- page 63/119

Algorithmes en ligne à priorité variable : EDF
La priorité d’une tâche varie dans le temps.

Earliest Deadline : (ED) : La + haute priorité à l’instant t est accordée à
la tâche dont l’échéance est la + proche. Pour les tâches à échéances
sur requête, une CNS d’ordonnancement est : ∑ni=1 C P
i
≤1 i
Pour des tâches périodiques quelconques, une condition suffisante est :
C C
∑ni=1 Di ≤ 1 et une condition nécessaire est : ∑ni=1 Pi ≤ 1.
i i
Historique
- page 64/119
Exemple
la figure 10 montre l’exemple d’un ordonnancement “Earliest Deadline”
pour 3 tâches périodiques. T1 (r0 = 0, C = 3, D = 7, P = 20),
T2 (r0 = 0, C = 2, D = 4, P = 5), T3 (r0 = 0, C = 1, D = 8, P = 10).
à t=0 : au réveil des 3 tâches, T2 prioritaire, elle s’exécute pendant 2
unités.
A t=2, T2 termine. C’est T1 la + prioritaire. Elle s’exécute pendant 3
unités de temps.
A t=5, T1 se termine et T2 se réveille de nouveau (car période 5), mais
c’est T3 qui est cette fois la + prioritaire car son échéance est 8, elle
s’exécute pendant une unité.
Ici, on voit que les priorités des tâches varient dans le temps : par
exemple, à t=0, c’est T2 + prioritaire (que T1 et T3 ), mais à t=5, c’est T3
la plus prioritaire.
Historique
- page 65/119
Chronogramme de ces tâches avec ’ED’ (ou ’EDF’)
T1 (r0=0, C=3, D=7, P=20 )
0 2 5 7 20
T2 (r0=0, C=2, D=4, P=5 )
0 2 4 5 6 8 9 10 12 14 15 17 19 20
T3 (r0=0, C=1, D=8, P=10 )
0 5 6 8 10 12 13 18 20
Ordonnancement ED (ou EDF)

Historique
- page 66/119

Algorithmes en ligne à priorité variable : LLF
La priorité d’une tâche varie dans le temps.

Least Laxity (LL) : La tâche de + haute priorité à l’instant t est celle qui a
la + petite laxité dynamique Li (t ). Cet algorithme est optimal et les
conditions d’ordonnançabilité des tâches sont les mêmes que pour
Earliest Deadline. Les séquenecs produites par LL sont équivalentes à
celles produites par ED lorsque les valeurs des laxités sont calculées
aux dates de réveil. Par contre, si on calcule la laxité à chaque instant
alors la séquence produite par LL entraîne plus de changements de
contextes que par ED.
Historique
- page 67/119
Exemple
Les figures 11 et 12 montrent l’ordonnancement avec LL pour les 3
tâches de l’exemple sur ED, avec un calcul de laxité effectué aux seules
dates de réveil.
A t=0, les 3 tâches sont réveillées. Laxité dynamique de T1 =7-3=4.
Laxité de T2 =4-2=2. Laxité de T3 =8-1=7. C’est donc T2 (la + prioritaire)
qui s’exécute à t=0 (pour 2 unités).
A t=2, c’est T1 qui s’exécute (sa laxité [7-2-3] est plus petite que celle de
T3 [8-2-1] ).
A t=5, T2 se réveille de nouveau. Sa laxité dynamique (9-5-2 = 2ème
échéance - temps courant - durée exécution) est égale à 2 , celle de T3
(8-5-1) est de 2 également (retard ’toléré’ t.q l’échéance est toujours
respectée). On peut choisir T3 (cas a) ou t2 (cas b) pour être
ordonnancée et s’exécuter.
Rappel : L(t ) = D (t ) − C (t ) laxité nominale résiduelle, retard maximum
pour reprendre l’exécution d’une tâche si elle s’exécute seule (= aussi
D + r − t − C (t )).
Historique
- page 68/119
Chronogramme de ces tâches avec ’LL’ : ici T3 élue à t=5
T1 (r0=0, C=3, D=7, P=20)
temps
0 2 5 7 20
T2 (r0=0, C=2, D=4, P=5)
temps
0 2 4 5 6 8 9 10 12 14 15 17 19 20
T3 (r0=0, C=1, D=8, P=10)
temps
0 5 6 8 10 12 13 18 20
F IGURE: Ordonnancement “Least Laxity”. Cas (a) : c’est T3 qui est élue à t=5
Historique
- page 69/119
Chronogramme de ces tâches avec ’LL’ : ici T2 élue à t=5
T1 (r0=0, C=3, D=7, P=20)
temps
0 2 5 7 20
T2 (r0=0, C=2, D=4, P=5)
temps
0 2 4 5 7 9 10 12 14 15 17 19 20
T3 (r0=0, C=1, D=8, P=10)
temps
0 7 8 10 12 13 18 20
F IGURE: Ordonnancement “Least Laxity”. Cas (b) : c’est T2 qui est élue à t=5
Historique
- page 70/119
tâches tâches périodiques et tâches apériodiques

Algorithmes qui prennent en compte les tâches apériodiques
But : les CT des tâches périodiques doivent être respectées et

(1) soit minimiser le temps de réponse des tâches apériodiques à
contraintes relatives Best Effort),
(2) soit maximiser le nombre de tâches apériodiques à contraintes
strictes qui respectent leurs CT .
Historique
- page 71/119
Tâches apériodiques à contraintes relatives :

1. Traitement en arrière-plan (BackgroundProcessing)
les tâches apériodiques sont ordonnancées lorsque le processeur est

oisif (pas de tâche périodique prête).
Si ∃ plusieurs tâches apériodiques, traitement par dates de réveil
(FIFO).
Historique
- page 72/119
Exemple : Prise en compte des tâches apériodiques :

Ordonnancement “en arrière plan”
La figure montre un tel ordonnancement sur un intervalle égale à 2 fois

la période d’étude d’une configuration de 2 tâches périodiques à
échéances sur requête T1 (r0 = 0, C = 2, P = 5),
T2 (r0 = 0, C = 2, P = 10).
L’application de ’Rate Monotonic’ à cette configuration laisse le
processeur oisif sur les intervalles [4,5], [7,10], [14,15] et [17,20].
La tâche apériodique Ta3 (r = 4, C = 2) survenant à t = 4 peut
immédiatement commencer son exécution qu’elle finit sur le temps
creux suivant c-à-d entre les temps t = 7 et t = 8.
La tâche apériodique Ta4 (r=10, C=1) qui survient à t=10 doit attendre le
temps creux [14,15] pour s’exécuter. La tâche apériodique Ta5 (r=11,
C=2) doit attendre le temps creux [17,20] pour s’exécuter.
Historique
- page 73/119
Chronogramme : Ordonnancement “en arrière plan’
T1 (r0=0, C=2, P=5)
temps
0 2 5 7 10 12 15 17 20
T2 (r0=0, C=2, P=10)
temps
0 2 4 10 12 14 20
Temps creux
temps
0 4 5 7 10 14 15 17 20
Taches apériodiques
temps
0 4 5 7 8 10 11 14 15 17 19
20
Tap (r=4, C=2) Tap (r=11, C=2)

Tap (r=10, C=1)
Arriere−plan (background)
Historique
- page 74/119
Remarque
La méthode d’ordonnancement en arrière-plan est simple et peu

coûteuse et est applicable ∀ l’algorithme d’ordonnancement des tâches
périodiques. Mais les temps de réponse des tâches apériodiques
peuvent être mauvais surtout si la charge des tâches périodiques est
importante.
Historique
- page 75/119
Tâches apériodiques à contraintes relativeaffine le résultat et s’exécute

s’il reste assez de temps avant l’échéance.s : 2. Les serveurs de tâches
un serveur est une tâche périodique créée spécialement pour veiller à

l’ordonnancement des tâches apériodiques.
Elle est caractérisée par une période et un temps d’exécution (la
capacité du serveur).
Elle est souvent ordonnancée avec le même algo que les autres tâches
périodiques.
Une fois active, la tâche serveur sert les tâches apériodiques dans la
limite de sa capacité. L’ordre de service des tâches apériodiques ne
dépend pas de l’algo d’ordonnancement des tâches périodiques (il peut
être FIFO, f(échéances), f(temps d’exécution), ...).
∃ plusieurs types de serveurs : le plus simple est le serveur par
scrutation. Les autres (serveur ajournable, à échange de priorité,
sporadique) en sont des améliorations.
Historique
- page 76/119
Les serveurs de tâches : Traitement par ’scrutation’ (“Polling”)

à chaque activation, le serveur traite les tâches apériodiques en attente
depuis son activation précédente, jusqu’à épuisement de sa capacité
(ou plus de tâches en attente).
Si, lors d’une nouvelle activation, il n’y a aucune tâche apériodique en
attente, le serveur se suspend jusqu’à la prochaine occurence : sa
capacité (tps d’exécution) est récupérée par les tâches périodiques.
La figure montre le fonctionnement d’un serveur par scrutation.
Configuration : 2 tâches périodiques à échéances sur requête T1 (r0 =0,
C=3, P=20) et T2 (r0 =0, C=2, P=10).
La tâche serveur est Ts (r0 =0, C=2, P=5) est de plus grande priorité (car
plus petite période) avec “Rate Monotonic” appliqué pour ordonnancer
les 3 tâches. On vérifie que la condition d’acceptabilité est remplie :
3
+ 2 + 2 = 0.75 ≤ 0.77
20 10 5
Historique
- page 77/119
Chronogramme : Ordonnancement “avec un serveur par scrutation”
T1 (r0=0, C=3, P=20)
temps
0 2 5 20
T2 (r0=0, C=2, P=10)
temps
0 2 10 12 14 20
Tps (r0=0, C=2, P=5)

taches apériodiques
temps
0 4 5 7 10 11 12 15 16 20
Tap3(r=4, c=2)
Tap4(r=10, c=1) Tap5(r=11, c=2)
capacité du serveur
2 temps
1
0 5 7 10 12 15 16 20
Serveur par scrutation
F IGURE: Ordonnancement “avec un serveur par scrutation”
Historique
- page 78/119
Commentaires : “avec un serveur par scrutation”
à t=0, aucune tâche apériodique, donc le serveur se suspend

immédiatement. C’est T2 de priorité élevée suivante qui s’exécute, puis
c’est T1 .
à t=4, la tâche apériodique Ta4 survient. elle doit attendre l’occurence
suivante du serveur (t=5) pour s’exécuter. Elle épuise alors toute la
capacité (C=2) du serveur.
A t=10, le serveur se réveille de nouveau, il sert la tâche apériodique
Ta4 qui vient d’être activée. Puis il sert Ta5 . La tâche Ta5 ne peut
s’exécuter entièrement car elle épuise la capacité restante du serveur.
Elle doit attendre l’occurence suivante du serveur à t=15 pour finir son
exécution. Il reste encore une unité au serveur, il la perd car il n’y a
aucune tâche apériodique à servir.
Historique
- page 79/119
Commentaires : “avec un serveur par scrutation” (suite)
Remarques : Faiblesses : lorsque le serveur est prêt, si pas de tâches à

traiter, sa capacité est perdue. Si des tâches apériodiques surviennent,
elles doivent attendre l’occurence suivante.
Améloration : serveur “ajournable” : si pas de tâche apériodique à servir,
le serveur prêt conserve sa capacité. Il est donc prêt à servir
d’éventuelles tâches apériodiques qui surviennent. MAIS, il viole le
principe de “Rate Monotonic” (tâche prête de plus haute priorité doit
s’exécuter). Il diminue le taux d’utilisation du processeur par les tâches
périodiques.
Historique
- page 80/119
Les serveurs de tâches : Serveur sporadique
améliore le temps de réponse des tâches apériodiques sans diminuer le

taux d’utilisation du processeur des tâches périodiques.
Ce serveur est également une tâche périodique de + haute priorité, qui
conserve sa capacité de traitement si, à son réveil, il n’y a pas de tâche
apériodique à servir. Mais ici, le serveur sporadique ne retrouve pas sa
capacité initiale à chaque occurence.
Historique
- page 81/119
Commentaires : “Serveur sporadique”
La figue montre le fonctionnement d’un serveur sporadique sur le même

ensemble de tâches que précédement : T1 (r0 =0, C=3, P=20) et T2 (r0 =0,
C=2, P=10). La tâche serveur est Ts (r0 =0, C=2, P=5).
A t=0, le serveur se réveille, mais se suspend car pas de tâches
apériodique à traiter (mais il conserve sa capacité, 2).
A t=4, la tâche apériodique Ta3 survient. Elle est servie immédiatement
entre t=4 et t=6 et consomme toute sa capacité. Comme le serveur s’est
exécuté, une date de réinitialisation de sa capacité est calculée : ce sera
t=4+5. La valeur de réinitialisation est 2.
Historique
- page 82/119
Commentaires : “Serveur sporadique” (suite)
A t=9, le serveur retrouve toute sa capacité, mais il se suspend car il

n’ya pas de tâche apériodiques en attente.
A t=10, la tâche Ta4 arrive et s’exécute tout de suite pendant une unité
(C=1). Puis Ta5 arrive et commence à s’exécuter pendant une unité et
elle est suspendue jusqu’à nouvelle occurence du serveur (car sa
capacité est épuisée). Une nouvelle date de réinitialisation de la
capacité est calculée : t=10+5. La tâche Ta5 poursuivra son exécution
pour une unité quand le serveur aura récupéré sa capacité à t=15. Il
reste au serveur 1 unité qu’il récupérera à t=20.
Historique
- page 83/119
Chronogramme : Ordonnancement “avec un serveur sporadique”
T1 (r0=0, C=3, P=20)
temps
0 2 4 6 7 20
T2 (r0=0, C=2, P=10)
temps
0 2 10 12 14 20
Tps (r0=0, C=2, P=5)

taches apériodiques
temps
0 4 6 10 11 12 15 16 20
Tap3(r=4, c=2)
Tap4(r=10, c=1) Tap5(r=11, c=2)
capacité du serveur
2 temps
1
0
0 6 9 10 12 15 20
F IGURE: Ordonnancement “avec un serveur sporadique”
Historique
- page 84/119
Tâches apériodiques à contraintes strictes
Une méthode consiste à doter les tâches apériodiques avec des

pseudo-périodes : c’est l’intervalle minimal entre deux occurences
successives d’une tâche apériodique. On utilise “RM” pour ordonnancer
les 2 types de tâches. Difficulté : l’évaluation de la pseudo-période et la
sous-utilisation du processeur.
Une autre méthode : les tâches apériodiques sont traitées sans
hypothèse sur leur rythme d’arrivée. Elles sont ordonnancées selon
“Earliest Deadline”. A chaque arrivée d’une tâche apériodique, une
“routine” de garantie teste dynamiquement si la nouvelle peut s’exécuter
en respectant ses CT, celles des tâches périodiques et celles des autres
tâches apériodiques précédemment acceptées mais non terminées. Si
le test est positif, la tâche est acceptée.
Historique
- page 85/119
Méthodes pour tâches apériodiques à contraintes strictes
∃ 2 politiques d’acceptation dynamique de tâches apériodiques qui

favorisent toutes les 2 les tâches périodiques, car les tâches
apériodiques génératrices de surcharge sont rejetées. Ces politiques
sont applicables natament sur un système réparti où un mécanisme de
partage de charge permet de faire exécuter une tâche rejetée sur un
site par un autre site moins chargé. Ces 2 politiques sont :
1. Acceptation dans les temps creux d’une séquence rigide de tâches :
consiste à ordonnanncer les tâches apériodiques dans les temps creux
de la séquence d’ordonnancement “ED” des tâches périodiques. Proche
de la politique en ’arrière-plan’ vue précédemment, mais ici les tâches
apériodiques ont des CT à respecter et sont elles-mêmes
ordonnancées selon “ED”. A chaque réveil d’une tâche apériodique, une
routine de garantie est exécutée.
Historique
- page 86/119
Routine de garantie
1. teste l’existence d’un temps creux suffisant pour l’exécution de la

tâche apériodique entre sa date de reveil et son échéance.
2. si ce temps creux existe, elle vérifie que l’acceptation de la nouvelle
tâche ne remet pas en cause le respect des CT de tâches apériodiques
précédemment acceptées, non encore achevées. Cette vérification ne
concerne que les tâches apériodiques dont les échéances sont ≥ à
celle de la nouvelle tâche.
Si au moins une des condition 1 ou 2 n’est pas satisfaite, alors la tâche
est rejetée, sinon elle est ajoutée à l’ensemble des tâches apériodiques
acceptées, pour être exécutée selon son échéance.
Historique
- page 87/119
Exemple
La figure 16 montre que la configuration périodique “ED” présente

durant la période d’étude 3 intervalles de creux : [8,10], [13,15] et
[17,20]. Les 3 tâches apériodiques Ta4 , Ta5 et Ta6 peuvent être
acceptées dans ces temps creux :
Historique
- page 88/119
Exemple : déroulement
à t=4, Ta4 se réveille.Le temps creux existant entre sa date de réveil et

son échéance est l’intervalle [8,10] = 2 unités juste suffisantes pour
exécuter la tâche. Ta4 dispose donc d’assez de temps pour s’exécuter
dans le respect de ses CT, et comme il n’a pas d’autre tâches
apériodiques précédemment acceptées mais non terminée, elle est
acceptée.
à t=10, Ta5 se réveille. Le temps creux existant entre sa date de réveil
10 et son échéance 18, est de 3 unités (tout l’intervalle [13,15] + 1 unité
de l’intervalle [17,20]). Il y a donc d’assez de temps pour exécuter Ta5
qui a un temps d’exécution égal à 1. Et comme il n’a pas de tâches
apériodiques acceptées et non terminées (Ta4 s’était exécutée entre 8
et 10), alors Ta5 peut être acceptée.
Historique
- page 89/119
Déroulement (suite)
A t=11, Ta6 se réveille. Le temps creux existant entre sa date de réveil

11 et sont échéance 16 est de 2 unités ( [13,15]), donc juste suffisant
pour l’exécuter dans le respect de son échéance. Mais, il faut vérifier
que son acceptation ne remet pas en cause les CT des autres tâches
apériodiques acceptées non terminées (et d’échéances plus éloignées
que la sienne). Ici Ta5 qui n’a pas encore commencé son exécution et
dont l’échéance est 18. L’ordre d’exécution devient Ta6 puis Ta5 et on
constate que chacune peut s’exécuter dans le respect de ses CT (car
C=2 pour Ta6 et C=1 pour Ta5 ). lon son échéance.
Historique
- page 90/119
Ordonnancement dans les temps creux : Routine de garantie
T1 (r0=0, C=3, D=7, P=20)
temps
0 2 5 7 20
T2 (r0=0, C=2, D=4, P=5)
temps
0 2 4 5 6 8 9 10 12 14 15 17 19 20
T3 (r0=0, C=1, D=8, P=10)
temps
0 5 6 8 10 12 13 18 20
temps creux
8 10 13 15 17 20
taches aperiodiques
4 8 10 11 13 15 16 17 18 20
Ta4(r=4, c=2, d=10) Ta5(r=10, c=1, d=18) Ta6(r=11, c=2, d=16)
F IGURE: Ordonnancement “ dans les temps creux”
Historique
- page 91/119
2. Acceptation des tâches apériodiques et ordonnancement conjoint

aux tâches périodiques
2. Acceptation des tâches apériodiques et ordonnancement conjoint aux

tâches périodiques : à chaque arrivée d’une nouvelle tâche apériodique,
il y a construction d’une nouvelle séquence “ED” comprenant à la fois
les tâches périodiques, les tâches apériodiques précédemment
acceptées mais non terminées et la nouvelle tâche. Si la séquence peut
être construite, alors la tâche est acceptée. Les figures 17 et 19 montre
un exemple de fonctionnement et on voit que les 3 tâches apériodiques
Ta4 , Ta5 et Ta6 peuvent être ordonnancées conjointement aux tâches
périodiques.
A t=4, Ta4 se réveille. La séquence “ED” construite à t=4 comprend les
tâches périodiques actives T1 (C(4)=1, d=7) et T3 , les requêtes à venir
des tâches périodiques ainsi que la tâche qui arrive Ta4 . L’exécution de
celle-ci sera planifiée entre t=8 et t=10. La séquence respecte les CT de
toutes les requêtes qui la composent.
Historique
- page 92/119
2. suite
A t=10, Ta5 se réveille. La séquence “ED” construite à t=10 comprend

les requêtes à venir des tâches périodiques T2 et T3 et celle de Ta5 . Ici
aussi, la séquence “ED” permet le respect des CT de toutes les
requêtes qui la composent. L’exécution de Ta5 acceptée est planifiée
entre 13 et 14.
A t=11, Ta6 se réveille (figure suivante 2.12). La séquence “ED”
construite à t=11 comprend les tâches périodiques actives T2 (C(11)=1,
d=14) et T3 , les requêtes à venir de la tâche périodique T2 ainsi que les
tâches apériodiques Ta5 et Ta6 . La tâche Ta6 peut être ordonnancée
sans remettre en cause ni les échéances des tâches périodiques, ni
celle de la tâche apériodique Ta5 . Ta6 est donc acceptée.
Historique
- page 93/119
Ordonnancement conjoint
T1 (r0=0, C=3, D=7, P=20)
temps
0 2 5 7 20
T2 (r0=0, C=2, D=4, P=5)
temps
0 2 4 5 6 8 9 10 12 14 15 17 19 20
T3 (r0=0, C=1, D=8, P=10)
temps
0 5 6 8 10 12 13 18 20
taches aperiodiques
temps
4 8 10 13 14 18 20
Ta4(r=4, c=2, d=10) Ta5(r=10, c=1, d=18)
F IGURE: Ordonnancement “conjoint”
Historique
- page 94/119
Ordonnancement conjoint
T1 (r0=0, C=3, D=7, P=20)
temps
0 2 5 7 20
T2 (r0=0, C=2, D=4, P=5)
temps
0 2 4 5 6 8 9 10 12 14 15 16 18 19 20
T3 (r0=0, C=1, D=8, P=10)
temps
0 5 6 8 10 14 15 18 20
taches aperiodiques
temps
4 8 10 11 12 14 15 16 18 20
1
0
0
1 1
0
01
1 0
0
1 0
1 0
1
0
1
0
1 01
1
0
1
0
0
1
0
1 01
1 0
1
0
0
1 0
1 0
1
0
1
0
1 01
1
0
1 0
0
1
0
10
1
0
10
1
0
1
111
0000
1
0
10
1
0
10
1
0
10
1
Ta4(r=4, c=2, d=10) Ta5(r=10, c=1, d=18) Ta6(r=11, c=2, d=16)
F IGURE: Ordonnancement “conjoint”
Historique
- page 95/119

Paramètres de priorité
définis selon l’application industrielle (fréquence d’acquisition des

données, ...)
certaines applications induisent des contraintes de précédence que l’on
doit retrouver dans le modèle de tâches.
Historique
- page 96/119
Exemple : Caméra pour la reconnaissance et la vérification
T1, T2 : acquisition
T3, T4 : pré-traitement
T5 : extraction de caractéristiques
T6 : détection de contours
T7 : estimation de la hauteur
T8 : Reconnaissance finale
Historique
- page 97/119
Graphe de précédence
tache
T1
pecedence
T2 T3
T4 T5
F IGURE: précédence
Historique
- page 98/119
Commentaires
Tx → Ty : Tx est un prédécesseur direct de Ty . Ex. T1 → T2

Tx < Ty : Tx est un prédécesseur direct ou indirect de Ty . Ex. T1 < T4
Historique
- page 99/119

A. Contraintes de précédence
Ti → Tj si Tj doit attendre la fin de l’exécution de Ti pour commencer

son exécution.
Si A précéde B alors {(1) rB ≥ rA , (2) si A périodique alors B l’est
également et (3) priorité(A) > priorité (B)}
Historique
- page 100/119
Contraintes de précédence et ’Rate Monotonic’
Idée : Une tâche ne doit pas commencer avant son prédecesseur, et ne

doit préempter son successeur.
dans le cas de l’ordonnancement selon “RM”, on transforme hors ligne
l’ensemble des tâches liées par une contrainte de précédence en un
ens. de tâches indépendantes pour lesquelles le test d’acceptabilité de
“RM” est valide, en faisant :
calcul des dates de réveil : ri∗ = max{ri , rpred
∗ ∗
} avec rpred date de réveil de
la tâche précédant la tache i.
et Si A et B ont même période avec A qui précéde B alors priorité (A) >
priorité (B)
Historique
Precedence C∗i r∗i P∗i

—————– ———- ———– ————
0/ -> T∗i Ci ri Pi
—————– ———- ———– ————
T∗j -> T∗i Ci max(ri , r∗j ) Pi et > P∗j
—————– ———- ———– ————
T∗j -> T∗i
T∗k -> T∗i Ci max(ri , r∗j , r∗k ) Pi et max(P∗j , P∗k )
—————– ———- ————— ——————-
Tj
Ti
Tk
F IGURE: graphe 3 noeuds
Historique
- page 101/119
Exemple/Exercice : précédence avec RM
T1*
T3*
T5*
T2* T4*
F IGURE: exemple de précédence
Historique
tache Ci ri Pi r∗i
—————– ———- ———– ———— ————
T∗1 1 0 12 r∗1 =r1=0
—————– ———- ———– ———— ——————–
T∗2 2 5 14 r∗2 =r2=5
—————– ———- ———– ———— ——————–
T∗3 2 0 10 r∗3 =max(r3 ,r∗1 )=max(0,0)=0
—————– ———- ———– ———— ——————–
T∗4 1 0 8 r∗4 =max(r4 ,r∗1 ,r∗2 )=max(0,0,5)=5
—————– ———- ———– ———— ———————–
T∗5 3 0 16 r∗5 =max(r5 ,r∗3 ,r∗4 )=max(0,0,5)=5
—————– ———- ————— ——————- ——————–
Calcul des r∗i
Historique
tache Ci ri Pi P∗i
—————– ———- ———– ———— ————
T∗1 1 0 12 P∗1 =P1 -> 12
—————– ———- ———– ———— ——————–
T∗2 2 5 14 P∗2 =P2 -> 14
—————– ———- ———– ———— ——————–
T∗3 2 0 10 P∗ ∗
3 =(P3 =10) et > (P1 =12) -> 13
—————– ———- ———– ———— ——————–
T∗4 1 0 8 P∗ ∗ ∗
4 =(P4 =8) et > max(P1 =12,P2 =14) -> 15
—————– ———- ———– ———— ———————–
T∗5 3 0 16 P∗ ∗ ∗
5 =(P5 =16) et > max(P3 =13,P4 =15) -> 16
—————– ———- ————— ——————- ——————–
Calcul des P∗i
Historique
- page 102/119
Conservation des conditions après transformation
Somme(Ci /Pi <= n(21/n -1) :

1/12+2/14+2/10+1/8+3/16 <= 5(21/5 -1)
0.738 <= 0.743
—————————————————————
Somme(C∗i /P∗i <= n(21/n -1) :
1/12+2/14+2/13+1/15+3/16 <= 5(21/5 -1)
0.634 <= 0.743
Historique
- page 103/119
Contraintes de précédence et ’Earliest Deadline’
la prise en compte de la précédence est réalisée

en modifiant ri , di ,ri∗ , di∗ , selon les formules :
ri∗ = max{ ri , max(rpred
∗ +C
pred ) }, c-à-d la date de début d’une tâche doit
être supérieure à toutes les dates de début de ses prédécesseurs
immédiats augmentées de leurs durées d’exécution.
di∗ = min{di , min(dsucc
∗ -C
succ ) }, c-à-d pour une instance donnée,
l’échéance d’une tâche doit être inférieure à toutes les échéances de ses
successeurs immédiats diminuées de leurs temps d’exécution.
Historique
C∗
i = prec. r∗
i = prec. D∗i =
—————– ———- ———– ———— ————
Ci 0/ -> Ti ri Ti -> 0/ Di
—————– ———- ———– ———— ————
Ci Tj -> Ti max(ri , r∗j + Cj ) Ti -> Tj min(Di , D∗
j -Cj )
—————– ———- ———– ———— ————
Ci Tj -> Ti et Tk -> Ti max(ri , r∗ ∗
j + Cj , rk +Ck ) Ti -> Tj et Ti -> Tk min(Di , D∗ ∗
j -Cj , Dk -Ck )
—————– ———- ————— ——————- ————
Tj*
Tj *
Ti*
Ti
*
Tk * Tk*
F IGURE: graphes 3 noeuds pour EDF
Historique
- page 104/119
Exemple/Exercice : précédence avec EDF
T1*
T3*
T5*
T2* T4*
F IGURE: exemple de précédence
Historique
tache ∗
Ci =Ci ri Di ∗ ri
—————– ———- ———– ———— ————
T∗
1 1 0 12 r∗1 1 =0
=r
—————– ———- ———– ———— ——————–
T∗
2 2 5 14 r∗2 =r2 =5
—————– ———- ———– ———— ——————–
T∗
3 2 0 10 r∗
3 =max(r ,r∗ +C )=max(0,1)=1
3 1 1
—————– ———- ———– ———— ——————–
T∗
4 1 0 8 r∗ ∗ ∗
4 =max(r4 ,r1 +C1 ,r2 +C2 )=max(0,1,7)=7
—————– ———- ———– ———— ———————–
T∗
5 3 0 16 r∗
5 =max(r ,r∗ +C ,r∗ +C )=max(0,3,8)=8
5 3 3 4 4
—————– ———- ————— ——————- ——————–
Calcul des r∗i

NB : On commence par calculer r1 , puis r2 , puis .... r5
Historique
tache ∗
Ci =Ci ri Di ∗
ri Di∗
—————– ———- ———– ———— ———— ————
T∗
1 1 0 12 =0 min(D1, D4*-C4, D3*-C3)= min(12,7,8) = 7
—————– ———- ———– ———— ——————– ——————–
T∗
2 2 5 14 =5 min(D2, D4*-C4) = min(14,7) = 7
—————– ———- ———– ———— ——————– ——————–
T∗
3 2 0 10 =1 min(D3, D5*-C5) = min(10, 13) = 10
—————– ———- ———– ———— ——————– ——————–
T∗
4 1 0 8 =7 min(D4, D5*-C5) = min(8,13) = 8
—————– ———- ———– ———— ———————– ——————–
T∗
5 3 0 16 =8 D5 = 16
—————– ———- ————— ——————- ——————– ——————–
Calcul des D∗i

NB : On commence par calculer D5 , puis D4 , puis .... D1
Historique
- page 105/119
Conservation des conditions après transformation
Somme(Ci /Di <= 1 : 1/12+2/14+2/10+1/8+3/16 <= 1

0.738 <= 1
—————————————————————
Somme(C∗i /D∗i <= 1 : 1/7+2/7+2/10+1/8+3/16 <= 1
0.941 <= 1
Historique
- page 106/119

B. Tâches partageant des ressources critiques
Problèmes :
Evaluer le temps de réponse d’une tâche
Inversion de priorité : apparaît quand une tâche A est retardée par une
tâche moins prioritaire B (car A a demandé une ressource déjà détenue
par C, moins prioritaire que A et B)
Interblocage (la tâche A détient la ressource R1 et demande la ressource
R2. En même temps, la tâche B détient la ressource R2 et demande R1).
Historique
Prio(T1) > Prio(T2)
Ri une tache demande

R2 R1
la ressource Ri
T1
temps
R1 R2 Interblocage !
T2 temps
Figure : probleme d’interblocage

Ri
=> une solution : les classes ordonnees (chaque tache demande les ressources dans l’ordre)
R2 R2 Liberation de Ri
R1,R2
Fin de T1
T1 temps
R1 R2 R1,R2
Fin de T2
T2 temps
F IGURE: Exemple de problème d’interblocage et une solution
Historique
On a : Pri(T1) > Pri (T2) > Pri(T3) > Pri(T4)
T1 temps
R1 R1
T2
temps
T3
temps
R1 R1
T4 temps
Ri Ri liberation ress. crit.

sans ress. critique demande ress. crit.
avec ress. critique
F IGURE: Exemple du problème d’inversion de priorité
Historique
- page 107/119
Protocoles prenant en compte les ressources partagées
Héritage de priorité (PIP, Priority Inheritance Protocole) : résoud le problème

d’inversion de priorité : la tâche en section critique hérite de la plus haute
priorité parmi celles des tâches en attente (bloquées). La durée de l’attente des
tâches peut être très grande (car l’interblocage n’est pas résolu).
Priorité plafond (PCP, Priority Ceiling Protocol) : Limite la durée maximale de
blocage des tâches à la durée d’une section critique et prévient les
interblocages (deadlock). L’idée est que chaque ressource se voit affectée une
priorité égale à celle de la tâche de plus haute priorité qui va y accéder.
Historique
R1 R1
T1 temps
R2
R2
T2 temps
R1 R2
R1
R2
T3 temps
heritage prio. de T2 heritage prio. de T1

tache elue Ri
Ri
demande ress. crit. libration ress. crit.
tache occupant la ress. R1
tache occupant la ress. R1 et R2
tache occupant la ress. R2
F IGURE: Solution au pb d’inversion de priorite avec PIP
Historique
F IGURE: Solution au pb d’inversion de priorite avec PCP

Historique
- page 108/119
Situations de surcharge
Quelques éléments
quand la charge du processeur devient telle qu’il est impossible de respecter

toutes les échéances
Ex. EDF et RM –> mauvaises performances en situations de surcharge
Eviter ces fautes temporelles => plusieurs politiques, qui se basent sur des
modèles de tâches plus élaborés
Historique
- page 109/119
Tolérance aux surcharges pour tâches périodiques
1. Méthode du mécanisme à échéance

2. Méthode du calcul approché
Historique
- page 110/119
Méthode du mécanisme à échéance
Chaque tâche = version primaire et version secondaire

Version primaire : fournit un résultat avec une bonne QdS mais au bout d’un
temps indéterminé.
Version secondaire : fournit un résultat acceptable en un temps borné (connu à
l’initialisation)
Historique
- page 111/119
Méthode du mécanisme à échéance

algorithme de tolérance aux fautes
Doit assurer le respect des échéances soit par le primaire, soit par le
secondaire.
Si le primaire et le secondaire sont exécutés => le résultat du primaire est utilisé.
L’ordonnancement consiste en la juxtaposition d’une séquence des primaires et
d’une séquence des secondaires et d’une régle de décision pour commuter de
l’une à l’autre.
Il existe 2 politiques : 1ère chance et 2ème chance
Historique
- page 112/119
Tâches périodiques-Mécanisme à échéance : politque 1ère chance
politque 1ère chance

Priorié(Secondaires) > priorité (Primaires) => Primaires ordonnancées
dans les temps creux des secondaires associées
politque 2ème chance
Priorié(Primaires) > priorité (Secondaires) => Primaires exécutées avant
leurs secondaires associées, lesquelles sont ordonnancées plus tard.
Si l’exécution du la primaire réussit, la secondaire n’est pas exécutée.
Historique
- page 113/119
Méthode du calcul approché
Chaque tâche = partie obligatoire + partie optionnelle

Partie obligatoire : fournit un résultat approché et doit s’exécuter avant
l’échéance.
Partie optionnelle : affine le résultat et s’exécute s’il reste assez de temps avant
l’échéance.
Historique
- page 114/119
Éléments sur la tolérance aux surcharges pour tâches quelconques
En plus de l’échéance, ces politiques prennent encompte le critère

dimportance d’une tâche, qui définit son caractère primordial dans l’application
=> 2 tâches de même échéance peuvent avoir des importances différentes.
Ordonnancement à importance : à chaque réveil de tâche (périodique ou non),
un test de garantie définit si la nouvelle tâche engendre une faute temporelle ou
non.
Ce test est basé sur la laxité dynamique du système LP(t), qui devient négative
si une surcharg est détectée.
Historique
- page 115/119
Quelques éléments
Systèmes temps réel et répartis : Communication intra et inter sites. Envoi de

messages. Problème : respecter les temps de transfert des messages en
bornant les délais.
Un message peut être caractérisé par :
sa criticité (criticality ) : ce sont les contraintes de temps associées au
message
sa longueur : nombre d’octets composant le message. Les messages sont
transmis trame par trame sur le réseau. La longueur d’une trame = f(type
de réseau)
son type : synchrone, asynchrone
son adresse de destination
Historique
- page 116/119
Protocoles
Plusieurs protocoles sont définis, en fonction du type de réseau :

- Réseau à commutation de paquets : chaque station est reliée au réseau
et ne connait pas les protocoles utilisés pour communiquer à l’intérieur du
réseau. La station établit une connexion selon un contrat lui garantissant
une certaine QoS (taux de perte, délai max, ...). La station (considérée
comme un abonné) s’adresse au noeud (commutateur ATM par exemple)
auquelle elle est raccordée, et le noeud se charge du transfert. Les
stations ne rentrent pas en conflit.
- Réseau à accès multiple : Les stations connectées au réseau contrôlent
l’accès au réseau via une technique MAC (Medium Access Control)
implantée sur chaque station. L’accès au médium est soit par compétition,
soit par consultation (jeton). Les mécanismes d’ordonnancement des
messages sont implantées dans les stations (pour respecter les CT)
Historique
- page 117/119
Types d’ordonancements
Ordonnancement des messages : les techniques d’ordonnancement sont

adaptées de celles des tâches (ED, RM, notamment)
Pour ordonnancer les tâches, on doit connaître leurs temps d’exécution. Pour
ordonnancer les messages, il faut connaître leurs temps de transmission. La
durée de transmission est fonction de la taille du message, du débit et de la
longueur du réseau, du format des trames-réseau utilisées et du protocole.
Exemple : pour le bus à jeton, la durée de transmission d’un message de n
octets est 96+8xn µs (on considère que les adresses sont codées sur 2 octets,
un seul octet est utilisé comme information pour la trame, on néglige le délai
inter-trames. Le délai de transmission du jeton est 96 µs)
Historique
- page 118/119
Exemple : Bus à jeton
Ensemble des station = anneau logique. Le droit d’émettre est réservé à une
seule station : celle qui a le jeton. Quand une station a le jeton, elle émet des
trames pendant une durée fixée, puis transmet le jeton. Le bus à jeton peut
fonctionner avec ou sans priorités. Des paramètres sont utilisés : temps de
posssession du jeton, 3 compteurs de rotation du jeton, notamment.
Avec tous ces éléments, des protocoles spécifiques sont définis pour
ordonnancer les tâches et les messages dans un système distribué.
Historique
- page 119/119
Les SGBD Temps Réel
Systèmes de gestion de bases de données permettant de respecter :

Les contraintes logiques de la base de données (respecter les contraintes
d’intégrité), et
Ses contraintes temporelles (Chaque transaction doit respecter son
échéance)

1 Cours STR 2012 v4 PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

1 Cours STR 2012 v4 PDF

Загружено:

Авторское право:

Доступные форматы

Historique

Ordonnancement de tâches indépendantes

Systèmes temps réel et Ordonnancement - B. Sadeg

Université du Havre - UFR ST - LITIS - Équipe STI

2 Ordonnancement de tâches indépendantes

3 Ordonnancement de tâches dépendantes

4 Ordonnancement dans des situations de surcharge

5 Ordonnancement conjoint tâches et messages

le temps : rôle de + en + important dans les services et les applications

Maîtrise du temps : d’abord, plus de puissance de calcul, puis apparition de

Définition d’un système temps réel (STR)

système dont le comportement dépend non seulement de

Système informatisue Procédé

F IGURE: Schéma d’une application temps réel

Système temps réel : calcul de la position d’un bateau en mouvement.

Exemples d’applications temps réel

Commandes de procédés, Systèmes embarqués, Guidage de mobiles,

Les applications déclenchent des événements à occurence périodique

Types d’échéances et de systèmes temps réel

échéance dure (hard) : le dépassement de l’échéance provoque une

Caractéristiques dun système temps réel(1)

La prévisibilité d’un STR : est un aspect important.

Le déterminisme d’un STR : est le but à atteindre pour assurer la

L’organisation du système en couches facilite son évolution.

Charge de calcul (durées d’exécution variées)

Le déterminisme absolu : difficile à atteindre

Est un autre aspect important des STR

Pas d’intervention humaine directe

1. Le robot : doit prendre des objets qui défilent sur un tapis

Exemples d’application (2)

2. Système de vidéo-conférence : sur un réseau local.

Systèmes d’exploitation classiques

Plate−forme professionnelle : IHM :

Service de noms ...

Bases de donnees Noyau :

gest. horloge pilotes priphriques

gest. it. pilotes rseau

gest. de taches gest. semaphores Materiel

F IGURE: Structure d’un syst. d’expl. classique

Limites des systèmes classiques pour le temps réel

Reposent sur un OS qui offre des mécanismes mal adaptés au temps

On ne dispose pas de moyens pour indiquer à l’OS le degré d’urgence

Noyau : rend l’ensemble des services de base nécessaires à l’exécution

Ordonnancements classiques : multiprogrammation

Objectifs : maximiser le taux d’utilisation du processeur 1 et minimiser le

1. temps où le processeur est actif/temps total. En théorie : 0-100%, en pratique :40-95%

Principales politiques (1)

→ déterminer quelle tâche prête doit être élue

Principales politiques (2)

4. Tourniquet (RoundRobin) : on définit un quantum de temps (10ms à

T1 (C1=20 unites) T2 (C2= 7 unites) T3 (C3= 3 unites)

Ordonnancement par Tourniquet (Round Robin)

F IGURE: Exemple : Tourniquet (Round Robin)

Principales politiques (3)

FILE N−1 q N−1

Ordonnancement : Files multi−niveaux

F IGURE: Exemple : Files multi-niveaux : priorités constantes/variables

Aucune des politiques présentées ne permet de remplir les 2 objectifs

Terminologie pour l’ordonnancement des tâches temps réel

tâche = unité de base de l’ordonnancement temps réel. Sont

Illustration : diagramme temporel d’exécution

F IGURE: Modèle de tâches

Tâche à contraintes relatives : D parfois omis