Sistemas Operacionais I - France Ricardo Marques Gonzaga - UNIGRAN

Aula 01

DEADLOCKS (IMPASSES)

Todos temos problemas, algum fceis de resolver outros nem tanto, mas muitas
vezes nos deparamos com problemas diante dos quais ficamos completamente estticos.
So aqueles problemas que, quando surgem, pensamos: se ficarmos parados no
resolvemos o problema e se agimos o problema tambm no resolvido ou at mesmo
pode piorar a nossa situao. Enfim, temos que encontrar alguma soluo ou ento
11
 Sistemas Operacionais I - France Ricardo Marques Gonzaga - UNIGRAN

todo um trabalho que foi desenvolvido at aquele ponto ser jogado ao vento e no
conseguimos ter um avano at alcanarmos o nosso objetivo.
Vamos imaginar uma situao,para a qual iro existir vrias solues, mas o
objetivo demonstrar o que pode ocorrer quando se tem um problema entre processos.
Imagine voc sendo proprietrio de uma transportadora de cargas e a sua empresa tem
uma entrega a cumprir. obvio que todos os seus custos foram calculados, tais como
despesas de combustvel, gastos com pneus e com automvel. O cliente aguarda a entrega
com muita ansiedade, contando os dias e as horas para a chegada de sua mercadoria;
na data e hora marcada a mercadoria sai do ponto origem e parte para o destino. Uma
situao inesperada acontece, uma ponte quebrada, ou uma parte do asfalto desmorona
e isso causa um enorme transtorno, voc j deve imaginar o que vai acontecer: a sua
entrega vai se atrasar, o prazo estabelecido no vai ser cumprido. At a tudo mais ou
menos normal na medida do possvel, vamos dizer que s no est normal porque a
entrega vai se atrasar.
O seu cliente est aguardando a entrega e percebe que o prazo j expirou, mas ele
no sabe o que aconteceu para que sua mercadoria no prazo estabelecido. Vamos observar
na gura 1 o que est ocasionando o atraso da entrega: o automvel da empresa saiu do
ponto de partida, mas cou preso no congestionamento que foi se formando em virtude do
problema como mencionado seja ele a queda de uma ponte ou o desmoronamento da estrada
ou qualquer outro problema que possamos imaginar. O automvel da empresa ca preso
no centro do congestionamento no podendo voltar e nem dar continuidade ao transporte
da carga. Imagine agora que o problema que houve no seja solucionado nos prximos
anos, isso faria seu cliente car em uma espera innita sem poder fazer atividade alguma
enquanto a sua mercadoria no chega, caminho da transportadora vai se deteriorar, ou
seja, acabar durante esse tempo. dessa forma que ocorrem os impasses ou deadloks,
vamos a um exemplo prtico dos processos: vamos supor que haja dois processos e esses
dois processos querem gravar em CD um documento obtido de um scanner. O processo X
faz a solicitao para usar o scanner e tem a autorizao. O processo Y, que programado
de uma maneira diferente, faz a solicitao de primeiro obter a permisso para usar o
gravador de CD e tambm obtm essa autorizao. Ento o processo X pede para usar
o gravador de CD, mas esta solicitao lhe negada at que o processo Y o libere. No
entanto, ao invs de liberar o gravador de CD, o processo Y pede para usar o scanner. Neste
instante os dois processos cam bloqueados e assim caro para sempre. A gura 1 ilustra
o que pode ocorrer em cidades, onde vrios automveis esto tentando transitar por uma
via, mas o trfego est totalmente engarrafado. claro que pode haver uma interveno,
como a de um policiamento, a m de resolver o problema i trfego e melhorar o trfego,
mas isso ainda causaria muito aborrecimento, esforo e perda de tempo.
12
Sistemas Operacionais I - France Ricardo Marques Gonzaga - UNIGRAN

Figura: 1

