Qu'est-ce que l'inversion de priorité?
J'ai entendu l'expression «inversion des priorités» en référence au développement de systèmes d'exploitation.
Qu'est-ce que l'inversion de priorité?
Quel est le problème qu'il est censé résoudre et comment le résout-il?
L'inversion de priorité est un problème, pas une solution. L’exemple typique est un processus de faible priorité qui acquiert une ressource dont un processus de haute priorité a besoin, puis qui est préempté par un processus de priorité moyenne. priorité inférieure).
Le problème rencontré par le rover Mars Pathfinder en est un exemple assez célèbre: http://www.cs.duke.edu/~carla/mars.html , c'est une lecture assez intéressante.
Imaginez trois (3) tâches de priorité différente: tLow, tMed et tHigh. tLow et tHigh ont accès à la même ressource critique à des moments différents; tMed fait sa propre chose.
- tLow est en cours d'exécution, tMed et tHigh sont actuellement bloqués (mais pas dans la section critique).
- tLow arrive et entre dans la section critique.
- tHaute débloque et comme il s’agit de la tâche la plus prioritaire du système, elle s’exécute.
- le tHigh tente alors d'entrer dans la ressource critique mais il se bloque tant que le tLow est dedans.
- le tMed se débloque et, puisqu'il s'agit désormais de la tâche la plus prioritaire du système, il s'exécute.
tHigh ne peut pas fonctionner tant que tLow n’abandonne pas la ressource. Le tLow ne peut pas fonctionner tant que le tMed n'est pas bloqué ou terminé La priorité des tâches a été inversée; tHaut que la priorité soit la plus élevée, elle se situe au bas de la chaîne d'exécution.
Pour "résoudre" l'inversion de priorité, la priorité de tLow doit être augmentée pour être au moins égale à tHigh. Certains peuvent repousser sa priorité au niveau de priorité le plus élevé possible. Il est tout aussi important de hausser le niveau de priorité de tLow que d'abandonner le niveau de priorité de tLow au moment opportun. Différents systèmes adopteront des approches différentes.
Quand abandonner la priorité du tLow ...
- Aucune autre tâche n'est bloquée sur aucune des ressources de tLow. Cela peut être dû à des délais d'attente ou à la libération de ressources.
- Aucune autre tâche contribuant à élever le niveau de priorité de tLow n'est bloquée sur les ressources dont dispose tLow. Cela peut être dû à des délais d'attente ou à la libération de ressources.
- En cas de modification du nombre de tâches en attente des ressources, supprimez la priorité de tLow pour qu'elle corresponde à la priorité de la tâche de niveau de priorité le plus élevé bloquée sur ses ressources.
La méthode n ° 2 est une amélioration par rapport à la méthode n ° 1 en ce qu'elle raccourcit la durée pendant laquelle le niveau de priorité de tLow a été dépassé. Notez que son niveau de priorité reste supérieur au niveau de priorité de tHigh pendant cette période.
La méthode n ° 3 permet de réduire le niveau de priorité de tLow par incréments si nécessaire plutôt que par une étape tout ou rien.
Différents systèmes implémenteront différentes méthodes en fonction des facteurs qu’ils considèrent importants.
- empreinte mémoire
- complexité
- réactivité en temps réel
- connaissances des développeurs
J'espère que cela t'aides.
C'est le problème plutôt que la solution.
Il décrit la situation dans laquelle, lorsque les threads de faible priorité obtiennent des verrous au cours de leur travail, les threads de haute priorité devront attendre leur fin (ce qui peut prendre beaucoup de temps étant donné qu'ils ont une priorité basse). L'inversion ici est que le thread de priorité élevée ne peut pas continuer jusqu'à ce que le thread de priorité basse le fasse. En conséquence, il a également une priorité basse maintenant.
Une solution courante consiste à faire en sorte que les threads de faible priorité héritent temporairement de la priorité élevée de tous ceux qui attendent des verrous qu'ils détiennent.
Supposons qu'une application comporte trois threads:
Thread 1 has high priority.
Thread 2 has medium priority.
Thread 3 has low priority.
Supposons que les threads 1 et 3 partagent le même code de section critique
Les threads 1 et 2 sont en veille ou bloqués au début de l'exemple. Le fil 3 s'exécute et entre dans une section critique.
A ce moment, le thread 2 commence à s'exécuter, préemptant le thread 3 car le thread 2 a une priorité plus élevée. Ainsi, le thread 3 continue de posséder une section critique.
Plus tard, le thread 1 commence à fonctionner, préemptant le thread 2. Le thread 1 tente d'entrer dans la section critique que possède le thread 3, mais parce qu'il appartient à un autre thread, le thread 1 bloque et attend la section critique.
À ce stade, le thread 2 commence à s'exécuter car sa priorité est supérieure à celle du thread 3 et le thread 1 n'est pas en cours d'exécution. Le thread 3 ne libère jamais la section critique que le thread 1 attend, car le thread 2 continue de s'exécuter.
Par conséquent, le thread le plus prioritaire du système, le thread 1, devient bloqué dans l'attente de l'exécution des threads de priorité inférieure.
[Supposer, processus faible = LP, processus moyen = MP, processus élevé = HP]
LP exécute une section critique. En entrant dans la section critique, LP doit avoir acquis un verrou sur un objet, dites OBJ. LP est maintenant dans la section critique.
En attendant, HP est créé. En raison de la priorité plus élevée, le processeur change de contexte et HP s'exécute maintenant (pas la même section critique, mais un autre code). À un moment donné au cours de l'exécution de HP, il doit être verrouillé sur le même OBJ (peut être ou non sur la même section critique), mais le verrou sur OBJ est toujours détenu par LP, car il a été préempté lors de l'exécution de la section critique . LP ne peut pas abandonner maintenant parce que le processus est dans l'état READY, pas en cours d'exécution. Maintenant, HP est déplacé vers l'état BLOCKED/WAITING.
Maintenant, MP entre et exécute son propre code. MP n'a pas besoin de verrouiller OBJ, il continue donc à s'exécuter normalement. HP attend que LP relâche le verrou et LP attend que MP termine son exécution afin que LP puisse revenir à l'état RUNNING (.. et exécuter et libérer le verrou). HP ne peut revenir à READY qu’après que le verrou LP a été relâché (puis passez à RUNNING en anticipant les tâches de faible priorité).
Cela signifie donc que jusqu'à ce que MP ait terminé, LP ne peut pas s'exécuter et donc HP ne peut pas s'exécuter. Il semble donc que HP attend MP, même s'ils ne sont pas directement liés par des verrous OBJ. -> Priorité Inversion.
Une solution pour l’inversion prioritaire est Héritage prioritaire -
augmenter la priorité d'un processus (A) à la priorité maximale de tout autre processus en attente de toute ressource sur laquelle A a un verrou de ressource.
Laissez-moi le rendre très simple et clair. (Cette réponse est basée sur les réponses ci-dessus mais présentée de manière nette).
Supposons qu'il existe une ressource R et 3 processus. L, M, H. où p(L) < p(M) < p(H) (où p(X) est la priorité de X).
Dire
Lcommence à s'exécuter en premier et intercepteR. (accès exclusif àR)Hvient plus tard et veut également un accès exclusif àRet puisqueLle détient,Hdoit attendre.Mvient aprèsHet il n’a pas besoin deR. Et puisqueMa tout ce qu’il veut exécuter, il forceLà partir car il a une priorité élevée par rapport àL. MaisHne peut pas faire cela car il a une ressource verrouillée parLdont elle a besoin pour être exécutée.
Maintenant, pour rendre le problème plus clair, la M devrait en fait attendre que H se termine en tant que p(H) > p(M), ce qui n’est pas arrivé et c’est là le problème. Si de nombreux processus tels que M arrivent et n'autorisent pas L à s'exécuter et libèrent le verrou H ne sera jamais exécuté. Ce qui peut être dangereux dans des applications critiques
Et pour les solutions référez-vous aux réponses ci-dessus :)
L'inversion de priorité est lorsqu'un processus de priorité inférieure obtient une ressource dont un processus de priorité supérieure a besoin, empêchant le processus de priorité supérieure de continuer jusqu'à ce que la ressource soit libérée.
par exemple: FileA doit être accessible par Proc1 et Proc2 . Proc 1 a une priorité supérieure à Proc2, mais Proc2 parvient à ouvrir FileA en premier.
Normalement, Proc1 fonctionnerait 10 fois plus souvent que Proc2, mais ne pourrait rien faire car Proc2 contient le fichier.
Donc ce qui finit par arriver, c'est que Proc1 bloque jusqu'à ce que Proc2 finisse avec FileA, essentiellement leurs priorités sont «inversées» tandis que Proc2 détient le handle de FileA.
En ce qui concerne «la résolution d'un problème», l'inversion des priorités est un problème en soi si elle continue. Le pire des cas (la plupart des systèmes d’exploitation ne le laisseront pas cependant) est si Proc2 n’était pas autorisé à s'exécuter jusqu’à ce que Proc1 l’ait été. Cela ferait verrouiller le système, car Proc1 continuerait à recevoir du temps processeur, et Proc2 n'obtiendrait jamais de temps processeur, le fichier ne serait donc jamais publié.
L’inversion des priorités se produit de la manière suivante: Étant donné les processus H, M et L où les noms correspondent aux priorités haute, moyenne et faible, Seuls H et L partagent une ressource commune.
Disons que L acquiert d'abord la ressource et commence à s'exécuter. Etant donné que H a également besoin de cette ressource, il entre dans la file d'attente . M ne partage pas la ressource et peut commencer à s'exécuter. Lorsque L est interrompu par quelque moyen que ce soit, M prend l'état en cours d'exécution car il a une priorité plus élevée et il s'exécute au moment où l'interruption se produit . Bien que H ait une priorité plus élevée que M, il est impossible acquérir la ressource, ce qui implique une priorité plus basse que même M . Après que M ait terminé, L reprendra le contrôle de la CPU, ce qui fera attendre H tout le temps.
Considérons un système avec deux processus, H avec une priorité élevée et L avec une priorité basse. Les règles de planification sont telles que H est exécuté chaque fois qu'il est prêt à fonctionner en raison de sa haute priorité. À un certain moment, avec L dans sa région critique, H devient prêt à être exécuté (par exemple, une opération d'E/S se termine). H commence maintenant à attendre, mais comme L n'est jamais planifié tant que H est en cours d'exécution, L n'a jamais l'occasion de quitter la section critique. Donc H boucle pour toujours.
Cette situation s'appelle Priority Inversion. Parce qu'un processus de priorité plus élevée attend un processus de priorité plus faible.
Un problème de planification survient lorsqu'un processus de priorité supérieure doit lire ou modifier les données du noyau auxquelles un processus de priorité inférieure accède actuellement, ou une chaîne de processus de priorité inférieure. Comme les données du noyau sont généralement protégées par un verrou, le processus de priorité supérieure doit attendre qu'un processus de priorité inférieure se termine avec la ressource. La situation devient plus compliquée si le processus moins prioritaire est préempté en faveur d'un autre processus plus prioritaire. Par exemple, supposons que nous ayons trois processus - L, M et H - dont les priorités suivent l’ordre L <M <H. Supposons que le processus H nécessite la ressource R, actuellement utilisée par le processus L.Ordinairement, le processus H attendez que L finisse en utilisant la ressource R. Cependant, supposons maintenant que le processus M devienne exécutable, préemptant ainsi le processus L. Indirectement, un processus de priorité inférieure - processus M - a une incidence sur le temps requis par le processus H pour que L abandonne la ressource R Ce problème est connu sous le nom d'inversion de priorité. Il ne se produit que dans des systèmes comportant plus de deux priorités. Une solution consiste donc à n'avoir que deux priorités. Ce problème est cependant insuffisant pour la plupart des systèmes d'exploitation à usage général. Généralement, ces systèmes résolvent le problème en mettant en œuvre un protocole d'héritage des priorités. Selon ce protocole, tous les processus qui accèdent aux ressources requises par un processus de priorité supérieure héritent de la priorité la plus élevée jusqu'à ce qu'ils soient terminés avec les ressources en question. Une fois qu'ils sont terminés, leurs priorités reviennent à leurs valeurs d'origine. Dans l'exemple ci-dessus, un protocole d'héritage de priorité permettrait au processus L d'hériter temporairement de la priorité du processus H, empêchant ainsi le processus M de préempter son exécution. Une fois que le processus L avait terminé en utilisant la ressource R, il abandonnait sa priorité héritée et assumait sa priorité d'origine.Parce que la ressource R était désormais disponible, le processus H - et non M - serait exécuté ensuite . Référence: ABRAHAM SILBERSCHATZ
L'inversion de priorité peut être évitée si le thread bloqué de haute priorité bloqué transfère sa priorité haute au thread de priorité basse qui conserve la ressource.