Slides da Aula 07
Impasses
Os sistemas computacionais estão cheios de recursos que podem ser usados somente por um processo de cada vez. Exemplos comuns incluem impressoras, unidades de fita para backup de dados da empresa e entradas nas tabelas internas do sistema. Ter dois processos escrevendo simultaneamente para a impressora gera uma saída ininteligível. Ter dois processos usando a mesma entrada da tabela do sistema de arquivos invariavelmente levará a um sistema de arquivos corrompido. Em consequência, todos os sistemas operacionais conseguem conceder (temporariamente) acesso exclusivo a um processo a determinados recursos.
Para muitas aplicações, um processo precisa de acesso exclusivo a não somente um recurso, mas a vários. Suponha, por exemplo, que dois processos queiram cada um gravar um documento escaneado em um disco Blu-ray. O processo A solicita permissão para usar o scanner e ela lhe é concedida. O processo B é programado diferentemente e solicita o gravador Blu-ray primeiro e ele também lhe é concedido. Agora A pede pelo gravador Blu-ray, mas a solicitação é suspensa até que B o libere. Infelizmente, em vez de liberar o gravador Blu-ray, B pede pelo scanner. A essa altura ambos os processos estão bloqueados e assim permanecerão para sempre. Essa situação é chamada de impasse (deadlock).
Impasses também podem ocorrer entre máquinas. Por exemplo, muitos escritórios têm uma rede de área local com muitos computadores conectados a ela. Muitas vezes dispositivos como scanners, gravadores Blu-ray/DVDs, impressoras e unidades de fitas estão conectados à rede como recursos compartilhados, disponíveis para qualquer usuário em qualquer máquina. Se esses dispositivos puderem ser reservados remotamente (isto é, da máquina da casa do usuário), impasses do mesmo tipo podem ocorrer como descrito. Situações mais complicadas podem provocar impasses envolvendo três, quatro ou mais dispositivos e usuários.
Impasses também podem ocorrer em uma série de outras situações. Em um sistema de banco de dados, por exemplo, um programa pode ter de bloquear vários registros que ele está usando a fim de evitar condições de corrida. Se o processo A bloqueia o registro R1 e o processo B bloqueia o registro R2, e então cada processo tenta bloquear o registro do outro, também teremos um impasse. Portanto, impasses podem ocorrer em recursos de hardware ou em recursos de software.
Examinaremos vários tipos de impasses, ver como eles surgem, e estudar algumas maneiras de preveni-los ou evitá-los. Embora esses impasses surjam no contexto de sistemas operacionais, eles também ocorrem em sistemas de bancos de dados e em muitos outros contextos na ciência da computação; então, este material é aplicável, a uma ampla gama de sistemas concorrentes.
Muito já foi escrito sobre impasses. Duas bibliografias sobre o assunto apareceram na Operating Systems Review e devem ser consultadas para referências (NEWTON, 1979; e ZOBEL, 1983). Embora essas bibliografias sejam muito antigas, a maior parte dos trabalhos sobre impasses foi feita bem antes de 1980, de maneira que eles ainda são úteis.
Recursos
Uma classe importante de impasses envolve recursos para os quais algum processo teve acesso exclusivo concedido. Esses recursos incluem dispositivos, registros de dados, arquivos e assim por diante. Para tornar a discussão dos impasses mais geral possível, vamos nos referir aos objetos concedidos como recursos. Um recurso pode ser um dispositivo de hardware (por exemplo, uma unidade de Blu-ray) ou um fragmento de informação (por exemplo, um registro em um banco de dados). Um computador normalmente terá muitos recursos diferentes que um processo pode adquirir. Para alguns recursos, várias instâncias idênticas podem estar disponíveis, como três unidades de Blu-rays. Quando várias cópias de um recurso encontram-se disponíveis, qualquer uma delas pode ser usada para satisfazer qualquer pedido pelo recurso. Resumindo, um recurso é qualquer coisa que precisa ser adquirida, usada e liberada com o passar do tempo.
Recursos preemptíveis e não preemptíveis
Há dois tipos de recursos: preemptíveis e não preemptíveis. Um recurso preemptível é aquele que pode ser retirado do processo proprietário sem lhe causar prejuízo algum. A memória é um exemplo de um recurso preemptível. Considere, por exemplo, um sistema com uma memória de usuário de 1 GB, uma impressora e dois processos de 1 GB cada que querem imprimir algo. O processo A solicita e ganha a impressora, então começa a computar os valores para imprimir. Antes que ele termine a computação, ele excede a sua parcela de tempo e é mandado para o disco.
O processo B executa agora e tenta, sem sucesso no fim das contas, ficar com a impressora. Potencialmente, temos agora uma situação de impasse, pois A tem a impressora e B tem a memória, e nenhum dos dois pode proceder sem o recurso contido pelo outro. Felizmente, é possível obter por preempção (tomar a memória) de B enviando-o para o disco e trazendo A de volta. Agora A pode executar, fazer sua impressão e então liberar a impressora. Nenhum impasse ocorre.
Um recurso não preemptível, por sua vez, é um recurso que não pode ser tomado do seu proprietário atual sem potencialmente causar uma falha. Se um processo começou a ser executado em um Blu-ray, tirar o gravador Blu-ray dele de repente e dá-lo a outro processo resultará em um Blu-ray bagunçado. Gravadores Blu-ray não são preemptíveis em um momento arbitrário. A questão se um recurso é preemptível depende do contexto. Em um PC padrão, a memória é preemptível porque as páginas sempre podem ser enviadas para o disco para depois recuperá-las. No entanto, em um smartphone que não suporta trocas (swapping) ou paginação, impasses não podem ser evitados simplesmente trocando uma porção da memória.
Em geral, impasses envolvem recursos não preemptíveis. Impasses potenciais que envolvem recursos preemptíveis normalmente podem ser solucionados realocando recursos de um processo para outro. Desse modo, nosso estudo enfocará os recursos não preemptíveis.
A sequência abstrata de eventos necessários para usar um recurso é dada a seguir.
- Solicitar o recurso.
- Usar o recurso.
- Liberar o recurso.
Se o recurso não está disponível quando ele é solicitado, o processo que o está solicitando é forçado a esperar. Em alguns sistemas operacionais, o processo é automaticamente bloqueado quando uma solicitação de recurso falha, e despertado quando ela se torna disponível. Em outros sistemas, a solicitação falha com um código de erro, e cabe ao processo que está fazendo a chamada esperar um pouco e tentar de novo.
Um processo cuja solicitação de recurso foi negada há pouco, normalmente esperará em um laço estreito solicitando o recurso, dormindo ou tentando novamente. Embora esse processo não esteja bloqueado, para todos os efeitos e propósitos é como se estivesse, pois ele não pode realizar nenhum trabalho útil. Mais adiante, presumiremos que, quando um processo tem uma solicitação de recurso negada, ele é colocado para dormir.
A exata natureza da solicitação de um recurso é altamente dependente do sistema. Em alguns sistemas, uma chamada de sistema request é fornecida para permitir que os processos peçam explicitamente por recursos. Em outros, os únicos recursos que o sistema operacional conhece são arquivos especiais que somente um processo pode ter aberto de cada vez. Esses são abertos pela chamada open usual. Se o arquivo já está sendo usado, o processo chamador é bloqueado até o arquivo ser fechado pelo seu proprietário atual.
Aquisição de recursos
Para alguns tipos de recursos, como registros em um sistema de banco de dados, cabe aos processos do usuário, em vez do sistema, gerenciar eles mesmos o uso de recursos. Uma maneira de permitir isso é associar um semáforo a cada recurso. Esses semáforos são todos inicializados com 1. Também podem ser usadas variáveis do tipo mutex. Os três passos listados são então implementados como um down no semáforo para aquisição e utilização do recurso e, por fim, um up no semáforo para liberação do recurso. Esses passos são mostrados
na figura “Uso de Semáforo”.