Ainda podem ocorrer impasses com mquinas em muitas empresas que tm redes
locais com vrios computadores interligados, muitos dispositivos com scanners, impressoras,
gravadores de CD que cam conectados a essas redes como recursos compartilhados, isto
, esses dispositivos cam disponveis a vrios usurios. A vem a questo: e se esses
dispositivos puderem ser reservados remotamente1? Isso pode ocasionar impasses assim
como aconteceu quando o processo Y fez a solicitao para primeiro obter a permisso para
utilizar o gravador.
Como os impasses podem ocorrer tanto em dispositivos de hardware como e
arquivos, para generalizarmos e assim car mais compreensvel o assunto sobre impasses
vamos referenciar os objetos acessados como recursos, ou seja, um recurso pode ser um
hardware (como por exemplo, uma impressora, um scanner) ou uma informao (por
exemplo, um arquivo, um registro de um banco de dados). Em um computador podemos
ter vrios tipos de recursos conectados como duas ou trs unidades de disco, duas ou
mais unidades de ta, assim vrios recursos idnticos podem estar disponveis e podemos
constatar que quando vrios isso ocorre, qualquer um deles pode ser usado para satisfazer
qualquer requisio daquele recurso. Um recurso um item que pode ser utilizado por
somente um nico processo em um dado instante do tempo.
Ainda falando em recursos, temos dois tipos deles que so, os recursos
preemptveis e os no preemptveis. Os primeiros preemptveis so recursos que podem
ser interrompidos e retirados da rea de uso sem ter qualquer perda ao sistema, ou seja sem
causar impasses. Um exemplo de recurso preemptivo a memria, pois quando um processo
parado e enviado para o disco como, por exemplo, na situao de termos um sistema com
64mb de memria disponvel para usurios, uma impressora e dois processos de 64mb que
queiram imprimir algum documento. O processo X requisita e obtm a impressora e ento
passa a computar os dados para impresso. Antes que ele nalize o seu processo, a sua fatia
de tempo de uso da CPU termina ele retirado da memria, ento entra em ao o processo
Y que agora est em execuo e tenta, mas no obtm nenhum xito em obter para si o uso
da impressora, pois ela j tinha sido requisitada pelo processo X. Estamos diante de uma
tpica situao de impasse: o processo X tem a impressora e o processo Y tem a memria,
assim nenhum deles consegue prosseguir sem o recurso mantido pelo outro, mas como

1
Remotamente: Computador ou rede de computadores a que se tem acesso por meio de linha de comunicao.
13
 Sistemas Operacionais I - France Ricardo Marques Gonzaga - UNIGRAN

estamos falando de um recurso preemptivo que a memria, pode-se enviar o processo Y

para o disco e depois carregar o processo X; com isso o processo X termina a sua execuo,
naliza a impresso e logo libera a impressora, isso torna os recursos livres para o processo
Y, no ocasionando nenhum impasse.
J com os recursos no preemptiveis, ao inverso dos preemptiveis, no h a
possibilidade do processo ser interrompido e depois de um tempo continuar a execuo, pois
caso isso ocorra pode ocasionar falhas, ou seja, impasses. Um exemplo clssico quando isso
pode ocorrer quando estamos gravando um CD: se um processo comeou a gravar um CD-
ROM e, de repente, retirar dele o gravador de CD e dar a um outro processo, isso ocasionar
uma falha e o resultado ser um CD com erros. Resumindo: gravadores de CD so recursos
que no podem ser tomados a qualquer instante, pois so recursos no preemptiveis. De
um forma geral os impasses envolvem recursos no preemptiveis, teoricamente temos um
sequncia de eventos necessrios ao uso de um determinado recurso. So eles.

1. Requisitar o recurso.
2. Usar o recurso.
3. Liberar o recurso.

Caso um processo requisite um recurso e esse recurso esteja ocupado no exato

