Pourquoi un état dangereux ne provoque pas toujours un blocage?

Je lisais les systèmes d'exploitation par Galvin et suis tombé sur la ligne ci-dessous,

Cependant, tous les états dangereux ne sont pas bloqués. Un état dangereux peut entraîner un blocage

Quelqu'un peut-il expliquer comment l' impasse! = État dangereux ? J'ai aussi attrapé la même ligne ici

S'il n'y a pas de séquence sûre, le système est dans un état dangereux, ce qui PEUT conduire à un blocage. (Tous les états sûrs sont sans impasse, mais tous les états dangereux ne mènent pas à des blocages.)

Deadlock moyens quelque chose de spécifique: il y a deux (ou plus) les processus qui sont actuellement bloqués en attente pour l'autre.

Dans un état dangereux , vous pouvez également être dans une situation où il pourrait y avoir un blocage dans le futur, mais cela ne s'est pas encore produit parce qu'un ou les deux processus n'ont pas réellement commencé à attendre.

Prenons l'exemple suivant:

Process A                  Process B
lock X                     lock Y           # state is "unsafe"
                           unlock Y
lock Y                                      # state is back to "safe" (no deadlock this time.  We got lucky.)

Il y a un exemple plus intéressant dans la section 7.5.1 du lien que vous avez donné :

Considérons un système avec 12 lecteurs de bande avec:

Process       Max Need       Current
P0:             10              5
P2:              9              3

Il s'agit d'un état dangereux. Mais nous ne sommes pas dans une impasse. Il y a seulement 4 disques gratuits, donc, par exemple, si P0 ne demande un supplément de 5 et P2 ne demande un 1 supplémentaire, nous l' impasse, mais il n'a pas encore eu lieu. Et P0 pourrait ne plus demander de disques, mais pourrait libérer les disques qu'il possède déjà. Il Max needs'agit de toutes les exécutions possibles du programme, et ce n'est peut-être pas l'une des exécutions où nous avons besoin des 10 disques dans P0.

Juste pour expliquer ce que Wandering Logic disait.

Disons que j'ai deux threads qui ont tous les deux besoin d'accéder à X et Y, et que je n'ai pas de synchronisation ni de mécanisme pour corriger l'impasse. Ceci n'est pas sûr, car l'un pourrait verrouiller X et l'autre Y et aucun des deux ne pourrait continuer. Mais ce n'est pas garanti.

Thread 1                    Thread 2
Lock X                      
Lock Y
OS Interrupts Thread 1 and passes control to Thread 2
                            Unable to lock needed resources.
OS Interrupts Thread 2 and passes control to Thread 1
Unlock X                    
Unlock Y                    
                            Lock Y
                            Lock X
 ....

Ce scénario n'a pas abouti à une impasse, mais il aurait pu. En raison du fonctionnement du filetage, il n'y a pas de flux défini. Le système d'exploitation contrôle le filetage et il peut donc se produire quelque chose comme ceci:

Thread 1                    Thread 2
Lock X        
OS Interrupts Thread 1 and passes control to Thread 2
                            Lock Y              
DEADLOCK Thread 1 needs Y, Thread 2 needs X. Neither knows to back down and simply waits.

L'état sûr est sans blocage, c'est sûr, mais si vous ne pouvez pas remplir toutes les conditions pour éviter le blocage, cela peut se produire. Par exemple, si deux threads peuvent tomber dans une impasse lorsqu'ils démarrent le thread A, puis le thread B, mais lorsqu'ils démarrent l'opposé (B, A), ils fonctionneront correctement - je suppose que B est plus agréable;) L'état du système n'est pas sûr, mais avec une séquence de départ heureuse, cela fonctionnera. Pas d'impasse, mais c'est possible. Si vous les synchronisez également à la main - commencez dans le bon ordre - il est dangereux - pour une raison quelconque, ils ne peuvent pas être déclenchés comme vous le souhaitez - le système est toujours dangereux (en raison d'un blocage possible), mais il y a une faible probabilité à cela. En cas de certains événements externes comme le gel des threads ou des interruptions après la poursuite, il échouera.

Vous devez vous rendre compte - un état sûr est une condition suffisante pour éviter l'impasse, mais dangereux n'est qu'une condition nessaire. Il est difficile d'écrire du code de la tête en ce moment, mais je peux en chercher. J'ai rencontré du code dans Ada qui, plus de 99/100 fois, fonctionnait parfaitement pendant plusieurs semaines (puis s'est arrêté en raison d'un redémarrage du serveur et non d'un blocage), mais de temps en temps il se bloquait après plusieurs secondes dans un état de blocage.

Permettez-moi d'ajouter un exemple simple en comparant à la division: si votre fonction divise c / d et renvoie un résultat, sans vérifier si d est égal à 0, il peut y avoir une division par erreur zéro, donc le code n'est pas sûr (même dénomination), mais jusqu'à ce que vous faites une telle division, tout va bien, mais après que le code d'analyse théorique ne soit pas sûr et puisse tomber dans un comportement indéfini non géré correctement.

Voici ma compréhension à ce sujet (veuillez me corriger si je me trompe): (A) Si blocage, signifie qu'il existe un cycle (l'une des conditions nécessaires) (B) Un cycle est une condition obligatoire pour le blocage (à la fois simple et multiple ressources d'instance)

Nous pouvons donc prouver maintenant qu'il existe un cycle qui ne peut pas conduire à un blocage. Vous pouvez voir ici qu'un cycle existe signifiant qu'un état dangereux est trouvé, mais cela ne peut pas conduire à un blocage car la ressource R2 qui participe au cycle peut rompre le cycle dès que le processus P3 se termine et le libère (rappelez-vous que P3 n'a aucune dépendance ou n'attend aucune autre ressource).

Un état dangereux insignifiant: le thread 1 prend le verrou A, puis le verrou B, puis déverrouille les deux. Le thread 2 prend le verrou B, puis le verrou A, puis déverrouille les deux.

Cela conduira uniquement à un blocage si le thread 2 prend le verrou B juste entre le thread 1 prenant le verrou A et essayant de prendre le verrou B, ou le thread 1 prenant le verrou A juste entre le thread 2 prenant le verrou B et essayant de prendre le verrou A.

Si Thread 1 et Thread 2 le font au hasard une fois par heure, et il y a un intervalle de temps de microsecondes qui conduirait en fait à un blocage. cela peut durer très longtemps entre les mains des clients jusqu'à ce que vous obteniez finalement un blocage par hasard.

Traversez une rue les yeux fermés. C'est dangereux. Mais on ne se fait pas toujours tuer.