Às vezes, processos precisam de dois ou mais recursos. Eles podem ser adquiridos em sequência, como mostrado na figura “Uso de Semáforo”(b). Se mais de dois recursos são necessários, eles são simplesmente adquiridos um depois do outro.
Até aqui, nenhum problema. Enquanto apenas um processo estiver envolvido, tudo funciona bem. É claro, com apenas um processo, não há a necessidade de adquirir formalmente recursos, já que não há competição por eles.
Agora vamos considerar uma situação com dois processos, A e B, e dois recursos. Dois cenários são descritos na figura “Impasse”. Na figura “Impasse”(a), ambos os processos solicitam pelos recursos na mesma ordem. Na figura “Impasse”(b), eles os solicitam em uma ordem diferente. Essa diferença pode parecer menor, mas não é. Na figura “Impasse”(a), um dos processos adquirirá o primeiro recurso antes do outro. Esse processo então será bem-sucedido na aquisição do segundo recurso e realizará o seu trabalho. Se o outro processo tentar adquirir o recurso 1 antes que ele seja liberado, o outro processo será simplesmente bloqueado até que o recurso esteja disponível.

Como todos os processos estão esperando, nenhum deles jamais causará qualquer evento que possa despertar um dos outros membros do conjunto, e todos os processos continuam a esperar para sempre. Para esse modelo, presumimos que os processos têm um único thread e que nenhuma interrupção é possível para despertar um processo bloqueado. A condição de não haver interrupções é necessária para evitar que um processo em situação de impasse seja acordado por, digamos, um alarme, e então cause eventos que liberem outros processos no conjunto.
Na maioria dos casos, o evento que cada processo está esperando é a liberação de algum recurso atualmente possuído por outro membro do conjunto. Em outras palavras, cada membro do conjunto de processos em situação de impasse está esperando por um recurso que é de propriedade do processo em situação de impasse. Nenhum dos processos pode executar, nenhum deles pode liberar quaisquer recursos e nenhum pode ser desperto. O número de processos e o número e tipo de recursos possuídos e solicitados não têm importância. Esse resultado é válido para qualquer tipo de recurso, incluindo hardwares e softwares. Esse tipo de impasse é chamado de impasse de recurso, e é provavelmente o tipo mais comum, mas não o único. Estudaremos primeiro os impasses de recursos em detalhe e, então, no fim do capítulo, retornaremos brevemente para os outros tipos de impasses.
Condições para ocorrência de impasses
Coffman et al. (1971) demonstraram que quatro condições têm de ser válidas para haver um impasse (de recurso):
- Condição de exclusão mútua. Cada recurso está atualmente associado a exatamente um processo ou está disponível.
- Condição de posse e espera. Processos atualmente de posse de recursos que foram concedidos antes podem solicitar novos recursos
- Condição de não preempção. Recursos concedidos antes não podem ser tomados à força de um processo. Eles precisam ser explicitamente liberados pelo processo que os têm.
- Condição de espera circular. Deve haver uma lista circular de dois ou mais processos, cada um deles esperando por um processo de posse do membro seguinte da cadeia.
Todas essas quatro condições devem estar presentes para que um impasse de recurso ocorra. Se uma delas estiver ausente, nenhum impasse de recurso será possível.
Vale a pena observar que cada condição se relaciona com uma política que um sistema pode ter ou não. Pode um dado recurso ser designado a mais um processo ao mesmo tempo? Pode um processo ter a posse de um recurso e pedir por outro? Os recursos podem passar por preempção? Esperas circulares podem existir? Mais tarde veremos como os impasses podem ser combatidos tentando negar-lhes algumas dessas condições.
Modelagem de impasses
Holt (1972) demonstrou como essas quatro condições podem ser modeladas com grafos dirigidos. Os grafos têm dois tipos de nós: processos, mostrados como círculos, e recursos, mostrados como quadrados. Um arco direcionado de um nó de recurso (quadrado) para um nó de processo (círculo) significa que o recurso foi previamente solicitado, concedido e está atualmente com aquele processo. Na figura “Grafos de alocação de recursos”(a), o recurso R está atualmente alocado ao processo A.
Um arco direcionado de um processo para um recurso significa que o processo está atualmente bloqueado esperando por aquele recurso. Na figura “Grafos de alocação de recursos”(b), o processo B está esperando pelo recurso S. Na figura “Grafos de alocação de recursos”(c) vemos um impasse: o processo C está esperando pelo recurso T, que atualmente está sendo usado pelo processo D. O processo D não está prestes a liberar o recurso T porque ele está esperando pelo recurso U, sendo usado por C. Ambos os processos esperarão para sempre. Um ciclo no grafo significa que há um impasse envolvendo os processos e recursos no ciclo (presumindo que há um recurso de cada tipo). Nesse exemplo, o ciclo é C – T – D – U – C.

Agora vamos examinar um exemplo de como grafos de recursos podem ser usados. Imagine que temos três processos, A, B e C, e três recursos, R, S e T. As solicitações e as liberações dos três processos são dadas na figura “Evitar Impasse”(a) a (c). O sistema operacional está liberado para executar qualquer processo desbloqueado a qualquer instante, então ele poderia decidir executar A até A ter concluído o seu trabalho, então executar B até sua conclusão e por fim executar C.