momento em que ele foi requisitado, o que pode ocorrer que em alguns sistemas operacionais
o processo que solicitou forado a esperar. O processo ser automaticamente bloqueado
quando a requisio do recurso falhar, mas ser novamente chamado quando o recurso
se tornar livre. Em alguns sistemas a falha da requisio ir gerar um cdigo de erro, a
cabe ao processo solicitante esperar e tentar novamente mais tarde. Um processo que teve
a sua requisio negada poder permanecer em um loop2 e vai car requisitando o recurso
continuamente, depois vai parar e tentar novamente. De certo modo esse processo no est
bloqueado, mas como ele no poder realizar nenhum trabalho til, ento como se estivesse.
A forma real de como feita a solicitao do recurso totalmente dependente do
sistema. Em alguns sistemas utilizado uma chamada ao sistema do tipo request, a qual
permite que processos solicitem recursos. Em outros, os nicos recursos que o sistema
operacional reconhece so alguns arquivos que apenas um processo por vez pode abrir.
Caso o arquivo no momento estiver em uso, o processo bloqueado at que seja nalizado
pelo proprietrio atual.
Nos trs passos relacionados anteriormente, so seguidos por operaes como para
a aquisio do recurso (down) depois vem a utilizao do recurso e em seguida liberao
do recurso (up), cada recurso pode ser associado a um semforo. Veja os passos mostrados
na tabela 1 a seguir.
2
Loop: Tcnica de trabalho denominada laos de repetio, que tambm pode ser referenciada como malhas de repetio ou pelo termos
anlogos em ingls loopings ou loops.
14
Sistemas Operacionais I - France Ricardo Marques Gonzaga - UNIGRAN

Processo X Processo Y
type int semaphore; type int semaphore;
semaphore resource_1 semaphore resource_1;
void process_A(void){ semaphore resource_2;
down(&resource_1); void process_A(void) {
use_resource_1(); down(&resource_1);
up(&resource_1); down(&resource_2);
} use_both_resources();
up(&resource_2);
Up (resource_1);
}
Tabela 1
Sistemas Operacionais Modernos-2 Ed, Andrew S. Tanenbaum- p. 119

Temos dois processos X e Y, onde utilizado o semforo para proteger

recursos, o processo X com um recurso e processo Y com dois recursos. Em alguns
momentos h processos que necessitam de mais de um recurso e, nesse caso, os recursos,
so adquiridos sequencialmente, como mostra o exemplo do processo Y: quando houver
a necessidade de mais de um recurso eles sero adquiridos um aps o outro. Bom, por
enquanto est tudo na normalidade, nada de extraordinrio aconteceu, ou seja, at aqui
estamos apenas acompanhando um processo e esse processo tem acesso a recursos sem
maiores transtornos, no h a concorrncia entre processos pois estamos acompanhando
o acesso a recursos com apenas um processo.
Agora vamos imaginar uma situao com dois processos e dois recursos, em que,
em uma das situaes os dois processos solicitam os recursos na mesma ordem e na outra
os processos solicitam os recursos em ordem diferente. Essa diferena pode at parecer
sem importncia, mas devemos pensar totalmente ao contrrio.
Em um dos exemplos que se seguem um dos processos vai adquirir o primeiro
recurso antes do outro. Com isso esse processo ter sucesso na aquisio do segundo
recurso e assim ter xito em seu trabalho. Se o outro processo tentar adquirir o recurso 1
antes de ser liberado, por uma definio clara esse processo ser bloqueado at o recurso
1 ser liberado.
No outro processo o caso muda isso porque pode ocorrer que, um dos processo
adquira os dois recursos e nesse caso o outro processo bloqueado, at que seu trabalho
finalize. Existe ento a possibilidade de um deles ficar bloqueado quando tentar adquirir o
outro recurso. Assim nenhum dos processos poder continuar o seu trabalho ocasionando
um impasse. Observe o exemplo da tabela 2 que se segue:
15
 Sistemas Operacionais I - France Ricardo Marques Gonzaga - UNIGRAN

Typedef int semaphore; semaphore resource_1;

