OP donne un exemple où l'héritage de priorité est souhaitable. Nous avons une courte transaction protégée par mutex entre des threads de plus haute et plus basse priorité et un thread à longue durée d'exécution avec une priorité moyenne qui pourrait bloquer la transaction si l'héritage de priorité n'est pas utilisé. De plus, dans cet exemple, le thread de haute priorité est plus important pour l'application que le thread de priorité moyenne.
Pour rendre l'héritage de priorité non souhaitable, nous pourrions créer une application où toutes ces hypothèses sont contraires à l'exemple ci-dessus. Faisons une transaction entre des threads de plus haute et plus basse priorité plus longue que le temps disponible pour le thread de priorité moyenne pour effectuer sa tâche. Et supposons que les résultats de ce thread de priorité moyenne sont plus importants que les résultats du thread de haute priorité.
Imaginez une application qui doit gérer 100 interruptions par seconde avec son thread de haute priorité. Et 10 interruptions par seconde avec son thread de priorité moyenne (où chaque interruption nécessite 30 ms pour être traitée). Le thread de basse priorité pourrait verrouiller une ressource (utilisée avec le thread de haute priorité). Et parfois (très rarement), il pourrait la verrouiller pendant longtemps (1 sec). Avec l'héritage de priorité, le premier accès à cette ressource par le thread de haute priorité augmente la priorité du thread en arrière-plan pendant jusqu'à 1 seconde. Ainsi, le thread de priorité moyenne manquerait 10 interruptions. En même temps, le thread de haute priorité pourrait manquer 100 interruptions. Sans héritage de priorité, le thread de priorité moyenne gère toutes les interruptions, mais le thread de haute priorité en manque jusqu'à 130. Si les interruptions gérées par le thread de priorité moyenne sont plus précieuses, nous devrions préférer désactiver l'héritage de priorité.
Je n'ai jamais vu une application réelle de ce type. Alors j'en ai inventé une pour illustrer ce cas. Soit une application de capture vidéo avec une tâche de vision par ordinateur en arrière-plan et (en bonus supplémentaire) l'enregistrement audio. Les trames vidéo sont capturées par le thread de priorité moyenne. Le son est capturé par le thread de haute priorité (car sinon le processus de capture vidéo pourrait bloquer une partie importante des interruptions sonores). La vidéo est capturée dans un tampon pré-alloué. L'audio est capturé avec suppression du silence (aucune mémoire n'est nécessaire pour capturer le silence). Ainsi, le thread audio a besoin de blocs de mémoire alloués dynamiquement (c'est notre ressource partagée). La tâche de vision par ordinateur alloue également parfois des blocs de mémoire. Lorsque nous manquons de mémoire, le thread de collecte des déchets bloque l'allocation de mémoire et effectue un travail. Ici, sans héritage de priorité, la capture vidéo fonctionne parfaitement. Mais avec l'héritage de priorité, le thread audio bloque parfois la capture vidéo (ce qui est considéré comme mauvais pour cette application).
Il existe également des applications où l'héritage de priorité ne présente aucun avantage :
- Lorsqu'il y a (1) plusieurs threads en arrière-plan et (2) plusieurs threads de priorité à courte durée de vie. Chaque groupe de threads partage des ressources uniquement à l'intérieur de son propre groupe.
- Lorsqu'une ressource est partagée par les threads avec les priorités 1 et 2, une autre - par les threads avec les priorités 3 et 4, etc.
- Lorsque le processeur dispose de plus de cœurs que de threads critiques en temps dans l'application.
- Dans de nombreux autres cas.
Si l'héritage de priorité est activé dans de tels cas, nous ne pourrions obtenir qu'une dégradation des performances (ou de l'efficacité énergétique) car l'implémentation de l'héritage de priorité dans le noyau nécessite très probablement des ressources supplémentaires.
