O que você vai aprender
Enunciar as quatro condições necessárias para deadlock.
Comparar prevenção, evitação, detecção e recuperação.
Aplicar o algoritmo do banqueiro para evitar deadlocks.
Modelar impasses com o grafo de alocação de recursos.
O abraço mortal
Dois processos: A segura a impressora e quer o scanner; B segura o scanner e quer a impressora. Nenhum solta o que tem, nenhum consegue o que falta. Ambos esperam para sempre. Esse "abraço mortal" é o deadlock.
Deadlocks travam servidores, sistemas embarcados e bancos de dados. Esta aula — última antes da Prova 1 — ensina a reconhecer, prevenir, evitar, detectar e recuperar de impasses, com o clássico algoritmo do banqueiro.
Roteiro da aula
de Coffman→Grafo de
recursos→Estratégias→Banqueiro
Das condições necessárias à modelagem por grafo, às quatro estratégias de tratamento e ao algoritmo de evitação por estados seguros.
O que é um deadlock
As quatro condições de Coffman
Um deadlock só ocorre se as quatro condições valerem simultaneamente. Negar qualquer uma impede o impasse:
| Condição | Significado |
|---|---|
| Exclusão mútua | Recurso não compartilhável |
| Posse e espera | Segura um recurso e pede outro |
| Não preempção | O recurso não é tomado à força |
| Espera circular | Ciclo de processos esperando uns pelos outros |
Deadlock em código
Esse é o erro de "ordem de aquisição de locks" mencionado na Aula 6. A correção: adquirir sempre na mesma ordem global (A antes de B em ambas).
Passo a passo: o banqueiro avalia um pedido
As quatro estratégias
Evitação. Conceder recursos só em estados seguros (banqueiro).
Detecção e recuperação. Deixar acontecer, detectar e desfazer.
Ignorar (avestruz). Assumir que é raro e não tratar.
Quando usar cada estratégia
| Estratégia | Ideia | Quando |
|---|---|---|
| Prevenção | Negar uma das 4 condições | Sistemas críticos/embarcados |
| Evitação | Conceder só em estados seguros (banqueiro) | Demanda máxima conhecida |
| Detecção/recuperação | Detectar ciclos e desfazer | Bancos de dados |
| Ignorar (avestruz) | Assumir raridade | SOs de propósito geral |
Muitos SOs de uso geral (Linux, Windows) adotam o avestruz para recursos do kernel: tratar deadlocks teria custo alto para algo raro na prática.
O cruzamento travado
Deadlock vs. inanição
| Aspecto | Deadlock | Inanição |
|---|---|---|
| Quem trava | Um conjunto de processos, mutuamente | Um processo específico |
| Causa | Espera circular por recursos | Sempre preterido pela política |
| Progresso do resto | Os envolvidos não progridem | Os outros progridem normalmente |
| Solução | Prevenir/evitar/detectar | Envelhecimento (aging) |
Detecção por grafo de alocação
(processos×recursos)→Procure
ciclos→1 instância:
ciclo = deadlock→N instâncias:
ciclo ⇒ possível
O algoritmo do banqueiro
O algoritmo usa as matrizes Alocação, Máximo e o vetor Disponível; a Necessidade = Máximo − Alocação. A cada pedido, simula a concessão e procura uma sequência em que cada processo, com o Disponível atual, consiga sua Necessidade, termine e libere seus recursos.
Verifique seu entendimento
Quantas das quatro condições de Coffman precisam valer ao mesmo tempo para haver deadlock?
Deadlock embarcado: dois barramentos
Num sistema embarcado, duas tarefas compartilham um barramento SPI e um I²C. A tarefa de logging trava o SPI e pede o I²C; a de sensores trava o I²C e pede o SPI. Sob a temporização errada, cada uma segura o que a outra precisa — deadlock que congela o firmware.
A correção típica é por prevenção: definir uma ordem global de aquisição (sempre SPI antes de I²C) ou usar um único mutex que protege ambos os barramentos. Em embarcados, prevenir é preferível a detectar — não há quem reinicie o dispositivo no campo.
Equívocos sobre deadlocks
• Confundir deadlock com inanição — no deadlock ninguém do grupo avança; na inanição, o resto progride.
• Achar que um ciclo no grafo sempre significa deadlock — só com uma instância por recurso.
• Esquecer que o banqueiro exige conhecer a demanda máxima antecipada.
Revisão para a Prova 1
Revele a análise
Por que negar a "espera circular" previne deadlocks, e como fazê-lo?
Revisão relâmpago
Fechando o ciclo das semanas 1–6
Deadlocks amarram o conteúdo da Prova 1:
- Surgem de locks e sincronização mal coordenados (Aula 6).
- Os recursos disputados são gerenciados pelo SO como gerente de recursos (Aula 1).
- A "não preempção" liga-se ao conceito de preempção do escalonador (Aula 5).
Resumo da aula
Simulador: algoritmo do banqueiro
O simulador do banqueiro permite informar as matrizes de Alocação e Máximo e o vetor Disponível, fazer um pedido de recursos e ver se o sistema permanece em estado seguro ou rejeita o pedido.
Atividade em grupo · Mutirão de revisão (Prova 1)
Em grupos, revisem as semanas 1–6 e pratiquem deadlocks.
Roteiro
- Cada integrante revisa um tema: hardware/SO, processos, threads/concorrência, escalonamento.
- Montem um mapa mental de uma página ligando os temas.
- Resolvam um cenário no simulador do banqueiro: o estado é seguro?
- Criem 2 questões por tema e troquem com outro grupo.
Mini-quiz · Aula 7
20 questões sobre esta aula. Escolha e veja a explicação na hora.
📌 Resumo — leve isto para a prova
- Deadlock exige as 4 condições de Coffman simultaneamente.
- Estratégias: prevenção, evitação, detecção/recuperação e ignorar (avestruz).
- O grafo de alocação modela impasses; ciclo = deadlock só com 1 instância por recurso.
- O banqueiro evita deadlocks concedendo recursos só em estados seguros.
- Estado seguro garante uma ordem de término para todos os processos.