semaphore resource_1; semaphore resource_2;
semaphore resource_2; void process_A(void) {
void process_A(void) { down(&resource_1);
down(&resource_1); down(&resource_2);
down(&resource_2); use_both_resources();
use_both_resources(); up(&resource_2);
up(&resource_2); up(&resource_1);
up(&resource_1); }
} void process_B(void) {
void process_B(void) { down(&resource_2);
down(&resource_1); down(&resource_1);
down(&resource_2); use_both_resources();
use_both_resources(); up(&resource_1);
up(&resource_2); up(&resource_2);
up(&resource_1); }
}
Tabela 2
Sistemas Operacionais Modernos-2 Ed, Andrew S. Tanenbaum- p. 119

Temos nos exemplos acima, um processo livre de impasse e um processo com a possibilidade
de impasse. Podemos vericar que em uma simples diferena de programao em que denido qual
recurso ser adquirido primeiro tem a nalidade de demonstrar se o programa vai funcionar ou no.
uma difcil misso a de detectar qual programa vai funcionar, pois os programas so muito semelhantes,
a nica diferena realmente palpvel qual processo vai adquirir o recurso primeiro.
Podemos dizer que impasses so situaes em que um processo espera por um recurso que
nunca estar disponvel, ou seja, um evento que nunca ocorrer. Um processo em situao de impasse
encontra-se espera de um recurso que est sendo usado por um outro processo tambm em situao de
impasse, um processo no pode continuar o seu trabalho e o outro processo no pode liberar qualquer
recurso. Veja a gura 2 em que os processos se encontram em situao de impasse.
Processo A Processo A Recurso 1
solicita o alocado ao

*
Recurso 2 Processo A

Recurso 2 Recurso 1

Processo B

Recurso 2
alocado ao
Processo B * Processo B
solicita o
Recurso 1

Figura: 2
16
Sistemas Operacionais I - France Ricardo Marques Gonzaga - UNIGRAN

Situaes de impasses ocorrem, na maioria das vezes, por consequncia do

compartilhamento de recursos entre processos concorrentes em que a excluso mtua e exigida.

EXCLUSO MTUA

Excluso mtua a soluo mais simples para evitar impasses. A inteno impedir
que dois ou mais processos acessem um mesmo recurso ao mesmo tempo. A excluso
mtua faz com que enquanto um processo acessa um recurso, todos os outros processos
que queiram acess-lo devam esperar pelo trmino de sua utilizao. A idia de que h uma
exclusividade de acesso que chamada de excluso mtua (mutual exclusion).
O mtodo de excluso mtua tem o dever de afetar somente os processos
concorrentes quando tais processos estiverem fazendo acesso ao recurso compartilhado.
Essa parte do cdigo do programa onde feito o acesso ao recurso compartilhado chamado
de regio crtica (critical region). Por isso podemos armar que se for garantida a execuo
mutuamente exclusiva da regio crtica, os problemas causados por compartilhamentos
sero evitados. Uma das solues a utilizao de um protocolo de acesso a regies
criticas. Todas as vezes que um processo for executar em sua regio crtica, um protocolo
de entrada dever ser antes executado nessa regio e isso tambm vale quando for sair da
regio crtica.
Esses protocolos de entrada e de sada garantem a excluso mtua da regio crtica de um
programa e uma das solues mais simples de excluso mtua a de desabilitar as interrupes.
O procedimento simples: o processo desabilita todas as interrupes antes de
entrar na rea crtica do programa e ao sair da rea critica, ele as habilita. Com isso o
processo que habilitou as interrupes ter acesso exclusivo garantido.
A soluo de desabilitar e habilitar as interrupes pode apresentar algumas
limitaes, primeiramente a multiprogramao caria seriamente comprometida, pois a
concorrncia entre processos tem como base o uso de interrupes. Um problema muito
grave que pode ocorrer e o de um processo desabilitar as interrupes e no tornar a habilit-
las. Nesse caso e bem provvel que o seu funcionamento ser comprometido.
Podemos notar que, em sistemas com mltiplos processadores, essa soluo no
e eciente por conta do tempo de propagao quando um processador sinaliza aos demais
que as interrupes devem ser habilitadas ou desabilitadas. Mas, por outro lado, essa
soluo pode se tornar bastante til, quando se pretende que a execuo de parte do ncleo
do sistema operacional seja utilizada sem que tenha interrupo.
Dessa maneira o sistema tem a garantia de que no ocorrero problemas de
inconsistncia ao executar algumas rotinas.
Em alguns processadores existe uma instruo de mquina especial que permite ler uma
varivel, armazenar o seu contedo em outra rea e atribuir um novo valor mesma varivel.
(Pg. 108 Sistemas Operacionais Modernos, Francis Berenger Machado e Luiz Paulo Maia)
17
 Sistemas Operacionais I - France Ricardo Marques Gonzaga - UNIGRAN