Essa ordem de execução não leva a impasse algum (pois não há competição por recursos), mas também não há paralelismo algum. Além de solicitar e liberar recursos, processos calculam e realizam E/S. Quando os processos são executados sequencialmente, não existe a possibilidade de enquanto um processo espera pela E/S, outro poder usar a CPU. Desse modo, executar os processos de maneira estritamente sequencial pode não ser uma opção ótima. Por outro lado, se nenhum dos processos realizar qualquer E/S, o algoritmo trabalho mais curto primeiro é melhor do que a alternância circular, de maneira que em determinadas circunstâncias executar todos os processos sequencialmente pode ser a melhor maneira.
Vamos supor agora que os processos realizam E/S e computação, então a alternância circular é um algoritmo de escalonamento razoável. As solicitações de recursos podem ocorrer na ordem da Figura 6.4(d). Se as seis solicitações forem executadas nessa ordem, os seis grafos de recursos resultantes serão como mostrado na figura “Evitar Impasse” (e) a (j). Após a solicitação 4 ter sido feita, A bloqueia esperando por S, como mostrado na figura “Evitar Impasse”(h). Nos próximos dois passos, B e C também bloqueiam, em última análise levando a um ciclo e ao impasse da figura “Evitar Impasse”(j).
No entanto, como já mencionamos, não é exigido do sistema operacional que execute os processos em qualquer ordem especial. Em particular, se conceder uma solicitação específica pode levar a um impasse, o sistema operacional pode simplesmente suspender o processo sem conceder a solicitação (isto é, apenas não escalonar o processo) até que seja seguro. Na figura “Evitar Impasse”, se o sistema operacional soubesse a respeito do impasse iminente, ele poderia suspender B em vez de conceder-lhe S. Ao executar apenas A e C, teríamos as solicitações e liberações da figura “Evitar Impasse(k) em vez da figura “Evitar Impasse”(d). Essa sequência conduz aos grafos de recursos da figura “Evitar Impasse”(l) a (q), que não levam a um impasse.
Após o passo (q), S pode ser concedido ao processo B porque A foi concluído e C tem tudo de que ele precisa. Mesmo que B bloqueie quando solicita T, nenhum impasse pode ocorrer. B apenas esperará até que C tenha terminado.
Mais tarde neste capítulo estudaremos um algoritmo detalhado para tomar decisões de alocação que não levam a um impasse. Por ora, basta compreender que grafos de recursos são uma ferramenta que nos deixa ver se uma determinada sequência de solicitação/liberação pode levar a um impasse. Apenas atendemos às solicitações e liberações passo a passo e após cada passo conferimos o grafo para ver se ele contém algum ciclo. Se afirmativo, temos um impasse; se não, não há impasse. Embora nosso tratamento de grafos de recursos tenha sido para o caso de um único recurso de cada tipo, grafos de recursos também podem ser generalizados para lidar com múltiplos recursos do mesmo tipo (HOLT, 1972).
Em geral, quatro estratégias são usadas para lidar com impasses.
- Simplesmente ignorar o problema. Se você o ignorar, quem sabe ele ignore você.
- Detecção e recuperação. Deixe-os ocorrer, detecte-os e tome as medidas cabíveis.
- Evitar dinamicamente pela alocação cuidadosa de recursos.
- Prevenção, ao negar estruturalmente uma das quatro condições.
Algoritmo do avestruz
A abordagem mais simples é o algoritmo do avestruz: enfie a cabeça na areia e finja que não há um problema. As pessoas reagem a essa estratégia de maneiras diferentes. Matemáticos a consideram inaceitável e dizem que os impasses devem ser evitados a todo custo. Engenheiros perguntam qual a frequência que se espera que o problema ocorra, qual a frequência com que ocorrem quedas no sistema por outras razões e quão sério um impasse é realmente. Se os impasses ocorrem na média uma vez a cada cinco anos, mas quedas do sistema decorrentes de falhas no hardware e defeitos no sistema operacional ocorrem uma vez por semana, a maioria dos engenheiros não estaria disposta a pagar um alto preço em termos de desempenho ou conveniência para eliminar os impasses.
Para tornar esse contraste mais específico, considere um sistema operacional que bloqueia o chamador quando uma chamada de sistema open para um dispositivo físico como um driver de Blu-ray ou uma impressora não pode ser executada porque o dispositivo está ocupado. Tipicamente cabe ao driver do dispositivo decidir qual ação tomar sob essas circunstâncias. Bloquear ou retornar um código de erro são duas possibilidades óbvias. Se um processo tiver sucesso em abrir a unidade de Blu-ray e outro tiver sucesso em abrir a impressora e então os dois tentarem abrir o recurso um do outro e forem bloqueados tentando, temos um impasse. Poucos sistemas atuais detectarão isso.
Detecção e recuperação de impasses
Uma segunda técnica é a detecção e recuperação. Quando essa técnica é usada, o sistema não tenta evitar a ocorrência dos impasses. Em vez disso, ele os deixa ocorrer, tenta detectá-los quando acontecem e então toma alguma medida para recuperar-se após o fato. Nesta seção examinaremos algumas maneiras como os impasses podem ser detectados e tratados.
Detecção de impasses com um recurso de cada tipo
Vamos começar com o caso mais simples: existe apenas um recurso de cada tipo. Um sistema assim poderia ter um scanner, um gravador Blu-ray, uma plotter e uma unidade de fita, mas não mais do que um de cada classe de recurso. Em outras palavras, estamos excluindo sistemas com duas impressoras por ora. Trataremos deles mais tarde, usando um método diferente.
Para esse sistema, podemos construir um grafo de recursos do tipo ilustrado na figura “Grafo de Recurso”. Se esse grafo contém um ou mais ciclos, há um impasse. Qualquer processo que faça parte de um ciclo está em situação de impasse. Se não existem ciclos, o sistema não está em impasse.
Como um exemplo de um sistema mais complexo do que aqueles que examinamos até o momento, considere um sistema com sete processos, A até G e seis recursos, R até W. O estado de quais recursos estão sendo atualmente usados e quais estão sendo solicitados é o seguinte:
- O processo A possui R e solicita S.
- O processo B não possui nada, mas solicita T.
- O processo C não possui nada, mas solicita S.
- O processo D possui U e solicita S e T.
- O processo E possui T e solicita V.
- O processo F possui W e solicita S.
- O processo G possui V e solicita U.
A questão é: “Esse sistema está em impasse? E se estiver, quais processos estão envolvidos?”.
Para responder, podemos construir o grafo de recursos da figura “Grafo de Recursos”(a). Esse grafo contém um ciclo, que pode ser visto por inspeção visual. O ciclo é mostrado na figura “Grafo de Recusros”(b). Desse ciclo, podemos ver que os processos D, E e G estão todos em situação de impasse. Os processos A, C e F não estão em situação de impasse porque S pode ser alocado para qualquer um deles, permitindo sua conclusão e retorno do recurso. Então os outros dois podem obtê-lo por sua vez e também ser finalizados. (Observe que a fim de tornar esse exemplo mais interessante permitimos que processos, a saber D, solicitasse por dois recursos ao mesmo tempo.)
Embora seja relativamente simples escolher os processos em situação de impasse mediante inspeção visual de um grafo simples, para usar em sistemas reais precisamos de um algoritmo formal para detectar impasses. Muitos algoritmos para detectar ciclos em grafos direcionados são conhecidos. A seguir exibiremos um algoritmo simples que inspeciona um grafo e termina quando ele encontrou um ciclo ou quando demonstrou que nenhum existe. Ele usa uma estrutura de dados dinâmica, L, uma lista de nós, assim como uma lista de arcos. Durante o algoritmo, a fim de evitar inspeções repetidas, arcos serão marcados para indicar que já foram inspecionados.
O algoritmo opera executando os passos a seguir como especificado:
- Para cada nó, N, no grafo, execute os cinco passos a seguir com N como o nó de partida.
- Inicialize L como uma lista vazia e designe todos os arcos como desmarcados.
- Adicione o nó atual ao final de L e confira para ver se o nó aparece agora em L duas vezes. Se ele aparecer, o grafo contém um ciclo (listado em L) e o algoritmo termina.
- A partir do referido nó, verifique se há algum arco de saída desmarcado. Se afirmativo, vá para o passo 5; se não, vá para o passo 6.
- Escolha aleatoriamente um arco de saída desmarcado e marque-o. Então siga-o para gerar o novo nó atual e vá para o passo 3.
- Se esse nó é o inicial, o grafo não contém ciclo algum e o algoritmo termina. De outra maneira, chegamos agora a um beco sem saída. Remova-o e volte ao nó anterior, isto é, aquele que era atual imediatamente antes desse, faça dele o nó atual e vá para o passo 3.

