Phénomène où, pendant qu'une tâche de haute priorité attend une ressource détenue par une tâche de basse priorité, une tâche de priorité intermédiaire préempte cette dernière et continue de s'exécuter, faisant attendre longtemps la tâche prioritaire.
Nom japonais: 優先度逆転
« Inversion de priorité » apparaît dans 2 questions d'entraînement réparties sur 1 thèmes, dont Systèmes embarqués et firmware.
Domaine: Systèmes embarqués et firmware
Considérons trois tâches dans un système d'exploitation temps réel (RTOS) préemptif : priorité haute (H), moyenne (M) et basse (L). L verrouille un mutex protégeant une ressource partagée. H devient prête, a besoin du même mutex et se bloque en attendant que L le libère. M, qui n'a rien à voir avec la ressource, devient alors prête. Comme M est plus prioritaire que L, l'ordonnanceur exécute M, et L ne peut pas atteindre le point où elle libère le mutex. Tant que M continue de s'exécuter, H attend aussi : en pratique, une tâche de priorité moyenne retarde la tâche la plus prioritaire, ce qui inverse l'ordre voulu.
Un certain blocage est inévitable dès que des tâches partagent une ressource : si L détient le mutex, H doit attendre que L termine sa section critique. Ce délai est borné par la longueur de la section critique et peut être intégré à l'analyse temporelle. Le problème vient de l'interférence de priorité moyenne, qui rend le délai non borné, puisqu'un nombre quelconque de tâches moyennes peut s'exécuter entre-temps. Dans un système temps réel dur, où les échéances doivent être garanties, un délai non borné peut signifier une échéance manquée, une réinitialisation par le chien de garde (watchdog) ou un comportement dangereux, d'où l'attention portée à ce problème.
L'héritage de priorité corrige le problème de façon dynamique : lorsque H se bloque sur un mutex détenu par L, L prend temporairement la priorité de H, de sorte que M ne peut pas la préempter. L termine sa section critique, libère le mutex, revient à sa propre priorité, et H s'exécute. De nombreux mutex de RTOS proposent cette option. Le protocole du plafond de priorité (priority ceiling) est une alternative statique : chaque mutex reçoit la priorité de la tâche la plus prioritaire susceptible de l'utiliser, et toute tâche qui le verrouille est immédiatement élevée à ce plafond. Les protocoles à plafond évitent aussi certains interblocages, au prix d'une analyse des ressources utilisées par chaque tâche.
Un exemple bien connu s'est produit sur l'atterrisseur Mars Pathfinder en 1997. Après l'atterrissage, l'engin a subi des réinitialisations système répétées. Une tâche de haute priorité attendait un mutex détenu par une tâche de basse priorité, elle-même préemptée par des traitements de priorité moyenne, jusqu'à ce qu'un timer chien de garde constate qu'une tâche périodique ne s'était pas terminée à temps et réinitialise le système. Les ingénieurs ont reproduit le problème sur une réplique au sol et l'ont corrigé en activant l'héritage de priorité sur le mutex concerné. Garder les sections critiques courtes et limiter les ressources partagées entre niveaux de priorité restent des règles de conception utiles.
Réponse : A. Pendant qu'une tâche de haute priorité attend une ressource détenue par une tâche de faible priorité, une tâche de priorité moyenne préempte la tâche de faible priorité et s'exécute longuement, si bien que la tâche de haute priorité attend longtemps
Si une tâche de haute priorité attend un mutex détenu par une tâche de faible priorité, elle attend que celle-ci le libère. Si une tâche de priorité moyenne, sans rapport avec la ressource, se met alors à s'exécuter, la tâche de faible priorité est préemptée et ne peut libérer la ressource ; au final, la tâche de haute priorité attend la tâche de priorité moyenne. En 1997, la sonde martienne Mars Pathfinder a subi pour cette raison des réinitialisations répétées du système.
Réponse : C. Élever temporairement la priorité de la tâche de faible priorité détenant la ressource au niveau de la tâche de haute priorité qui l'attend
Avec l'héritage de priorité, lorsqu'une tâche de haute priorité commence à attendre un mutex détenu par une tâche de faible priorité, la priorité de cette dernière est temporairement portée au niveau de la tâche de haute priorité. Elle progresse alors sans être préemptée par la tâche de priorité moyenne et retrouve sa priorité initiale dès qu'elle libère la ressource. L'attente de la tâche de haute priorité se limite au bref temps d'utilisation de la ressource par la tâche de faible priorité. Les mutex de nombreux RTOS disposent de cette fonction.
C'est une situation où une tâche de haute priorité attend une ressource détenue par une tâche de basse priorité, et où une tâche de priorité moyenne préempte cette dernière, si bien que la tâche prioritaire est en pratique retardée par la tâche moyenne. Le délai peut devenir non borné.
L'héritage de priorité n'élève la priorité du détenteur d'un verrou que lorsqu'une tâche plus prioritaire se bloque effectivement sur ce verrou. Le plafond de priorité élève toute tâche à une priorité plafond prédéfinie dès qu'elle prend le verrou, ce qui aide aussi à prévenir les interblocages.
Les réinitialisations répétées ont été attribuées à une inversion de priorité sur un mutex partagé, et les ingénieurs les ont corrigées en activant l'héritage de priorité sur ce mutex dans le logiciel de vol.
RTOS (OS temps réel) Mutex Héritage de priorité Anti-rebond (debounce) Capture d'entrée (input capture) Chargeur d'amorçage (bootloader) Chien de garde (watchdog timer) Débit en bauds Détection de baisse de tension (brown-out) GPIO