Essa instruo chamada de test-and-set. A instruo tem como principal

funcionalidade o fato de ser executada sem interrupo, ou seja, trata-se de uma instruo
indivisvel, com isso pode-se garantir que dois processos no manipulem uma varivel
compartilhada ao mesmo tempo.

CONDIES PARA EXISTIR DEADLOCK

Coffman, Elphick e Shoshani provaram que as quatro condies seguintes so

necessrias para existir deadlock:

1. Um recurso (impressora, arquivo) pode ser requisitado com exclusividade por

um nico processo por vez (condio de excluso mtua).
2. Um processo que obteve um recurso exclusivo pode reter esse recurso enquanto
espera para obter outros recursos (condio de espera, tambm denominada condio de
posse e espera).
3. Uma vez que o processo obtenha um recurso (condio de no preempo).
4. Dois ou mais processos cam travados em uma cadeia circular na qual
cada processo est esperando por um ou mais recursos que o processo seguinte da cadeia
(condio de espera circular).

Sistemas Operacionais: terceira edio/H.M.Deitel, P.J. Deitel, D.R. Choffnes;

Ed.Pearson Prentice Hall, 2005; So Paulo.

Assim como h condies para existncia de impasses, foram desenvolvidas

tambm condies para se evitar os impasses. Vamos analisar algumas das principais
condies para a preveno, deteco e correo de deadlocks.

1. Se houver impasses, voc pode simplesmente ignor-lo, pois pode ser que com
essa atitude talvez o impasse ignore voc.
2. Preveno de Deadlock.
3. Deteco do Deadlock.
4. Correo do Deadlock.

ALGORITMO DO AVESTRUZ

A estratgia muito simples, ena a cabea na terra e nge que no tem problema
algum. Existem pessoas que reagem a essa estratgia de formas muito diferentes. Os
matemticos acham isso um absurdo inaceitvel, pois eles dizem que os impasses devem
ser evitados a qualquer custo. J os engenheiros perguntam com que frequncia o problema
18
Sistemas Operacionais I - France Ricardo Marques Gonzaga - UNIGRAN

esperado, com que frequncia o sistema falha por outros motivos e qual a gravidade
do impasse. Se os impasses ocorrerem em longos espaos de tempo devido a algumas
falhas ocasionadas por hardware, erros de compilador e erros dos sistemas operacionais
se ocorrerem uma vez por semana, a maioria dos engenheiros penalizar fortemente o
desempenho ou a convenincia para eliminar os impasses.

PREVENO DE DEADLOCK

