1
Deadlocks
Capítulo 3
3.1. Recursos 3.2. Introdução a deadlocks 3.3. O algoritmo a avestruz3.4. Detecção e recuperação de deadlock 3.5. Evitando Deadlock 3.6. Prevenindo Deadlock 3.7. Outros assuntos 2
Recursos
z Reusáveis– Usado e não gasto por
um processo zArquivo em disco zUnidade de Fita zProcessadores zCanais de E/S zMemórias zDispositivos zSemáforos zBancos de Dados z “Consumíveis” – Criado e consumido (destruído) zInterrupções zSinais zMensagens zInformação em buffers de E/S
3
Recursos
z
Os processos precisam ter acesso aos recursos
de forma razoavelmente ordenada
z
Suponha que um processo tenha o recurso A e
solicite o recursos B
– Ao mesmo tempo, outro processo possui B e solicita A – Ambos são bloqueados e permanecem bloqueados
Recursos (1)
z
Deadlocks ocorem quando
…– Processos obtém aceeso exclusivo a dispositivos – Estes dispositivos são chamados recursos em geral z
Recursos “Preemptáveis”
– Podem ser retirados de um processo sem efeito danoso z
Recursos “Não Preemptáveis”
5
Recursos(2)
z
Sequencia de eventos requeridos para
usar um recursos
1. Solicitar o recurso 2. Usar o recurso 3. Liberar o recurso
z
Deve esperar se solicitação é negada
– Processo solicitante pode ser bloqueado – Pode falhar com código de erro
6
Introdução aos Deadlocks
z Definição Formal:
Um conjunto de processos está em deadlocked se cada processo no conjunto espera por um evento que apenas um outro processo do conjunto pode causar
z Normalmente o evento é a liberação de um recurso
z Nenhum dos processo pode …
– executar – Liberar recursos – Ser acordado
7
Quatro condições para Deadlock
1. Exclusão mútua 2. Toma e espera
3. Ausência de preempção 4. Espera Circular
Modelagem de Deadlocks
z Modelado por grafos diretos
– recurso R está atribuido ao processo A
– processo B está solcitando/esperando recurso S
9
Modelagem Deadlock
Estratégias para lidar com deadlock
1. Ignore o problema! 2. Detecção e recuperação 3. Evite dinamicamente
• Alocação cuidadosa de recursos 4. Prevenção
• Negação de uma das quatro condições
10
Como deadlocks ocorrem
A B C
11
Como deadlock pode ser evitado
(o) (p) (q)
Modelagem de Deadlock
O algoritmo da avestruz
z
Finja que não há qualquer problema
z
Razoável se
– deadlocks ocorre muito raramente – Custo de prevenção é alto
z
UNIX e Windows adotam este enfoque
z
É um custo benefício (trade off) entre
– conveniencia – corretude
13
Detecção cm um recurso de cada
tipo (1)
z
Observe o propriedade do recurso e solicitações
z
Um ciclo pode ser observado no grafo, denotando
deadlock
14
Estruturas de dados requeridas pelo algoritmo de detecção de deadlock
Detecção cm um recurso
de cada tipo (1)
15
Um exemplo para o algoritmo de detecção de
deadlock
Detecção com um
recurso de cada tipo (1)
Recuperação de Deadlock (1)
z Recuperação por preempção
– Tome um recurso de algum outro processo – Depende da natureza do recurso
z Recuperação por retrocesso
– Realize pontos de verificação periodicamente – Use este estado salvo
17
z
Recuperação matando processos
– Forma mais simples de resolver um deadlock
– Mate um dos processos no ciclo de deadlock deadlock – O outro processo obtem os recursos
– Escolhar processos que possam ser re-executados do
início
Recuperação de Deadlock
18
Evitando Deadlock
trajetórias de recursos
19
Exemplo de trajetória
Deadlock pode ocorrer
Exemplo de trajetória
21
Estados seguros e inseguros
Demonstração que o estado em (a) é seguro
(a) (b) (c) (d) (e)
22
Estados seguros e inseguros(2)
Demonstração que o estado em b é inseguro
23
Algoritmo do banqueiro
z Um estado é segura sse existe uma seqüência {P1..Pn} onde a cada Pi é alocado todos os seus recursos para execução até o término
– Ou seja, podemos sempre rodar todos os processo até a término a partir de um estado seguro
z O algoritmo de segurança é a parte que determina se um estado é seguro
z Inicialização:
– Todos os processos são considerados “não terminados” – O vetor de trabalho é inicializado com a quantidade de
recursos disponíveis : W(i) = V(i) para todo i;
z
REPITA: Ache um processo não terminado j
tal que N(j,i) <= W(i) para todo i.
– Se não existe tal j, vá para FIM
– SENÃO: “termine” este processo e recupere os
seus recursos: W(i) = W(i) + A(j,i) para todo i. Então vá para REPITA
z
FIM: se todos os processo “terminaram”
estão este estado é seguro. Senão, é
inseguro.
25
z Seja Q(j,i) a quantidade de recurso do tipo i requisitada pelo processo j.
z Para determinar se uma solicitação deve ser atendida usamos o algoritmo do banqueiro:
– Se Q(j,i) <= N(j,i) pata todo i então continue. Senão
provoque condição de erro (solicitações excedidas).
– Se Q(j,i) <= V(i) para todo i então continue. Senão espere
(recurso não está disponível ainda)
– “Finja” que a solicitação foi atendida e determine o novo
estado recurso-alocação:
26
z V(i) = V(i) - Q(j,i) para todo i
z A(j,i) = A(j,i) + Q(j,i) para todo i
z N(j,i) = N(j,i) - Q(j,i) para todo i
– Se o estado resultando for seguro então aloque o
recurso para o processo j. Caso contrário, o processo j deve esperar pela solicitação Q(j,i) e restaurar o estado antigo.
27
z
Temos 3 tipos de recursos com quantidades:
– R(1) = 9, R(2) = 3, R(3) = 6
z
E temos 4 processos com estado inicial:
z
Temos 3 tipos de recursos com quantidades:
– R(1) = 9, R(2) = 3, R(3) = 6
z
E temos 4 processos com estado inicial:
Claimed Allocated Available 3 2 2 6 1 3 3 1 4 4 2 2 1 0 0 5 1 1 2 1 1 0 0 2 1 1 2 P1 P2 P3 P4
z
Suponha que P2 solicite Q = (1,0,1). A
solicitação deve ser atendida?
29
30
z Este estado é seguro com seqüência {P2, P1, P3, P4}. Após P2, temos W = (6,2,3) que habilita o outro processo terminar. Daí: atende a solicitação..
Claimed Allocated Available 3 2 2 6 1 3 3 1 4 4 2 2 1 0 0 6 1 2 2 1 1 0 0 2 0 1 1 P1 P2 P3 P4
z
O estado resultante seria:
31
z
No entanto, se do estado inicial, P1 solicitasse
Q = (1,0,1). O estado resultante seria:
Claimed Allocated Available 3 2 2 6 1 3 3 1 4 4 2 2 2 0 1 5 1 1 2 1 1 0 0 2 0 1 1 P1 P2 P3 P4
z
Que não é seguro pois qualquer processo
para terminar precisaria uma unidade
adicional de R1. Solicitação recusada: P1 é
33
O Algoritmo do Banqueiro para um recurso
z Três estados de alocação de recursos
– seguro – Seguro – inseguro
(a) (b) (c)
34
O Algoritmo do Banqueiro para Múltiplos Recursos
35
Algoritmo do banqueiro : comentários
z Um estado seguro não pode ser “deadlocked”. Mas um inseguro não está necessariamente em
deadlock.
z Ex: P1 do estado anterior (inseguro) poderia liberar temporariamente uma unidade de R1 e R3 (retornando para um estado seguro)
– Alguns processos podem ter que esperar desnecessariamente
– Uso sub ótimo dos recursos
z Todos os algoritmos que evitam deadlock assumem que os processos são independentes: livres de qualquer restrição de sincronização
Prevenção de Deadlock
Atacando a condição de exclusão mútua
z
Alguns dispositivos (como impressoras) podem
ser spooled
– Apenas o daemon usa o recurso impressora – Assim, deadlock para a impressora é eliminado z
Nem todos os dipositivos podem ser spooled
z
Princípio:
– Evite alocar recurso quando não for absolutametne
necessário
37
Atacando a condição de toma e espera
z Obrigue o processo a solicitar recurso antes de iniciar
– Um processo nunca irá esperar por um reccurso
z Problemas
– Pode não saber todos os recursos que necessitará no início – Prende recursos que outros processos poderiam estar utilizando
z Variação:
– Processos devem liberars todos os recursos
– Então solicitar todos os recurso necessários naquele instante
38
Atacar a condição de falta de preempção
z
NÃO É UMA OPÇÃO VIÁVEL
z
Considere um processo que obteve uma
impressora
– Na metade da sua tarefa – Perde a impressora – !!??
39
Atacando a condição de
espera circular (1)
z
Recusos normalmente ordenados
z
Um grafo de recursos
(a) (b)
41
Outros tópicos
Trava (lock) em duas fases
z Fase 1
– O processo tentar travar todos os registros que precisa, um
por vez
– Se algum registro requerido estiver travado, reinicia – (nenhum trabalho real é feito na fase um)
z Se a fase um for bem sucedida, inicia a fase dois
– Realiza atualizações – Libera travas
z Observe a similiraridade com requerer todos os recursos de uma vez
z O algortimo funcioina se …
– programa pode ser parado e reiniciado
42
Deadlocks sem recursos
z
É possível que dois processos entrem em
deadlock
– Cada um espera que o outro realize uma tarefa z
Pode ocorer com semáforos
– Cada processo deve fazer um down() em dois
semáforos (mutex e outro)
43
Fome (Starvation)
z
O algoritmo para alocar um recurso
– Pode ser shortest job first
z
Funciona muito bem para processos curtos tem
um sistema
z
Pode fazere com que processos longos seja
adiados indefinidamente
– Apesar de não estar bloqueado z
