Impasses cap 06 (ii unidade)

1,853 views
1,613 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,853
On SlideShare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
77
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Impasses cap 06 (ii unidade)

  1. 1. Sistemas operacionais modernos Terceira edição ANDREW S. TANENBAUM Capítulo 6 Impasses Adaptado por: Prof. Esp. Rodrigo Ronner rodrigoronner@gmail.com http://rodrigoronner.blogspot.com
  2. 2. Deadlocks • Situação onde dois ou mais processos estão esperando por um evento que só pode ser gerado por algum dos mesmos processos em espera. • Ou seja: • Cada processo de um conjunto em deadlock está esperando por um recurso que foi entregue a outro processo do mesmo conjunto.
  3. 3. Deadlocks • Em alguns casos pode ocorrer a seguinte situação: um processo solicita um determinado recurso e este não está disponível no momento. • Quando isso acontece o processo entra para o estado de espera (bloqueado). • Em algumas situações é possível que estes processos nunca mais mudem de estado, pois os recursos que eles necessitam podem estar sendo mantidos por outros processos em espera. Essa situação é chamada de deadlock ou impasses. “Um conjunto de processos está em estado de deadlock quando todos os processos no conjunto estão esperando por um evento que só pode ser causado por outro processo do conjunto.”
  4. 4. Por exemplo, que dois processos queiram cada um gravar em CD um documento obtido de um scanner: • O processo A solicita permissão para usar o scanner e é autorizado; • O processo B, que é programado diferentemente, solicita primeiro permissão para usar o gravador de CD e também é autorizado; • Então, o Processo A pede para usar o gravador de CD, mas a solicitação lhe é negada até que o processo B o libere; • Infelizmente, em vez de liberar o gravador de CD, o processo B pede para usar o scanner; • Nesse ponto, ambos os Processos ficam bloqueados e assim permanecerão para sempre; • Essa situação é denominada deadlock. Deadlocks
  5. 5. Deadlocks • A ideia de impasse ou deadlock pode ser mais facilmente entendida se fizermos uma analogia com uma escada de um prédio utilizada para casos de incêndio. • Apesar de ter sido construída como uma opção de fuga em caso de incêndio, as pessoas que trabalham no prédio muitas vezes preferem utilizar a escada ao invés dos elevadores. • No entanto, há espaço apenas para uma pessoa em cada degrau. Logo, o tráfego pela escada vai bem até que 2 pessoas se cruzam. • Por outro lado, existe uma plataforma em cada um dos andares que suporta várias pessoas. • Os problemas acontecem no momento em que uma pessoa que está subindo a escada encontra outra que está descendo e ambas se recusam a retroceder até a plataforma. • Esta situação permanecerá gerando um impasse ou deadlock.
  6. 6. Exemplo para Atravessar uma Ponte  Trafégo somente em uma direção  Cada seção da ponte pode ser vista como um recurso  Se ocorre deadlock, pode ser resolvido se um carro voltar (preempção de recursos e rollback)  Diversos carros podem ter que voltar se ocorre deadlock  Pode causar starvation (Quando um processo nunca é executado ("morre de fome"), pois processos de prioridade maior sempre o impedem de ser executado.) Deadlocks
  7. 7. Deadlocks: Recursos É qualquer objeto ao qual deva ser dado acesso exclusivo para cada processo. Recursos podem ser dispositivos de hardware ou arquivo. Para a utilização de um recurso, o processo deve realizar a seguinte sequência: • Requisitar o recurso; • Utilizar o recurso ; • Liberar o recurso. Se um recurso não estiver disponível quando for requisitado, o processo que o requisitou é forçado a aguardar, sendo dois métodos utilizados: 1) O processo é bloqueado e acordado quando o recurso estiver disponível; 2) é enviado um código de erro ao processo indicando que a requisição falhou sendo, então, que o próprio processo deve decidir a ação a tomar (ex: aguardar algum tempo e pedir novamente).
  8. 8. Deadlocks:Recursospreemptíveise não preemptíveis • Preemptível é aquele que pode ser retirado do processo proprietário sem nenhum prejuízo; • Recurso Não Preemptível: é aquele que não pode ser retirado do atual Processo proprietário sem que a computação apresente falha. Se um Processo começou a gravar um CD-ROM, retirar dele repentinamente o gravador de CD e dar a um outro processo resultará em um CD com erros . Gravadores de CD são recursos que não podem ser tomados a qualquer momento, isto é, não são preemptíveis.
  9. 9. Deadlocks: Condições Para ocorrência de Deadlock • Condições necessárias: • Exclusão Mútua; • Posse e Espera; • Não-Preempção; • Espera Circular. Obs: Todas as condições necessárias devem estar presentes para que ocorra. Se faltar uma delas, não ocorrerá deadlock.
  10. 10. • Exclusão mútua: Apenas um processo por vez pode usar o recurso. • Posse e Espera: Processos que, em determinado instante, retêm recurso concedido anteriormente podem requisitar novos recursos. • Não-preempção: Os recursos só podem ser liberados voluntariamente pelo processo que o mantém. • Espera circular: Dado um conjunto de processos {P1, P2, ..., Pn} em espera, P1 está esperando por um recurso mantido por P2; P2 está esperando um recurso mantido por P3 e assim sucessivamente, até que Pn esteja esperando por um recurso alocado por P1. Deadlocks: Condições para ocorrência de Deadlock
  11. 11. Deadlocks: Prevenção de Deadlocks • Exclusão Mútua. • Solução: • Sem exclusão mútua, não existem deadlocks. Por quê? • Quando possível de ser realizada, a eliminação das condições de exclusão mútua resolve os problemas de deadlock. • Problemas: • Risco de Inconsistência no compartilhamento de recursos.
  12. 12. Deadlocks: Prevenção de Deadlocks • Posse e Espera. • Solução: • Alocação de todos os recursos necessários antes do inicio dos processos. • Problemas: • Desperdício dos recursos do sistema. • Impossibilidade de alocação dinâmica de recursos. • Risco de starvation. Muitos processos só sabem quanto recursos vão precisar somente após sua execução.
  13. 13. Deadlocks: Prevenção de Deadlocks • Não-Preempção. • Solução: • Retirada do recurso de um processo quando for requisitado por outro processo. • Problemas: • Pode fazer o processo perder totalmente o processamento realizado. • Risco de starvation.
  14. 14. Deadlocks: Prevenção de Deadlocks • Espera Circular • Solução: • Limitação da posse de um recurso por vez. • Se um processo necessitar de outro recurso, deve liberar qualquer recurso já alocado. • Fornecer uma numeração global de todos os recursos. Processos podem requisitar recursos sempre que necessário, mas todas as solicitações devem ser feitas em ordem numérica. Ex: 1 – Impressora, 2 – Scanner, 3 – Plotter, 4 – Unidade Fita, 5 – Unidade CD-ROM. • Problemas: • Restrição no grau de compartilhamento e processamento dos processos.
  15. 15. Deadlocks: Modelagem de Deadlock • Estratégias para Solução de Deadlocks: • Ignorar; • Detectar e Tratar; • Prevenir.
  16. 16. Em geral, podemos utilizar 3 métodos para tratar o problema de Deadlocks: • 1. podemos usar um protocolo para garantir que o sistema nunca entre em estado de deadlock: PREVENÇÃO (O Sistema operacional deve eliminar uma das 4 condições para que o deadlock ocorra) • 2. podemos permitir que o sistema entre em deadlock e se recupere: DETECÇÃO e RECUPERAÇÃO. • 3. podemos ignorar o problema (Algoritmo do avestruz). Esta opção é utilizada pela maioria dos sistemas operacionais, incluindo o UNIX. • Para garantir que um sistema nunca entre em deadlock é possível usar um esquema de prevenção de Deadlocks ou de impedimento de Deadlocks. Esta prevenção é realizada através de um conjunto de métodos que garantem que pelo menos uma das situações necessárias para que um deadlock aconteça seja falha. Basicamente, isso é feito limitando a forma como as solicitações de recursos acontecem. Deadlocks: Modelagem de Deadlock
  17. 17. Deadlocks: Prevenção de Deadlocks • Todas as soluções anteriores são limitadas. • Alternativa mais utilizada: • Algoritmo do Banqueiro (Dijkstra – 1965) • Exige que todos os processos informem o número máximo de cada tipo de recurso necessário a sua execução. • Assim é possível definir: • O estado de alocação de um recurso. • Número de recursos alocados e disponíveis. • O número máximo de processos que necessitem desses recursos. • Problemas: • Necessidade de definir o número fixo de processos ativos e recursos disponíveis.
  18. 18. Deadlocks: Evitação Dinâmica de Deadlock • Procura-se evitar o deadlock sem impor restrições aos processos, isto é possível desde que alguma informação sobre a utilização de recursos pelo processo seja disponível antecipadamente ao SO. Vamos analisar maneiras de se conseguir isso: • Algoritmo do Banqueiro para um único Recurso: usado para evitar deadlocks consiste em simular as decisões de um banqueiro no empréstimo de certa quantia de dinheiro sujeita a certas condições. • No exemplo próximo slide temos 4 clientes (A B C D) cada um especificou o número máximo de crédito que precisará, mas eles não precisam de todas elas imediatamente, de forma que o banqueiro reservou 10 unidades para atender todos os pedidos (totalizando 32 unidades).
  19. 19. Deadlocks: Prevenção de Deadlocks Chamamos de estado, a situação dos empréstimos e dos recursos ainda disponíveis em um dado momento. Algoritmo do Banqueiro para um único Recurso:
  20. 20. O exemplo ao lado demonstra um estado seguro, pois existe uma sequência de outros estados que leva a que todos os clientes recebam seus empréstimos até seus limites de crédito. Disponível:2 Algoritmo do Banqueiro para um único Recurso: Deadlocks: Prevenção de Deadlocks
  21. 21. • O banqueiro pode emprestar 2 unidades à C; pegar de volta (4) emprestar à B, pegar as 5 unidades de volta e emprestar à A, pegar as 6 unidades de volta e emprestar 3 delas à D, pegando então as 7 unidades de volta, garantindo o atendimento a todos os clientes. Questão??? Se por exemplo o cliente B fizesse um pedido de mais uma unidade (2) teríamos um estado não seguro? • Não há forma do banqueiro garantir o atendimento de todos os pedidos, podendo vir a gerar um deadlock. Ainda não haverá um deadlock, pois os valores de máximo não precisam necessariamente ser atingido. • Por exemplo, o cliente D pode decidir que não precisa mais de novos recursos e devolver os 4 que pediu, voltando novamente a uma situação segura. • Mas o banqueiro não pode contar com isso, então para cada pedido que chega, o banqueiro deve verificar se conceder o mesmo leva a uma situação segura, verificando se o disponível é suficiente para atender o cliente mais próximo de seu máximo. • Se for, finge que esse cliente já devolveu tudo que possuía, marca o mesmo como terminado e verifica se pode atender o cliente mais próximo do máximo entre os que restam. Se ele puder levar a bom termo esse processo, atendendo todos os clientes então o estado é seguro. Algoritmo do Banqueiro para um único Recurso: Deadlocks: Prevenção de Deadlocks
  22. 22. Exercícios 1. O que é deadlock, quais as condições para o acontecimento desses impasses e quais as soluções possíveis? 2. Pesquise e descreva o mecanismo (ideia) de funcionamento do algoritmo do banqueiro de Dijkstra proposto para evitar deadlocks. Além disso, cite as deficiências presentes nesse algoritmo. 3. Um estado inseguro é um estado de deadlock? 4. Descreva as restrições que o algoritmo do banqueiro impõe aos processos. 5. Por que a prevenção de deadlock não é uma preocupação primária para muitos sistemas operacionais? 6. Por que a recuperação de deadlock é um problema tão difícil? 7. Explique o são Recursos preemptíveis e não preemptíveis? 8. Explique as diferenças entre impasses e condição de inanição (starvation)?
  23. 23. Gerenciamento de processos
  24. 24. Políticas de escalonamento (agendamento) •SO escolhe qual processo da fila de PRONTOS irá executar •Despachante designa um processador a um dado processo •Política de escalonamento (ou disciplina de escalonamento): –Critério do SO para escolher o processo que executará
  25. 25. Políticas de escalonamento (agendamento) Forte influência no desempenho global do SO •Deve garantir: justiça, previsibilidade e escalabilidade •Deve considerar o comportamento de um processo –Processos CPU-Bound x I/O-Bound –Processos Em Lote x Interativo Objetivos do escalonamento (em relação aos processos) •Maximizar: throughput (total de processos terminados na unidade de tempo) •Minimizar: turnaround (tempo da criação até o término do processo) •Maximizar: taxa de utilização de CPU (tempo total de ocupação da CPU) •Minimizar: tempo de resposta (tempo da criação até o inicio da execução) •Minimizar: tempo de espera (soma dos tempos na fila de prontos) •Minimizar: tempo de resposta em processos interativos •Maximizar: utilização dos recursos (HW ou SW) •Minimizar: a sobrecarga de gerenciamento do SO •Favorecer: rotinas de maior prioridade e importância
  26. 26. Escalonamento
  27. 27. Poderá ser classificada como –Preemptiva –Não-preemptiva •Não-preemptiva (cooperativo) –SO não pode interromper um processo –Processo executa até concluir (ou parar voluntariamente) •Preemptiva: –SO pode interromper um processo a qualquer instante –Para executar outro processo (chaveamento de contexto) •Há vantagens e desvantagens em ambas Políticas de escalonamento (agendamento)
  28. 28. Políticasdeescalonamentocomprioridades •Permite quantificar a importância relativa dos processos •Mecanismos de prioridades são de dois tipos: –Prioridade estática –Prioridade dinâmica •Prioridade estática: –Não varia ao longo da execução do processo –Fácil de implementar •Prioridade dinâmica (mais inteligente) –Varia ao longo da execução do processo –Permite uma maior responsividade à mudanças no ambiente –Exemplos: Técnica de aging, algoritmo HRRN •Inversão de prioridade: –SO aumenta a prioridade de um processo menos importante –Diminuir sobrecarga ou liberar recursos para outro processo
  29. 29. Políticas de escalonamento: critérios Tentam implementar “justiça” na escolha dos processos •Primeiros SO eram colaborativos: ineficientes! –Exemplo: Windows 95 (multitarefa cooperativa) –Processo rodava o tempo que desejava •Regra geral: 1º: Processo que chega vai para o final da fila pronto 2º: Fila é rearranjada conforme o critério de escalonamento •Atualmente, na prática, algoritmos usados nos SO: –Combinam dois ou mais critérios e são adaptativos –Variam dinamicamente conforme os estados dos processos
  30. 30. FIFO: First In First Out Critério: ordem de chegada •Não-preemptivo (processo executa enquanto quiser) •Vantagens –Justo: atende pela ordem de chegada –Impede adiamento indefinido –Fácil de implementar •Desvantagens –Processos longos fazem os curtos esperarem muito –Não se mostra eficiente para processos interativos –Não considera a importância de uma tarefa
  31. 31. SPF: Shortest Process First Critério: tempo de execução restante (burst): menor primeiro •Não-preemptivo •Vantagens –Favorece os processos mais curtos –Aumenta o rendimento (throughput) –Menor tempo médio de espera •Desvantagens –Baseado em estimativas de tempo –Maior variância no tempo de espera (+ imprevisibilidade) –Não impede o adiamento indefinido
  32. 32. SRT: Shortest Remaining Time Critério: tempo de execução restante (burst): menor primeiro •Preemptivo (se chegar processo de menor burst) •Versão preemptiva do SPF •Vantagens –Busca minimizar tempo de espera •Desvantagens –Baseado em estimativas de tempo –Gera sobrecarga desnecessária nas troca de contexto –Usado em SO antigos (para processamento em lote)
  33. 33. RR: Round Robin (alternância circular) Critério: ordem de chegada (como no FIFO) •Preemptivo (por quantum de tempo) •Vantagens –Efetivo com processos interativos –Impede adiamento indefinido •Desvantagens –Mais complexo que FIFO –Adiciona sobrecarga no chaveamento de contexto
  34. 34. por Prioridades (Filas de Prioridades) Critério: maior prioridade primeiro •Preemptivo (por tempo e/ou prioridade de execução) •Prioridade por ser fixa ou dinâmica •Agrupa processos em filas de prioridades decrescentes –Filas mais altas são executadas primeiro (na totalidade) –Em cada fila, aplica-se RR (Round Robin)
  35. 35. Ainda Existem: • Filas Múltiplas (multinível com feedback) • Fração Justa (Fair-share) • HRRN: Highest Response Rate Next
  36. 36. Outras políticas de escalonamento • •Escalonamento Garantido • –Cumpre promessas feitas a usuários (% alocação de CPU) • •Escalonamento por Loteria • –SO distribui tokens (fichas) numerados entre os processos • –Escalonador sorteia um número aleatório • –Processos com mais tokens têm mais chance de escolha • •Vantagens • –Altamente responsivo (ao número de tokens distribuídos) • –Ideal para processos cooperativos (doação de tokens)
  37. 37. Escalonamento de Tempo Real •Ocorre em SO de tempo real •Prioriza os processos em detrimento do próprio SO •Busca produzir resultados em tempos determinados •Divide-se em 2 tipos –Crítico: prazos devem ser rigorosamente cumpridos –Não-crítico: descumprimentos de prazo são tolerados
  38. 38. Resumo: Políticas de Escalonamento

×