O que esse algoritmo faz é tomar cada nó, um de cada vez, como a raiz do que ele espera ser uma árvore e então realiza uma busca do tipo busca em profundidade nele. Se acontecer de ele voltar a um nó que já havia encontrado, então o algoritmo encontrou um ciclo. Se ele exaurir todos os arcos de um dado nó, ele retorna ao nó anterior. Se ele retornar até a raiz e não conseguir seguir adiante, o subgrafo alcançável a partir do nó atual não contém ciclo algum. Se essa propriedade for válida para todos os nós, o grafo inteiro está livre de ciclos, então o sistema não está em impasse.
Para ver como o algoritmo funciona na prática, vamos usá-lo no grafo da figura “Grafo de Recursos”(a). A ordem de processamento dos nós é arbitrária; portanto, vamos apenas inspecioná-los da esquerda para a direita, de cima para baixo, executando primeiro o algoritmo começando em R, então sucessivamente A, B, C, S, D, T, E, F e assim por diante. Se depararmos com um ciclo, o algoritmo para.
Começamos em R e inicializamos L como lista vazia. Então adicionamos R à lista e vamos para a única possibilidade, A, e a adicionamos a L, resultando em L = [R, A]. De A vamos para S, resultando em L = [R, A, S]. S não tem arcos de saída, então trata-se de um beco sem saída, forçando-nos a recuar para A. Já que A não tem arcos de saída desmarcados, recuamos para R, completando nossa inspeção de R.
Agora reinicializamos o algoritmo começando em A, reinicializando L para a lista vazia. Essa busca também para rapidamente, então começamos novamente em B. De B continuamos para seguir os arcos de saída até chegarmos a D, momento em que L = [B, T, E, V, G, U, D]. Agora precisamos fazer uma escolha (ao acaso). Se escolhermos S, chegaremos a um beco sem saída e recuaremos para D. Na segunda tentativa, escolhemos T e atualizamos L para ser [B, T, E, V, G, U, D, T], ponto em que descobrimos o ciclo e paramos o algoritmo.
Esse algoritmo está longe de ser ótimo. Para um algoritmo melhor, ver Even (1979). Mesmo assim, ele demonstra que existe um algoritmo para detecção de impasses.
Detecção de impasses com múltiplos recursos de cada tipo
Quando existem múltiplas cópias de alguns dos recursos, é necessária uma abordagem diferente para detectar impasses. Apresentaremos agora um algoritmo baseado em matrizes para detectar impasses entre n processos, P1 a Pn. Seja m o número de classes de recursos, com E1 recursos de classe 1, E2 recursos de classe 2, e geralmente, Ei recursos de classe i (1 ≤ i ≤ m). E é o vetor de recursos existentes. Ele fornece o número total de instâncias de cada recurso existente. Por exemplo, se a classe 1 for de unidades de fita, então E1 = 2 significa que o sistema tem duas unidades de fita.
A qualquer instante, alguns dos recursos são alocados e não se encontram disponíveis. Seja A o vetor de recursos disponíveis, com Ai dando o número de instâncias de recurso i atualmente disponíveis (isto é, não alocadas). Se ambas as nossas unidades de fita estiverem alocadas, A1 será 0.
Agora precisamos de dois arranjos, C, a matriz de alocação atual e R, a matriz de requisição. A i-ésima linha de C informa quantas instâncias de cada classe de recurso Pi atualmente possui. Desse modo, Cij é o número de instâncias do recurso j que são possuídas pelo processo i. Similarmente, Rij é o número de instâncias do recurso j que Pi quer. Essas quatro estruturas de dados são mostradas na figura “Algoritmo de Detecção”.

Uma importante condição invariante se aplica a essas quatro estruturas de dados. Em particular, cada recurso é alocado ou está disponível. Essa observação significa que
Em outras palavras, se somarmos todas as instâncias do recurso j que foram alocadas e a isso adicionarmos todas as instâncias que estão disponíveis, o resultado será o número de instâncias existentes daquela classe de recursos.
O algoritmo de detecção de impasses é baseado em vetores de comparação. Vamos definir a relação A ≤ B, entre dois vetores A e B, para indicar que cada elemento de A é menor do que ou igual ao elemento correspondente de B. Matematicamente, A ≤ B se mantém se e somente se Ai ≤ Bi para 1 ≤ i ≤ m.
Diz-se que cada processo, inicialmente, está desmarcado. À medida que o algoritmo progride, os processos serão marcados, indicando que eles são capazes de completar e portanto não estão em uma situação de impasse. Quando o algoritmo termina, sabe-se que quaisquer processos desmarcados estão em situação de impasse. Esse algoritmo presume o pior cenário possível: todos os processos mantêm todos os recursos adquiridos até que terminem.
O algoritmo de detecção de impasses pode ser dado agora como a seguir.
- Procure por um processo desmarcado, Pi , para o qual a i-ésima linha de R seja menor ou igual a A.
- Se um processo assim for encontrado, adicione a i-ésima linha de C a A, marque o processo e volte ao passo 1.
- Se esse processo não existir, o algoritmo termina.
Quando o algoritmo terminar, todos os processos desmarcados, se houver algum, estarão em situação de impasse.
O que o algoritmo está fazendo no passo 1 é procurar por um processo que possa ser executado até o fim. Esse processo é caracterizado por ter demandas de recursos que podem ser atendidas pelos recursos atualmente disponíveis. O processo escolhido é então executado até ser concluído, momento em que ele retorna os recursos a ele alocados para o pool de recursos disponíveis. Ele então é marcado como concluído. Se todos os processos são, em última análise, capazes de serem executados até a sua conclusão, nenhum deles está em situação de impasse. Se alguns deles jamais puderem ser concluídos, eles estão em situação de impasse. Embora o algoritmo seja não determinístico (pois ele pode executar os processos em qualquer ordem possível), o resultado é sempre o mesmo.
Como um exemplo de como o algoritmo de detecção de impasses funciona, observe a figura “Detecção de Impasses”. Aqui temos três processos e quatro classes de recursos, os quais rotulamos arbitrariamente como unidades de fita, plotters, scanners e unidades de Blu-ray. O processo 1 tem um scanner. O processo 2 tem duas unidades de fitas e uma unidade de Blu-ray. O processo 3 tem uma plotter e dois scanners. Cada processo precisa de recursos adicionais, como mostrado na matriz R.
Para executar o algoritmo de detecção de impasses, procuramos por um processo cuja solicitação de recursos possa ser satisfeita. O primeiro não pode ser satisfeito, pois não há uma unidade de Blu-ray disponível. O segundo também não pode ser satisfeito, pois não há um scanner liberado. Felizmente, o terceiro pode ser satisfeito, de maneira que o processo 3 executa e eventualmente retorna todos os seus recursos, resultando em
A = (2 2 2 0)
Nesse ponto o processo 2 pode executar e retornar os seus recursos, resultando em
A = (4 2 2 1)
Agora o restante do processo pode executar. Não há um impasse no sistema. Agora considere uma variação menor da situação da figura “Detecção de Impasses”. Suponha que o processo 3 precisa de uma unidade de Blu-ray, assim como as duas unidades de fitas e a plotter. Nenhuma das solicitações pode ser satisfeita, então o sistema inteiro eventualmente estará em uma situação de impasse. Mesmo se dermos ao processo 3 suas duas unidades de fitas e um plotter, o sistema entrará em uma situação de impasse quando ele solicitar a unidade de Blu-ray.

