Prévenir les impasses : il suffit de détruire l'une des quatre conditions d'impasse.
0. Détruire la condition d'exclusion mutuelle : étant donné que la condition d'exclusion mutuelle est nécessaire pour les appareils non partagés, non seulement elle ne peut pas être modifiée, mais doit également être garantie. Nous considérons donc principalement les trois conditions restantes.
1. Romprecondition « demander et conserver »
Demander et conserver signifie que le système a demandé une ressource et qu'il occupe maintenant la ressource, mais il demande également de nouvelles ressources sans la libérer.
Solution:
1) Appliquez toutes les ressources avant le démarrage de tous les processus, afin qu'elles ne s'appliquent plus pendant toute l'exécution. Cette solution est simple, mais la nécessité d'allouer une grande quantité de ressources à la fois entraînera un gaspillage d'une grande quantité de ressources et entraînera la famine de certains processus en raison de l'incapacité de certains processus à obtenir les ressources correspondantes .
2) Permettre à un processus de démarrer uniquement en obtenant initialement les ressources dont il a besoin , puis libérer progressivement les ressources qui lui ont été allouées et qui ont été utilisées pendant le processus en cours . Ce sera plus raisonnable que la première solution.
2. Détruirecondition de « non-préemption »
Lorsque la demande de nouvelles ressources d'un processus ne peut pas être satisfaite, il doit immédiatement libérer toutes les ressources qu'il détient et les réappliquer lorsque cela est nécessaire ultérieurement. En d'autres termes, les ressources déjà occupées par le processus seront libérées brièvement.Même si certaines ressources n'ont pas été utilisées, elles doivent être activement libérées, détruisant ainsi la condition de non-préemption .
Inconvénients de cette solution :
1. C’est plus compliqué à mettre en œuvre.
2. La libération des ressources acquises peut entraîner l'échec de l'étape précédente des travaux. Par conséquent, cette méthode ne convient généralement qu’aux ressources dont l’état est facile à sauvegarder et à restaurer, comme le processeur.
3. La demande et la libération répétées de ressources augmenteront la surcharge du système et réduiront le débit du système.
4. Tant qu'une certaine ressource est temporairement indisponible, toutes les ressources précédemment obtenues doivent être abandonnées et réutilisées à l'avenir. Si cela se produit tout le temps, cela entraînera une famine du processus.
3. Pour détruireétat d'attente de la boucle
, vous pouvez utiliser la méthode d'allocation séquentielle des ressources . Tout d'abord, numérotez les ressources du système et stipulez que chaque processus doit demander des ressources par ordre croissant de nombres et que toutes les ressources du même type (c'est-à-dire les ressources avec le même numéro) peuvent être demandées en même temps.
Un processus est éligible pour postuler à une ressource avec un nombre plus grand uniquement s'il occupe déjà une ressource avec un nombre plus petit. Selon cette règle, un processus qui détient déjà une ressource de grand nombre ne peut pas revenir demander une ressource de petit nombre à l'envers, il n'y aura donc pas de phénomène d'attente de boucle.
Inconvénients de cette stratégie :
- Il n'est pas pratique d'ajouter de nouveaux équipements car tous les numéros peuvent devoir être réattribués ;
- L'ordre dans lequel le processus utilise réellement les ressources peut ne pas être cohérent avec l'ordre croissant des nombres, ce qui entraînera un gaspillage des ressources ;
- Les ressources doivent être demandées dans un ordre spécifié, ce qui rend la programmation utilisateur difficile.
Évitez les impasses :
Éviter les blocages est également une stratégie préventive, mais cela ne signifie pas prendre des mesures restrictives à l'avance pour détruire les conditions nécessaires aux blocages. Au lieu de cela, cela empêche le système d'entrer dans un état dangereux lors de l'allocation dynamique des ressources pour éviter les blocages.
1. Séquence de sécurité : La séquence dite de sécurité signifie que si le système alloue les ressources selon cette séquence, chaque processus peut être terminé avec succès. Tant qu'une séquence sûre peut être trouvée, le système est dans un état sûr. Bien entendu, il peut y avoir plusieurs séquences de sécurité.
Si après l'allocation des ressources, aucune séquence sûre ne peut être trouvée dans le système , le système entrera dans un état dangereux . Cela signifie que tous les processus ultérieurs risquent de ne pas être exécutés correctement. Bien sûr, si un processus renvoie des ressources à l'avance, le système peut revenir à un état sûr, mais nous devons toujours considérer le pire des cas avant d'allouer des ressources.
Si le système est dans un état sûr, un interblocage ne se produira certainement pas. Si le système devient dangereux, un interblocage peut se produire (être dans un état dangereux ne signifie pas nécessairement qu'un interblocage s'est produit, mais lorsqu'un interblocage se produit, il doit être dans (un état dangereux).
Par conséquent, avant l'allocation des ressources, vous pouvez pré-juger si cette allocation fera entrer le système dans un état dangereux, afin de décider d'accorder ou non la demande d'allocation de ressources. C'est aussi l'idée centrale de « l'algorithme du banquier » .
Pour plus de détails sur l'utilisation de l'algorithme du banquier pour éviter les blocages, voir : Système d'exploitation - Algorithme du banquier pour éviter les blocages_Utilisation de l'algorithme du banquier pour éviter les blocages_Un blog pour écrire des poèmes avec programmation-Blog CSDN
Un exemple de l'algorithme du banquier :
Supposons qu'il existe 5 processus {P0, P1, P2, P3, P4} et trois types de ressources {A, B, C} dans le système. Les nombres de ressources différentes sont respectivement 10, 5 et 7. L'allocation des ressources à l'instant T0 comme le montre l'image :
| Max. | Allocation | Besoin | Disponible | |
| ABC | ABC | ABC | ABC | |
| P0 | 7 5 3 | 0 1 0 | 7 4 3 | 3 3 2（2,3,0） |
| P1 | 3 2 2 | 2 0 0（3,0,2） | 1 2 2（0,2,0） | |
| P2 | 9 0 2 | 3 0 2 | 6 0 0 | |
| P3 | 2 2 2 | 2 1 1 | 0 1 1 | |
| P4 | 4 3 3 | 0 0 2 | 4 3 1 |
Sécurité à l'instant T0 : En utilisant l'algorithme de sécurité pour analyser l'allocation des ressources à l'instant T0, on peut voir qu'il existe une séquence de sécurité {P1, P3, P4, P2, P0} à l'instant T0, donc le système est sécurisé.
| Travail | Besoin | Allocation | Travail+Allocation | Finition | |
| ABC | ABC | ABC | ABC | ||
| P1 | 3 3 2 | 1 2 2 | 2 0 0 | 5 3 2 | vrai |
| P3 | 5 3 2 | 0 1 1 | 2 1 1 | 7 4 3 | vrai |
| P4 | 7 4 3 | 4 3 1 | 0 0 2 | 7 4 5 | vrai |
| P2 | 7 4 5 | 6 0 0 | 3 0 2 | 10 4 7 | vrai |
| P0 | 10 4 7 | 7 4 3 | 0 1 0 | 10 5 7 | vrai |
Les trois situations suivantes sont utilisées pour montrer les trois situations de l'algorithme du banquier. Les trois situations ici constituent un scénario d'exécution continue . Par conséquent, les données de la situation suivante sont héritées de la situation ci - dessus . Vous avez peut-être des doutes ici, donnez-moi un indice.
Le premier cas : P1 demande des ressources : P1 envoie le vecteur de requête Request(1,0,2), et le système vérifie selon l'algorithme du banquier.
Demande (1,0,2)<=Besoin(1,2,2) Demande(1,0,2)<=Disponible(3,3,2)
Le système alloue des ressources à P1 et le contenu entre parenthèses dans le premier tableau Disponible, Allocation et Besoin correspond aux résultats après allocation.
En utilisant l'algorithme de sécurité pour la vérification, une séquence de sécurité {P1, P3, P4, P0, P2} peut également être obtenue, elle est donc attribuée
| Travail | Besoin | Allocation | Travail+Allocation | Finition | |
| ABC | ABC | ABC | ABC | ||
| P1 | 2 3 0 | 0 2 0 | 3 0 2 | 5 3 2 | vrai |
| P3 | 5 3 2 | 0 1 1 | 2 1 1 | 7 4 3 | vrai |
| P4 | 7 4 3 | 4 3 1 | 0 0 2 | 7 4 5 | vrai |
| P0 | 7 4 5 | 7 4 3 | 0 1 0 | 7 5 5 | vrai |
| P2 | 7 5 5 | 6 0 0 | 3 0 2 | 10 5 7 | vrai |
Le deuxième cas : P4 demande des ressources : P4 émet le vecteur de requête Request(3,3,0), et le système vérifie selon l'algorithme du banquier
Demande (3,3,0) <= Besoin (4,3,1)
Request(3,3,0)>Available(2,3,0) laisse P4 attendre
La troisième situation : P0 demande des ressources : P0 envoie le vecteur de requête Request(0,2,0), et le système vérifie selon l'algorithme du banquier :
Demande (0,2,0) <= Besoin (7,4,3)
Demande(0,2,0)<=Disponible(2,3,0)
Le système suppose d'abord que les ressources sont allouées à P0 puis effectue des modifications.
| Max. | Allocation | Besoin | Disponible | |
| ABC | ABC | ABC | ABC | |
| P0 | 7 5 3 | 0 3 0 | 7 2 3 | 2 1 0 |
| P1 | 3 2 2 | 3 0 2 | 0 2 0 | |
| P2 | 9 0 2 | 3 0 2 | 6 0 0 | |
| P3 | 2 2 2 | 2 1 1 | 0 1 1 | |
| P4 | 4 3 3 | 0 0 2 | 4 3 1 |
Un contrôle de sécurité a été effectué et il a été constaté que les ressources disponibles ne pouvaient plus répondre aux besoins d'aucun processus, le système serait donc dans un état dangereux et les ressources ne seraient pas allouées.