¿Por qué el estado inseguro no siempre causa un punto muerto?

Estaba leyendo Sistemas operativos de Galvin y me encontré con la línea de abajo,

Sin embargo, no todos los estados inseguros están en punto muerto. Un estado inseguro puede llevar a un punto muerto

¿Alguien puede explicar cómo punto muerto! = Estado inseguro ? También tomé la misma línea aquí

Si no existe una secuencia segura, entonces el sistema está en un estado inseguro, lo que PUEDE conducir a un punto muerto. (Todos los estados seguros están libres de puntos muertos, pero no todos los estados inseguros conducen a puntos muertos).

El punto muerto significa algo específico: hay dos (o más) procesos que están actualmente bloqueados esperando el uno al otro.

En un estado inseguro , también puede encontrarse en una situación en la que puede haber un punto muerto en algún momento en el futuro, pero aún no ha sucedido porque uno o ambos procesos no han comenzado a esperar.

Considere el siguiente ejemplo:

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.)

Hay un ejemplo más interesante en la Sección 7.5.1 del enlace que proporcionó :

Considere un sistema con 12 unidades de cinta con:

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

Este es un estado inseguro. Pero no estamos en un punto muerto. Hay sólo 4 unidades libres, por lo que, por ejemplo, si P0 hace solicitud de un adicional de 5, y P2 hace solicitud de un adicional de 1, vamos a un punto muerto, pero no ha sucedido todavía. Y P0 podría no solicitar más unidades, sino que podría liberar las unidades que ya tiene. El Max needestá sobre todas las ejecuciones posibles del programa, y ​​esta podría no ser una de las ejecuciones donde necesitamos las 10 unidades en P0.

Solo para exponer lo que decía Wandering Logic.

Digamos que tengo dos subprocesos que necesitan acceso a X e Y, y no tienen sincronización ni mecanismo para corregir el punto muerto. Esto no es seguro, ya que uno podría bloquear X y el otro Y y luego ninguno podría proceder. Pero no está garantizado.

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
 ....

Este escenario no terminó en un punto muerto, pero podría haberlo hecho. Debido a la forma en que funciona el enhebrado, no hay un flujo establecido. El sistema operativo controla el subproceso y, por lo tanto, podría ocurrir algo como lo siguiente:

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.

El estado seguro es un punto muerto seguro, pero si no puede cumplir con todos los requisitos para evitar el punto muerto, puede ocurrir. Por ejemplo, si dos subprocesos pueden caer en un punto muerto cuando comienzan el subproceso A, luego el subproceso B, pero cuando comienzan el opuesto (B, A) funcionarán bien, déjenme suponer que B es más agradable;) El estado del sistema no es seguro, pero con una secuencia de inicio afortunada funcionará. No hay punto muerto, pero es posible. Si también los sincroniza a mano, comience en buen orden, es peligroso, por alguna razón, es posible que no se activen como desee, el sistema aún no es seguro (debido a un posible punto muerto), pero hay poca probabilidad de que eso suceda. En el caso de algunos eventos externos como congelar hilos o interrupciones después de continuar, fallará.

Tienes que darte cuenta: el estado seguro es condición suficiente para evitar un punto muerto, pero inseguro es solo una condición necesaria. Es difícil escribir código de la cabeza en este momento, pero puedo buscar algunos. Encontré código en Ada que más de 99/100 veces funcionó perfectamente durante varias semanas (y luego se detuvo debido al reinicio del servidor, no a un punto muerto), pero de vez en cuando se bloqueaba después de varios segundos en estado de punto muerto.

Permítanme agregar un ejemplo sencillo comparándolo con la división: si su función divide c / d y devuelve el resultado, sin verificar si d es igual a 0, puede haber una división por cero error, por lo que el código no es seguro (se pretende el mismo nombre), pero hasta Si realiza dicha división, todo está bien, pero después del análisis teórico, el código no es seguro y puede caer en un comportamiento indefinido que no se maneja adecuadamente.

Aquí está mi entendimiento sobre esto (corríjame si estoy equivocado): (A) Si se produce un punto muerto, significa que existe un ciclo (una de las condiciones necesarias) (B) Un ciclo es una condición obligatoria para el punto muerto (tanto para uno como para múltiples recursos de instancia)

Por lo tanto, podemos demostrar ahora que existe un ciclo que puede no conducir a un punto muerto. Puede ver aquí que existe un ciclo, lo que significa que se encuentra un estado inseguro, pero esto podría no conducir a un punto muerto dado que el recurso R2 que participa en el ciclo puede romper el cicle tan pronto como el proceso P3 finalice y lo libere (recuerde que P3 no tiene ninguna dependencia ni espera ningún otro recurso).

Un estado inseguro trivial: el subproceso 1 toma el bloqueo A, luego bloquea B y luego desbloquea ambos. El subproceso 2 toma el bloqueo B, luego el bloqueo A, luego desbloquea ambos.

Esto solo conducirá a un punto muerto si el Hilo 2 toma el bloqueo B justo entre el Hilo 1 que toma el bloqueo A y trata de tomar el bloqueo B, o el Hilo 1 toma el bloqueo A justo entre el Hilo 2 que toma el bloqueo B e intenta tomar el bloqueo A.

Si el subproceso 1 y el subproceso 2 hacen esto aleatoriamente una vez por hora, y hay un lapso de tiempo de microsegundos que en realidad conduciría a un punto muerto. Esto puede durar mucho tiempo en la mano de los clientes hasta que finalmente llegue a un punto muerto por casualidad.

Cruza una calle con los ojos cerrados. No es seguro Pero no siempre te matan.