Agora que sabemos como detectar impasses (pelo menos com solicitações de recursos estáticos conhecidas antecipadamente), surge a questão de quando procurar por eles. Uma possibilidade é verificar todas as vezes que uma solicitação de recursos for feita. Isso é certo que irá detectá-las o mais cedo possível, mas é uma alternativa potencialmente cara em termos de tempo da CPU. Uma
estratégia possível é fazer a verificação a cada k minutos, ou talvez somente quando a utilização da CPU cair abaixo de algum limiar. A razão para considerar a utilização da CPU é que se um número suficiente de processos estiver em situação de impasse, haverá menos processos executáveis, e a CPU muitas vezes estará ociosa.
Recuperação de um impasse
Suponha que nosso algoritmo de detecção de impasses teve sucesso e detectou um impasse. O que fazer então? Alguma maneira é necessária para recuperar o sistema e colocá-lo em funcionamento novamente. Nesta seção discutiremos várias maneiras de conseguir isso. Nenhuma delas é especialmente atraente, no entanto.
Recuperação mediante preempção
Em alguns casos pode ser viável tomar temporariamente um recurso do seu proprietário atual e dá-lo a outro processo. Em muitos casos, pode ser necessária a intervenção manual, especialmente em sistemas operacionais de processamento em lote executando em computadores de grande porte.
Por exemplo, para tomar uma impressora a laser de seu processo-proprietário, o operador pode juntar todas as folhas já impressas e colocá-las em uma pilha. Então o processo pode ser suspenso (marcado como não executável). Nesse ponto, a impressora pode ser alocada para outro processo. Quando esse processo terminar, a pilha de folhas impressas pode ser colocada de volta na bandeja de saída da impressora, e o processo original reinicializado.
A capacidade de tirar um recurso de um processo, entregá-lo a outro para usá-lo e então devolvê-lo sem que o processo note isso é algo altamente dependente da natureza do recurso. A recuperação dessa maneira é com frequência difícil ou impossível. Escolher o processo a ser suspenso depende em grande parte de quais processos têm recursos que podem ser facilmente devolvidos.
Recuperação mediante retrocesso
Se os projetistas de sistemas e operadores de máquinas souberem que a probabilidade da ocorrência de impasses é grande, eles podem arranjar para que os processos gerem pontos de salvaguarda (checkpoints) periodicamente. Gerar este ponto de salvaguarda de um processo significa que o seu estado é escrito para um arquivo, para que assim ele possa ser reinicializado mais tarde. O ponto de salvaguarda contém não apenas a imagem da memória, mas também o estado dos recursos, em outras palavras, quais recursos estão atualmente alocados para o processo. Para serem mais eficientes, novos pontos de salvaguarda não devem sobrescrever sobre os antigos, mas serem escritos para os arquivos novos, de maneira que à medida que o processo executa, toda uma sequência se acumula.
Quando um impasse é detectado, é fácil ver quais recursos são necessários. Para realizar a recuperação, um processo que tem um recurso necessário é retrocedido até um ponto no tempo anterior ao momento em que ele adquiriu aquele recurso, reiniciando em um de seus pontos de salvaguarda anteriores. Todo o trabalho realizado desde o ponto de salvaguarda é perdido (por exemplo, a produção impressa desde o ponto de salvaguarda deve ser descartada, tendo em vista que ela será impressa novamente). Na realidade, o processo é reiniciado para um momento anterior quando ele não tinha o recurso, que agora é alocado para um dos processos em situação de impasse. Se o processo reiniciado tentar adquirir o recurso novamente, terá de esperar até que ele se torne disponível.
Recuperação mediante a eliminação de processos
A maneira mais bruta de eliminar um impasse, mas também a mais simples, é matar um ou mais processos. Uma possibilidade é matar um processo no ciclo. Com um pouco de sorte, os outros processos serão capazes de continuar. Se isso não ajudar, essa ação pode ser repetida até que o ciclo seja rompido.
Como alternativa, um processo que não está no ciclo pode ser escolhido como vítima a fim liberar os seus recursos. Nessa abordagem, o processo a ser morto é cuidadosamente escolhido porque ele tem em mãos recursos que algum processo no ciclo precisa. Por exemplo, um processo pode ter uma impressora e querer um plotter, com outro processo tendo um plotter e querendo uma impressora. Ambos estão em situação de impasse. Um terceiro processo pode ter outra impressora idêntica e outra plotter idêntica e estar executando feliz da vida. Matar o terceiro processo liberará esses recursos e acabará com o impasse envolvendo os dois primeiros.
Sempre que possível, é melhor matar um processo que pode ser reexecutado desde o início sem efeitos danosos. Por exemplo, uma compilação sempre pode ser reexecutada, pois tudo o que ela faz é ler um arquivo-fonte e produzir um arquivo-objeto. Se ela for morta durante uma execução, a primeira execução não terá influência alguma sobre a segunda.
Por outro lado, um processo que atualiza um banco de dados nem sempre pode executar uma segunda vez com segurança. Se ele adicionar 1 a algum campo de uma tabela no banco de dados, executá-lo uma vez, matá-lo e então executá-lo novamente adicionará 2 ao campo, o que é incorreto.
Evitando impasses
Na discussão da detecção de impasses, presumimos tacitamente que, quando um processo pede por recursos, ele pede por todos eles ao mesmo tempo. Na maioria dos sistemas, no entanto, os recursos são solicitados um de cada vez. O sistema precisa ser capaz de decidir se conceder um recurso é seguro ou não e fazer a alocação somente quando for. Desse modo, surge a questão: existe um algoritmo que possa sempre evitar o impasse fazendo a escolha certa o tempo inteiro? A resposta é um sim qualificado — podemos evitar impasses, mas somente se determinadas informações estiverem disponíveis. Nesta seção examinaremos maneiras de evitar um impasse por meio da alocação cuidadosa de recursos.
Trajetórias de recursos
Os principais algoritmos para evitar impasses são baseados no conceito de estados seguros. Antes de descrevê-los, faremos uma ligeira digressão para examinar o conceito de segurança em uma maneira gráfica e fácil de compreender. Embora a abordagem gráfica não se traduza diretamente em um algoritmo utilizável, ela proporciona um bom sentimento intuitivo para a natureza do problema.
Na figura “Trajetória de Recursos” vemos um modelo para lidar com dois processos e dois recursos, por exemplo, uma impressora e uma plotter. O eixo horizontal representa o número de instruções executadas pelo processo A. O eixo vertical representa o número de instruções executadas pelo processo B. Em I1 o processo A solicita uma impressora; em I2 ele precisa de um plotter. A impressora e a plotter são liberadas em I3 e I4, respectivamente. O processo B precisa do plotter de I5 a I7 e a impressora, de I6 a I8.
Todo ponto no diagrama representa um estado de junção dos dois processos. No início, o estado está em p, com nenhum processo tendo executado quaisquer instruções. Se o escalonador escolher executar A primeiro, chegamos ao ponto q, no qual A executou uma série de instruções, mas B não executou nenhuma. No ponto q a trajetória torna-se vertical, indicando que o escalonador escolheu executar B. Com um único processador, todos os caminhos devem ser horizontais ou verticais, jamais diagonais. Além disso, o movimento é sempre para o norte ou leste, jamais para o sul ou oeste (pois processos não podem voltar atrás em suas execuções, é claro).
Quando A cruza a linha I1 no caminho de r para s, ele solicita a impressora e está lhe é concedida. Quando B atinge o ponto t, ele solicita a plotter.
As regiões sombreadas são especialmente interessantes. A região com linhas inclinadas à direita representa ambos os processos tendo a impressora. A regra da exclusão mútua torna impossível entrar essa região. Similarmente, a região sombreada no outro sentido representa ambos os processos tendo a plotter e é igualmente impossível.

