Vous trouverez ici un bref résumé de quelques-uns des principaux symboles et éléments de vocabulaire que l'on retrouve dans la littérature portant sur l'étude de l'ordonnancement des tâches dans un contexte de STR et sur l'impact des divers paramètres suseceptibles d'affecter la capacité de ces tâches de respecter leurs contraintes.
Notez que la dénomination des tâches selon les types de contrainers auxquelles elles sont assujetties est de moi; il se peut que la terminologie dans la littérature diffère, mais en pratique, c'est une dénomation qui m'a toujours semblée claire et utile
Une tâche TR offre des garanties de comportement; dit autrement, il s'agit d'une tâche qui est assujettie à des contraintes. Ces garanties sont typiquement de l'un des quatre types suivants :
B : garantie de brièveté. On entend ici une tâche qui, une fois démarrée, se terminera dans un temps maximal connu au préable. C'est vers le respect d'une contrainte de brièveté que mène typiquement l'optimisation d'une fonction lorsque cette optimisation vise à en réduire le temps d'exécution
R : garantie de régularité. On entend ici une tâche dont l'exécution se fera un nombre connu au préalable de fois par période de temps (informellement : fois par seconde)
I : garantie d'immédiateté. On entend ici une tâche dont l'exécution démarrera après un délai maximal connu au préalable suivant l'occurrence d'un événement. C'est ce que les gens entendent typiquement par le terme basse latence
C : garantie de constance. On entend ici une tâche dont l'exécution se fera un nombre connu au préalable de fois par période de temps, mais de manière telle que le début de chaque exécution se fera au même point dans son cycle d'exécution (informellement à chaque seconde)
Les tâches TR peuvent être groupées en familles, soit :
On nomme échéance (en anglais, Deadline) le seuil le plus tardif au moment duquel une tâche peut avoir été complétée. Si une tâche dans un STR manque son échéance, son résultat n'est pas valide. Notation
On nomme instant critique d'un ordonnancement le moment où toutes les tâches seraient prêtes à s'exécuter de manière simultanée. Pour plusieurs stratégies d'ordonnancement, en particulier celles de la famille des ordonnanceurs FPS, il s'agit du pire cas de charge pour le système
On nomme période d'une tâche périodique (évidemment) le rythme auquel cette tâche devra être lancée. Notation
On utilise l'acronyme WCET (Worst Case Execution Time) pour indiquer le pire cas en termes de temps d'exécution pour une tâche donnée. Notation
Le temps d'arrivée d'une tâche est le moment auquel cette tâche devient disponible pour être ordonnancée. Pour une tâche périodique, la période seule dicte le comportement de ce paramètre, mais il en va autrement pour une tâche apériodique ou pour une tâche sporadique.
Quelques symboles reviennent plus souvent que d'autres dans la notation utilisée pour exprimer des tests d'ordonnançabilité. La table ci-dessous liste quelques-uns d'entre eux et peut servir à titre de référence. Si vous préférez, j'ai aussi mis à votre disposition un document PDF contenant essentiellement la même information.
| Notation | Rôle |
|---|---|
|
Blocage de la tâche , dû à des verrous, des entrées/ sorties, une inversion de priorités, etc. |
|
WCET de la tâche , typiquement obtenu de manière analytique. Mnémonique : pensez à Computing ou à « calcul ». Voir aussi cet article. |
|
|
Coût associé au code de tolérance aux pannes (pensez à fault) pour la tâche , ce qui tient compte entre autres de la gestion des cas d'exceptions |
|
|
Pire temps d'exécution dans la section critique (ici, section critique signifie toute zone susceptible de provoquer un blocage en attente d'une ressource) |
|
Échéance (pensez à deadline) pour démarrer la tâche sporadique . |
|
|
Ensemble des tâches , donc de plus haute priorité que celle de la tâche . En pratique, dans un SETR où les tâches ont toutes des priorités distinctes (où ), seules ces tâches peuvent interférer avec la tâche . |
|
|
Ensemble des tâches , donc de priorité plus grande ou égale à celle de la tâche . En pratique, dans un SETR, seules ces tâches peuvent interférer avec la tâche . |
|
|
Interférence maximale de la tâche . Notez que la tâche la plus prioritaire ne subira pas d'interférence, alors que les autres en subiront, par définition. Par , on entend les cas où une tâche empêcherait, de par son exécution, l'ordonnancement la tâche |
|
|
Ce qu'on nomme le Release Jitter de la tâche . Intervient quand la tâche est lancée par une tâche . Représente le pire cas de latence entre la demande de lancement d'une tâche et son lancement effectif. |
|
|
Nombre de tâches à considérér – cardinalité de l'ensemble des tâches à ordonnancer. |
|
|
Moment auquel une tâche devient disponible pour exécution (Release Time). Puisqu'une exécution ne peut se débuter avant que la précédente n'ait été complétée, ce facteur est aussi considéré comme le temps maximal d'exécution d'une tâche une fois les interférences prises en compte. |
|
Période de la tâche . Mnémonique : avez-vous des sugestions? |
|
|
Intervalle minimal entre deux pannes, lorsque du code de tolérance aux pannes doit être considéré. |
|
|
Fonction booléenne évaluée à seulement si la ressource est utilisée par au moins une tâche de priorité . |
Voilà!