Para a prevenir a ocorrncia de deadlocks necessrio ter a certeza de que uma das quatro
condies mostradas anteriormente, que so necessrias para a sua existncia, nunca ocorra.
Se no houvesse a primeira condio (excluso mtua), com toda certeza seria eliminado o
problema de deadlock porque, com a sua ausncia, nenhum processo precisaria esperar para ter acesso
a qualquer recurso, mesmo que o recurso estivesse sendo usado por algum outro processo.
J na condio de espera, que tambm e conhecida por condio de posse e espera,
processos que j tem recursos garantidos no podem requisitar novos recursos. Uma das formas de
se implementar isso , antes do incio da execuo, fazer com que um processo deva pr-requisitar os
recursos necessrios. Com isso todos os recursos necessrios para a execuo devem estar disponveis
para o incio da execuo, pois algum dos recursos no estiver disponvel para o andamento, a operao
volta ao incio nenhum recurso alocado e o processo permanecer aguardando.
A outra condio, a de no preempo, poder ser evitada quando permitido que um recurso
seja retirado de um processo no caso de algum outro processo necessitar do mesmo recurso que est
sendo usado pelo atual processo.
A ltima condio, a de espera circular, para evitar um deadlock a sua excluso. Uma
forma de sua implementao forar o processo a ter apenas um recurso de cada vez, no caso do
processo precisar de outro recurso, o recurso que j estiver sendo usado ele deve ser liberado.
Prevenir deadlocks no deixando que ocorra qualquer uma das quatro condies apontadas
por Coffman, Elphick e Shoshani a preveno de deadlock torna-se bastante limitada e, por isso, no
utilizada na prtica. Podemos armar que possvel evitar o deadlock mesmo que todas as condies
necessrias sua ocorrncia estejam presentes.
A soluo mais conhecida para essa situao o algoritmo do banqueiro (Bankes
Algorithm) proposto por Dijkstra (1965). Esse algoritmo basicamente faz com que seja
exigido que os processos informem o nmero mximo de cada tipo de recurso necessrio
para sua execuo. uma boa maneira para evitar deadlock, mas possui vrias limitaes. A
maior delas a necessidade de um nmero xo de processos ativos e de recursos disponveis
no sistema. Essa limitao faz com que a soluo no seja implementada na prtica porque
muito difcil prever o nmero de usurios e o nmero de recursos disponveis.

DETECO DE DEADLOCKS

Em alguns sistemas no existe o mecanismo de preveno de deadlocks, ento

necessrio um esquema de deteco e correo de deadlocks. Deteco de deadlocks
19
 Sistemas Operacionais I - France Ricardo Marques Gonzaga - UNIGRAN

o mecanismo que reconhece uma situao de deadlocks, assim permitindo identicar os

recursos e processos envolvidos.
Na deteco de deadlocks necessria uma estrutura de dados capaz de identicar
cada recurso do sistema, principalmente o processo que est sendo usado e os processos que
esto espera da liberao do recurso. Toda vez que um recurso requisitado ou estiver
em uso, essa estrutura de ser atualizada. Em geral, os algoritmos que implementam esse
mecanismo vericam a existncia da espera circular, percorrendo toda a estrutura sempre
que um processo solicita um recurso e ele no pode ser imediatamente garantido para o uso.

CORREO DO DEADLOCK

Depois de detectar o deadlock, o sistema operacional ter de alguma forma corrigir

o problema encontrado. Na maioria dos sistemas a forma encontrada muito simples: ele
elimina um ou mais processos envolvidos no deadlock e desloca os recursos j garantidos
por eles, quebrando a espera circular.
Essa eliminao no to simples quanto parece, pois depende do tipo do recurso
envolvido. Se um processo estiver atualizando um arquivo ou imprimindo um relatrio, o
sistema deve garantir que esses recursos sejam liberados sem causar nenhum problema. Os
processos eliminados no podero ser recuperados, mas outros processos que estavam em
deadlock, esses podero prosseguir a execuo.
A escolha de qual processo deve ser eliminada normalmente feita de forma
aleatria ou ento com base em algum tipo de prioridade.

ATIVIDADES
As atividades referentes a esta aula esto disponibilizadas na ferramenta Atividades.
Aps respond-las, envie-nas por meio do Portflio- ferramenta do ambiente de aprendizagem
UNIGRANET. Em caso de dvidas, utilize as ferramentas apropriadas para se comunicar com
o professor.

20