Sempre que o sistema entrar no quadrado delimitado por I1 e I2 nas laterais e I5 e I6 na parte de cima e de baixo, ele eventualmente entrará em uma situação de impasse quando chegar à interseção de I2 e I6. Nesse ponto, A está solicitando a plotter e B, a impressora, e ambas já foram alocadas. O quadrado inteiro é inseguro e não deve ser adentrado. No ponto t, a única coisa segura a ser feita é executar o processo A até ele chegar a I4. Além disso, qualquer trajetória para u será segura.
A questão importante a atentarmos aqui é que no ponto t, B está solicitando um recurso. O sistema precisa decidir se deseja concedê-lo ou não. Se a concessão for feita, o sistema entrará em uma região insegura e eventualmente em uma situação de impasse. Para evitar o impasse, B deve ser suspenso até que A tenha solicitado e liberado a plotter.
Estados seguros e inseguros
A qualquer instante no tempo, há um estado atual consistindo de E, A, C e R. Diz-se de um estado que ele é seguro se existir alguma ordem de escalonamento na qual todos os processos puderem ser executados até sua conclusão mesmo que todos eles subitamente solicitem seu número máximo de recursos imediatamente. É mais fácil ilustrar esse conceito por meio de um exemplo usando um recurso. Na figura “Demonstração de Estado 1″(a) temos um estado no qual A tem três instâncias do recurso, mas talvez precise de até nove instâncias. B atualmente tem duas e talvez precise de até quatro no total, mais tarde. De modo similar, C também tem duas, mas talvez precise de cinco adicionais. Existe um total de 10 instâncias de recursos, então com sete recursos já alocados, três ainda estão livres.

O estado da figura ” Demonstração de Estado 1″(a) é seguro porque existe uma sequência de alocações que permite que todos os processos sejam concluídos. A saber, o escalonador pode apenas executar B exclusivamente, até ele pedir e receber mais duas instâncias do recurso, levando ao estado da figura ” Demonstração de Estado 1″(b). Quando B termina, temos o estado da figura ” Demonstração de Estado 1″(c). Então o escalonador pode executar C, levando em consequência à figura ” Demonstração de Estado 1″(d). Quando C termina, temos a figura ” Demonstração de Estado 1″(e). Agora A pode ter as seis instâncias do recurso que ele precisa e também terminar. Assim, o estado da figura ” Demonstração de Estado 1″(a) é seguro porque o sistema, pelo escalonamento cuidadoso, pode evitar o impasse.
Agora suponha que tenhamos o estado inicial mostrado na figura “Demonstração de Estado 2″(a), mas dessa vez A solicita e recebe outro recurso, gerando a figura “Demonstração de Estado 2″(b). É possível encontrarmos uma sequência que seja garantida que funcione? Vamos tentar. O escalonador poderia executar B até que ele pedisse por todos os seus recursos, como mostrado na figura “Demonstração de Estado 2″(c).
Por fim, B termina e temos o estado da figura “Demonstração de Estado 2″(d). Nesse ponto estamos presos. Temos apenas quatro instâncias do recurso disponíveis, e cada um dos processos ativos precisa de cinco. Não há uma sequência que garanta a conclusão. Assim, a decisão de alocação que moveu o sistema da figura “Demonstração de Estado 2″(a) para a figura “Demonstração de Estado 2″(b) foi de um estado seguro para um inseguro. Executar A ou C em seguida começando na figura “Demonstração de Estado 2″(b) também não funciona. Em retrospectiva, a solicitação de A não deveria ter sido concedida.

