Por que o estado inseguro nem sempre causa um impasse?

Eu estava lendo sistemas operacionais da Galvin e me deparei com a linha abaixo,

Nem todos os estados inseguros são um impasse, no entanto. Um estado inseguro pode levar a um impasse

Alguém pode explicar como o impasse! = Estado inseguro ? Eu também peguei a mesma linha aqui

Se uma sequência segura não existir, o sistema estará em um estado inseguro, o que PODE levar a um impasse. (Todos os estados seguros são livres de impasse, mas nem todos os estados inseguros levam a impasses.)

Impasse significa algo específico: existem dois (ou mais) processos atualmente bloqueados, esperando um pelo outro.

Em um estado inseguro, você também pode estar em uma situação em que pode haver um impasse em algum momento no futuro, mas isso ainda não aconteceu porque um ou ambos os processos não começaram a esperar.

Considere o seguinte exemplo:

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

Há um exemplo mais interessante na Seção 7.5.1 do link que você forneceu :

Considere um sistema com 12 unidades de fita com:

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

Este é um estado inseguro. Mas não estamos em um impasse. Há apenas 4 unidades livres, assim, por exemplo, se P0 faz pedido um adicional de 5, e P2 faz pedido um adicional de 1, vamos impasse, mas isso ainda não aconteceu. E P0 pode não solicitar mais unidades, mas pode liberar as unidades que já possui. Ele Max needterminou todas as execuções possíveis do programa, e essa pode não ser uma das execuções em que precisamos das 10 unidades em P0.

Apenas para explicar o que a Wandering Logic estava dizendo.

Digamos que eu tenha dois threads que precisam acessar X e Y e não tenham sincronização nem mecanismo para corrigir o impasse. Isso é inseguro, pois um pode bloquear o X e o outro Y e, em seguida, nenhum deles pode prosseguir. Mas não é garantido.

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

Esse cenário não acabou em um impasse, mas poderia ter acontecido. Devido à maneira como a segmentação funciona, não há um fluxo definido. O sistema operacional controla o encadeamento e, portanto, pode ocorrer algo como o seguinte:

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.

O estado seguro é livre de conflito, com certeza, mas se você não puder atender a todos os requisitos para impedir o conflito, isso poderá ocorrer. Por exemplo, se dois encadeamentos entrarem em conflito quando iniciarem o encadeamento A, depois o encadernar B, mas quando iniciarem o oposto (B, A) funcionarão bem - deixe-me supor que B seja melhor;) O estado do sistema não é seguro, mas com a sequência inicial afortunada, estará funcionando. Sem impasse, mas é possível. Se você também sincronizá-los manualmente - inicie em boa ordem - é perigoso - por algum motivo, eles podem não ser acionados como você gosta - o sistema ainda não é seguro (por causa de um possível impasse), mas há uma baixa probabilidade disso. No caso de alguns eventos externos, como congelar threads ou interromper depois de continuar, ele falhará.

Você deve perceber - o estado seguro é condição suficiente para evitar um conflito, mas inseguro é apenas uma condição necessária. É difícil escrever código fora de controle agora, mas posso procurar por alguns. Eu encontrei um código no Ada que, mais de 99/100 vezes, funcionava perfeitamente por várias semanas (e depois parava devido à reinicialização do servidor e não a um impasse), mas de vez em quando estava travando após vários segundos no estado de impasse.

Deixe-me adicionar um exemplo fácil comparando com a divisão: se sua função divide c / de retorna resultado, sem verificar se d é igual a 0, pode haver erro de divisão por zero, portanto, o código é inseguro (mesma nomeação pretendida), mas até você faz essa divisão, está tudo bem, mas depois que o código de análise teórica é inseguro e pode cair em comportamento indefinido, não é tratado adequadamente.

Aqui está o meu entendimento sobre isso (por favor, corrija-me se estiver errado): (A) Em caso de deadlock, significa que existe um ciclo (uma das condições necessárias) (B) Um ciclo é condição obrigatória para deadlock (para single e multi) recursos da instância)

Portanto, podemos provar agora que existe um ciclo que pode não levar a um impasse. Você pode ver aqui um ciclo que significa que um estado inseguro é encontrado, mas isso pode não levar a um impasse, pois o recurso R2 que participa do ciclo pode quebrar o faça o ciclo assim que o processo P3 for concluído e o libera (lembre-se de que o P3 não possui nenhuma dependência ou aguarda qualquer outro recurso).

Um estado inseguro trivial: o segmento 1 pega o bloqueio A, depois o bloqueio B e desbloqueia os dois. A linha 2 pega a trava B, trava A e desbloqueia ambas.

Isso só levará a um impasse se o Thread 2 pegar a trava B apenas entre o Thread 1 pegar a trava A e tentar pegar a trava B, ou o Thread 1 pegar a trava A logo entre o Thread 2 pegar a trava B e tentar pegar a trava A.

Se o Thread 1 e o Thread 2 fizerem isso aleatoriamente uma vez por hora, e haverá um intervalo de microssegundos que realmente levaria a um impasse. isso pode demorar muito tempo na mão dos clientes até que, eventualmente, você tenha um impasse por acaso.

Atravesse uma rua com os olhos fechados. Não é seguro. Mas você nem sempre é morto.