Vale a pena observar que um estado inseguro não é um estado em situação de impasse. Começando na figura “Demonstração de Estado 2″(b), o sistema pode executar por um tempo. Na realidade, um processo pode até terminar. Além disso, é possível que A consiga liberar um recurso antes de pedir por mais, permitindo a C que termine e evitando inteiramente um impasse. Assim, a diferença entre um estado seguro e um inseguro é que a partir de um seguro o sistema pode garantir que todos os processos terminarão; a partir de um estado inseguro, nenhuma garantia nesse sentido pode ser dada.
O algoritmo do banqueiro para um único recurso
Um algoritmo de escalonamento que pode evitar impasses foi desenvolvido por Dijkstra (1965); ele é conhecido como o algoritmo do banqueiro. Ele é modelado da maneira pela qual um banqueiro de uma cidade pequena poderia lidar com um grupo de clientes para os quais ele concedeu linhas de crédito. (Anos atrás, os bancos não emprestavam dinheiro a não ser que tivessem certeza de que poderiam ser ressarcidos.) O que o algoritmo faz é conferir para ver se conceder a solicitação leva a um estado inseguro. Se afirmativo, a solicitação é negada. Se conceder a solicitação conduz a um estado seguro, ela é levada adiante. Na figura “Alocação de Recursos”(a) vemos quatro clientes, A, B, C e D, cada um tendo recebido um determinado número de unidades de crédito (por exemplo, 1 unidade é 1K dólares). O banqueiro sabe que nem todos os clientes precisarão de seu crédito máximo imediatamente, então ele reservou apenas 10 unidades em vez de 22 para servi-los. (Nessa analogia, os clientes são processos, as unidades são, digamos, unidades de fita, e o banqueiro é o sistema operacional.)
Os clientes cuidam de seus respectivos negócios, fazendo solicitações de empréstimos de tempos em tempos (isto é, pedindo por recursos). Em um determinado momento, a situação é como a mostrada na figura “Alocação de Recursos”(b). Esse estado é seguro porque restando duas unidades, o banqueiro pode postergar quaisquer solicitações exceto as de C, deixando então C terminar e liberar todos os seus quatro recursos. Com quatro unidades nas mãos, o banqueiro pode deixar D ou B terem as unidades necessárias, e assim por diante.
Considere o que aconteceria se uma solicitação de B por mais uma unidade fosse concedida na figura “Alocação de Recursos”(b). Teríamos a situação da figura “Alocação de Recursos”(c), que é insegura. Se todos os clientes subitamente pedissem por seus empréstimos máximos, o banqueiro não poderia satisfazer nenhum deles, e teríamos um impasse. Um estado inseguro não precisa levar a um impasse, tendo em vista que um cliente talvez não precise de toda a linha de crédito disponível, mas o banqueiro não pode contar com esse comportamento.

O algoritmo do banqueiro considera cada solicitação à medida que ela ocorre, vendo se concedê-la leva a um estado seguro. Se afirmativo, a solicitação é concedida; de outra maneira, ela é adiada. Para ver se um estado é seguro, o banqueiro confere para ver se ele tem recursos suficientes para satisfazer algum cliente. Se afirmativo, presume-se que os empréstimos a esse cliente serão ressarcidos, e o cliente agora mais próximo do limite é conferido, e assim por diante. Se todos os empréstimos puderem ser ressarcidos por fim, o estado é seguro e a solicitação inicial pode ser concedida.
O algoritmo do banqueiro com múltiplos recursos
O algoritmo do banqueiro pode ser generalizado para lidar com múltiplos recursos. A figura “Múltiplos Recursos” mostra como isso funciona.
Na figura “Múltiplos Recursos” vemos duas matrizes. A primeira, à esquerda, mostra quanto de cada recurso está atualmente alocado para cada um dos cinco processos. A matriz à direita mostra de quantos recursos cada processo ainda precisa a fim de terminar. Como no caso do recurso único, os processos precisam declarar suas necessidades de recursos totais antes de executar, de maneira que o sistema possa calcular a matriz à direita a cada instante.

Os três vetores à direita da figura mostram os recursos existentes, E, os recursos possuídos, P, e os recursos disponíveis, A, respectivamente. A partir de E vemos que o sistema tem seis unidades de fita, três plotters, quatro impressoras e duas unidades de Blu-ray. Dessas, cinco unidades de fita, três plotters, duas impressoras e duas unidades de Blu-ray estão atualmente alocadas. Esse fato pode ser visto somando-se as entradas nas quatro colunas de recursos na matriz à esquerda. O vetor de recursos disponíveis é apenas a diferença entre o que o sistema tem e o que está atualmente sendo usado.
O algoritmo para verificar se um estado é seguro pode ser descrito agora.
- Procure por uma linha, R, cujas necessidades de recursos não atendidas sejam todas menores ou iguais a A. Se essa linha não existir, o sistema irá em algum momento chegar a um impasse, dado que nenhum processo pode executar até o fim (presumindo que os processos mantenham todos os recursos até sua saída).
- Presuma que o processo da linha escolhida solicita todos os recursos que ele precisa (o que é garantido que seja possível) e termina. Marque esse processo como concluído e adicione todos os seus recursos ao vetor A.
- Repita os passos 1 e 2 até que todos os processos estejam marcados como terminados (caso em que o estado inicial era seguro) ou nenhum processo cujas necessidades de recursos possam ser atendidas seja deixado (caso em que o sistema não era seguro).
Se vários processos são elegíveis para serem escolhidos no passo 1, não importa qual seja escolhido: o pool de recursos disponíveis ou fica maior, ou na pior das hipóteses, fica o mesmo.
Agora vamos voltar para o exemplo da figura “Múltiplos Recursos”. O estado atual é seguro. Suponha que o processo B faça agora uma solicitação para a impressora. Essa solicitação pode ser concedida porque o estado resultante ainda é seguro (o processo D pode terminar, e então os processos A ou E, seguidos pelo resto).
Agora imagine que após dar a B uma das duas impressoras restantes, E quer a última impressora. Conceder essa solicitação reduziria o vetor de recursos disponíveis para (1 0 0 0), o que leva a um impasse, portanto a solicitação de E deve ser negada por um tempo.
O algoritmo do banqueiro foi publicado pela primeira vez por Dijkstra em 1965. Desde então, quase todo livro sobre sistemas operacionais o descreveu detalhadamente. Inúmeros estudos foram escritos a respeito de vários de seus aspectos. Infelizmente, poucos autores tiveram a audácia de apontar que embora na teoria o algoritmo seja maravilhoso, na prática ele é essencialmente inútil, pois é raro que os processos saibam por antecipação quais serão suas necessidades máximas de recursos. Além disso, o número de processos não é fixo, mas dinamicamente variável, à medida que novos usuários se conectam e desconectam. Ademais, recursos que se acreditava estarem disponíveis podem subitamente desaparecer (unidades de fita podem quebrar). Desse modo, na prática, poucos — se algum — sistemas existentes usam o algoritmo do banqueiro para evitar impasses. Alguns sistemas, no entanto, usam heurísticas similares àquelas do algoritmo do banqueiro para evitar um impasse. Por exemplo, redes podem regular o tráfego quando a utilização do buffer atinge um nível mais alto do que, digamos, 70% — estimando que os 30% restantes serão suficientes para os usuários atuais completarem o seu serviço e retornarem seus recursos.
Prevenção de impasses
Tendo visto que evitar impasses é algo essencialmente impossível, pois isso exige informações a respeito de solicitações futuras, que não são conhecidas, como os sistemas reais os evitam? A resposta é voltar para as quatro condições colocadas por Coffman et al. (1971) para ver se elas podem fornecer uma pista. Se pudermos assegurar que pelo menos uma dessas condições jamais seja satisfeita, então os impasses serão estruturalmente impossíveis (HAVENDER, 1968).
Atacando a condição de exclusão mútua
Primeiro vamos atacar a condição da exclusão mútua. Se nunca acontecer de um recurso ser alocado exclusivamente para um único processo, jamais teremos impasses. Para dados, o método mais simples é tornar os dados somente para leitura, de maneira que os processos podem usá-los simultaneamente. No entanto, está igualmente claro que permitir que dois processos escrevam na impressora ao mesmo tempo levará ao caos. Utilizar a técnica de spooling na impressora, vários processos podem gerar saídas ao mesmo tempo. Nesse modelo, o único processo que realmente solicita a impressora física é o daemon de impressão. Dado que o daemon jamais solicita quaisquer outros recursos, podemos eliminar o impasse para a impressora.
Se o daemon estiver programado para começar a imprimir mesmo antes de toda a produção ter passado pelo spool, a impressora pode ficar ociosa se um processo de saída decidir esperar várias horas após o primeiro surto de saída. Por essa razão, daemons são normalmente programados para imprimir somente após o arquivo de saída completo estar disponível. No entanto, essa decisão em si poderia levar a um impasse. O que aconteceria se dois processos ainda não tivessem completado suas saídas, embora tivessem preenchido metade do espaço disponível de spool com suas saídas? Nesse caso, teríamos dois processos que haveriam terminado parte de sua saída, mas não toda, e não poderiam continuar. Nenhum processo será concluído, então teríamos um impasse no disco.
Mesmo assim, há um princípio de uma ideia aqui que é muitas vezes aplicável. Evitar alocar um recurso a não ser que seja absolutamente necessário, e tentar certificar-se de que o menor número possível de processos possa, realmente, requisitar o recurso.
Atacando a condição de posse e espera
A segunda das condições estabelecida por Coffman et al. parece ligeiramente mais promissora. Se pudermos evitar que processos que já possuem recursos esperem por mais recursos, poderemos eliminar os impasses. Uma maneira de atingir essa meta é exigir que todos os processos solicitem todos os seus recursos antes de iniciar a execução. Se tudo estiver disponível, o processo terá alocado para si o que ele precisar e pode então executar até o fim. Se um ou mais recursos estiverem ocupados, nada será alocado e o processo simplesmente esperará.
Um problema imediato com essa abordagem é que muitos processos não sabem de quantos recursos eles precisarão até começarem a executar. Na realidade, se soubessem, o algoritmo do banqueiro poderia ser usado. Outro problema é que os recursos não serão usados de maneira otimizada com essa abordagem. Tome como exemplo um processo que lê dados de uma fita de entrada, os analisa por uma hora e então escreve uma fita de saída, assim como imprime os resultados em um plotter. Se todos os resultados precisam ser solicitados antecipadamente, o processo emperrará a unidade de fita de saída e a plotter por uma hora.
Mesmo assim, alguns sistemas em lote de computadores de grande porte exigem que o usuário liste todos os recursos na primeira linha de cada tarefa. O sistema então prealoca todos os recursos imediatamente e não os libera até que eles não sejam mais necessários pela tarefa (ou no caso mais simples, até a tarefa ser concluída). Embora esse método coloque um fardo sobre o programador e desperdice recursos, ele evita impasses.
Uma maneira ligeiramente diferente de romper com a condição de posse e espera é exigir que um processo que solicita um recurso primeiro libere temporariamente todos os recursos atualmente em suas mãos. Então ele tenta, de uma só vez, conseguir todos os recursos de que precisa.
Atacando a condição de não preempção
Atacar a terceira condição (não preempção) também é uma possibilidade. Se a impressora foi alocada a um processo e ele está no meio da impressão de sua saída, tomar à força a impressora porque um plotter de que esse processo também necessita não está disponível é algo complicado na melhor das hipóteses e impossível no pior cenário. No entanto, alguns recursos podem ser virtualizados para essa situação. Promover o spooling da saída da impressora para o disco e permitir que apenas o daemon da impressora acesse a impressora real elimina impasses envolvendo a impressora, embora crie o potencial para um impasse sobre o espaço em disco. Com discos grandes, no entanto, ficar sem espaço em disco é algo improvável de acontecer.
Entretanto, nem todos os recursos podem ser virtualizados dessa forma. Por exemplo, registros em bancos de dados ou tabelas dentro do sistema operacional devem ser travados para serem usados e aí encontra-se o potencial para um impasse.
Atacando a condição da espera circular
Resta-nos apenas uma condição. A espera circular pode ser eliminada de várias maneiras. Uma delas é simplesmente ter uma regra dizendo que um processo tem o direito a apenas um único recurso de cada vez. Se ele precisar de um segundo recurso, precisa liberar o primeiro. Para um processo que precisa copiar um arquivo enorme de uma fita para uma impressora, essa restrição é inaceitável.
Outra maneira de se evitar uma espera circular é fornecer uma numeração global de todos os recursos, como mostrado na figura “Espera Circular”(a). Agora a regra é esta: processos podem solicitar recursos sempre que eles quiserem, mas todas as solicitações precisam ser feitas em ordem numérica. Um processo pode solicitar primeiro uma impressora e então uma unidade de fita, mas ele não pode solicitar primeiro um plotter e então uma impressora.
Com essa regra, o grafo de alocação de recursos jamais pode ter ciclos. Vamos examinar por que isso é verdade para o caso de dois processos, na figura “Espera Circular”(b). Só pode haver um impasse se A solicitar o recurso j, e B solicitar o recurso i. Presumindo que i e j são recursos distintos, eles terão números diferentes. Se i > j, então A não tem permissão para solicitar j porque este tem ordem menor do que a do recurso já obtido por A. Se i < j, então B não tem permissão para solicitar i porque este tem ordem menor do que a do recurso já obtido por B. De qualquer maneira, o impasse é impossível.

Com mais do que dois processos a mesma lógica se mantêm. A cada instante, um dos recursos alocados será o mais alto. O processo possuindo aquele recurso jamais pedirá por um recurso já alocado. Ele finalizará, ou, na pior das hipóteses, requisitará até mesmo recursos de ordens maiores, todos os quais disponíveis. Em consequência, ele finalizará e libertará seus recursos. Nesse ponto, algum outro processo possuirá o recurso de mais alta ordem e também poderá finalizar. Resumindo, existe um cenário no qual todos os processos finalizam, de maneira que não há impasse algum.
Uma variação menor desse algoritmo é abandonar a exigência de que os recursos sejam adquiridos em uma sequência estritamente crescente e meramente insistir que nenhum processo solicite um recurso de ordem mais baixa do que o recurso que ele já possui. Se um processo solicita inicialmente 9 e 10, e então libera os dois, ele está efetivamente começando tudo de novo, assim não há
razão para proibi-lo de agora solicitar o recurso 1.
Embora ordenar numericamente os recursos elimine o problema dos impasses, pode ser impossível encontrar uma ordem que satisfaça a todos. Quando os recursos incluem entradas da tabela de processos, espaço em disco para spooling, registros travados de bancos de dados e outros recursos abstratos, o número de recursos potenciais e usos diferentes pode ser tão grande que nenhuma ordem teria chance de funcionar.
Várias abordagens para a prevenção de impasses estão resumidas figura abaixo:
Fim da aula.