DeadlockPraça, E. A.

elaineap@gmail.comSabo, P. H.

phsabo@gmail.com

Universidade Estadual de Maringá (DIN-UEM)Avevida Colombo, 5790 – Bloco C56 – 87020-900 – Maringá – PR – BRASIL

+554430114345

RESUMOUm processo é dito em deadlock quando está esperando por um evento que nunca ocorrerá. Essa situação é conseqüência do compartilhamento de recursos do sistema entre vários processos, sendo que cada processo deve ter acesso ao recurso de forma exclusiva (exclusão mútua). O problema de deadlock existe em qualquer sistema multiprogramável; no entanto, as soluções implementadas devem considerar o tipo do sistema e o impacto em seu desempenho. Para ocorrer um deadlock é necessário que ocorra: Exclusão Mútua, Evitar que os processos que já possuam recursos garantidos requisitem novos recursos, também evitaremos o problema do deadlock, Permitir que um recurso seja retirado de um processo quando outro processo necessitar do mesmo recurso, Forçar o processo a ter apenas um recurso de cada vez. Os sistemas operacionais para detectar deadlocks, devem manter estruturas de dados capazes de identificar cada recurso do sistema, o processo que o está alocando e os processos que estão na espera da liberação do recurso. Toda vez que um recurso é alocado ou liberado por um processo, a estrutura deve ser atualizada. Dependendo do tipo de sistema, o ciclo de busca por um deadlock varia. Em sistemas com time sharing, o tempo de busca pode ser maior, sem comprometer o desempenho e a confiabilidade do sistema. Já em sistemas de tempo real devem constantemente certificar-se da ocorrência de deadlocks, porém essa maior segurança gera mais processamento no sistema. Uma solução bastante utilizada na maioria dos SOs é eliminar os processos envolvidos no deadlock e desalocar os recursos já garantidos por eles, quebrando assim a espera circular. Deadlocks não é um problema específico de sistemas operacionais, aqui mostramos a ocorrência deles em redes intra chip e uma possível solução.

Palavras-chaveDeadlock, Sistemas Operacionais, Redes Intra Chip.

ABSTRACTA process is a deadlock when waiting for an event that never occurs. This situation is a result of sharing system resources among multiple processes, each process must have access to feature an exclusive (mutex). The problem of deadlock exists in any multiprogram system, however, the solutions implemented should consider the type of system and impact on their performance. To experience a deadlock needs to take place: Mutual Exclusion, Prevent the processes that have

already secured funding to order new resources, you will avoid the problem of deadlock, allow an action to be taken from one process when another process needs the same resource, Force the process to have only one resource at a time. Operating systems to detect deadlocks must maintain data structures able to identify each system resource, the process that is allocating and processes that are waiting to release the resource. Whenever a resource is allocated or released by a process, the structure must be updated. Depending on the type of system, the cycle of searching for a deadlock varies. In systems with time sharing, the search time can be increased without compromising performance and reliability. Back in real-time systems must constantly check the occurrence of deadlocks, but this increased security creates more processing in the system. One solution often used in most OS’s is to eliminate the processes involved in the deadlock and deallocate the resources already secured for them, thus breaking the circular wait. Deadlock is not a problem specific to operating systems, here we show the occurrence of them in intra-chip networks and a possible solution.

KeywordsDeadlocks, Operating Systems, Network on Chip.

1. INTRODUÇÃODeadlock são situações indesejáveis, onde os processos nunca terminam sua execução e os recursos do sistema ficam comprometidos, impedindo que outros jobs iniciam. Ele é uma falha e não um erro do Sistema Operacional e ocorre quando mais de um processo requer um determinado recurso ao mesmo tempo.

O deadlock cria uma situação em que um ou mais processos nunca correrão para conclusão sem recuperação.

Para Dijkstra (1968) deadlock é definido como: "Efeito colateral de estratégias de sincronização, porque dois processos ao atualizar duas variáveis compartilhadas, usam uma lock flag, um para requisitar valores de uma variável, o outro para atualizar valor da variável".

Embora deadlocks possam ocorrer em diversos pontos de um sistema operacional, eles são um dos principais problemas dos programas concorrentes.

Situações semelhantes ocorrem periodicamente num conjunto de processos que estão a compartilhar recursos. Memória, os

drives de uma impressora, um drive de disquetes são todos exemplos de recursos. Um processo pode bloquear quando é pedido qualquer um desses recursos e os mesmos já estão ocupados, assim qualquer um pode contribuir para entrar na situação deadlock.

E não ocorrem apenas em sistemas operacionais, redes intra chip, também apresentam este problema, levando o problema para o meio físico de comunicação.

2. DEFINIÇÃOSegundo Tanenbaum, deadlock pode ser formalmente definido como: "Um conjunto de processos estará em situação de deadlock se todo processo pertencente ao conjunto estiver esperando por um evento que somente um outro processo desse mesmo conjunto poderá fazer acontecer".

Podemos citar como exemplo de situação de deadlock, não relacionado a computação, mas que facilita o entendimento do que seja uma situação de deadlock, dois carros seguindo em direção oposta numa pista que permite apenas a passagem de um veículo. Nesse caso os dois ficam impedidos de continuar seu percurso.

Um deadlock, em computação, ocorre normalmente com recursos como dispositivos, arquivos, memória, entre outros.

Na figura 1 ilustramos graficamente uma situação de deadlock, onde o processo P5 está bloqueado à espera do recurso R3. Entretanto, ele não está em deadlock, pois o processo P2 não está bloqueado. Ele pode executar até o fim, liberar o recurso R3, e então o processo P5 poderá executar. O mesmo não ocorre com os processos P1, P3 e P4. O processo P4 está bloqueado à espera do recurso R2, ocupado pelo processo P1. Os processos P1 e P3 estão bloqueados à espera do recurso R1, ocupado pelo processo P4. Logo, P1, P3 e P4 estão em deadlock.

Figura 1: Representação de processos e recursos

Existem quatro condições para que possa ter uma ocorrência de deadlock. São elas:

Condição de exclusão mutua – pelo menos um recurso deverá ser mantido em modo não-compartilhado; ou seja, apenas um processo de cada vez pode usar esse recurso. Se outro processo solicitar esse recurso, o processo solicitante deverá ser retardado até que o recurso tenha sido liberado.

Condição de posse e espera – deve haver um processo que esteja mantendo pelo menos um recurso e esteja esperando para obter recursos adicionais que estejam sendo mantidos por outros processos no momento.

Condição de não preempção – os recursos não podem sofrer preempção; ou seja, um recurso só pode ser liberado voluntariamente pelo processo que o mantém, depois que esse processo tiver completado sua tarefa.

Condição de espera circular – deve haver um conjunto {P0, P1, ..., Pn} de processos em espera, de modo que P0 esteja esperando pó um recurso que é mantido por P1, P1 esteja esperando por um recurso que é mantido por P2 ... Pn-1, esteja esperando por um recurso que é mantido por Pn e Pn esteja esperando por um recurso que é mantido por P0.

Todas estas condições devem estar presentes para que ocorra um deadlock. Se alguma delas falhar, será garantida a não ocorrência de um deadlock.

3. ALGORITMO DO AVESTRUZA estratégia mais simples para lidar com o deadlock é a mesma da avestruz frente a um perigo: colocar a cabeça em um buraco na areia e fingir que o problema não existe.

Apesar de teoricamente inaceitável, esta solução é a mais utilizada devido aos seguintes fatores:

(i) baixa probabilidade de ocorrência de deadlock, muito menor do que da ocorrência de quebra do sistema por erros no próprio S.O., em compiladores ou no hardware;

(ii) o alto preço pago pelos usuários para se prevenir os deadlocks.

O UNIX utiliza este método.

4. ESTRATÉGIAS PARA TRATAR O DEADLOCKAs situações de deadlock podem ser tratadas ou não em um sistema, os desenvolvedores devem avaliar o custo/benefício que essas implementações podem trazer.

Normalmente, as estratégias usadas para detectar e tratar as situações de deadlocks, geram grande sobrecarga, podendo até causar um dano maior que a própria ocorrência do deadlock, sendo, às vezes, melhor ignorar a situação.

Então basicamente podemos definir três métodos distintos para tratar os problemas dos deadlocks:

(i) podemos usar um protocolo para garantir que o sistema nunca entre em deadlock;

(ii) podemos permitir que o sistema entre em deadlock e em seguida se recupere;

(iii) podemos ignorar o problema e fingir que os deadlocks nunca ocorrem no sistema;

(iv) podemos prevenir a ocorrência de deadlock negando o surgimento de uma das quatro condições necessárias para gerar um deadlock.

Sendo assim, temos três estratégias para tratamento de deadlocks: Detecção e Recuperação, Evitar Deadlock e Prevenção.

4.1 Detectar e Recuperar deadlocksO sistema permite que ocorra o deadlock e depois executa o procedimento de recuperação, que se resume na detecção da ocorrência e na recuperação posterior do sistema.

Para detecção do deadlock, deve-se implementar no sistema uma estrutura de dados que armazene as informações sobre os processos e os recursos alocados a eles e essas reflitam a situação de cada processo/recurso no sistema. Porém, é importante ressaltar que o simples procedimento de atualização dessas estruturas gera sobrecarga no sistema, pois toda vez que o processo aloca, libera ou requisita um recurso, elas precisam ser atualizadas.

Algumas das técnicas de detecção utilizadas são:

4.1.1 Detecção de deadlocks com um recurso de cada tipoSe tem apenas um recurso de cada tipo (somente uma impressora, um drive de CD, um drive de disquete). Existe um algoritmo para detectar se existem ciclos no grafo dos processos e recursos, sendo que na presença de qualquer processo que faça parte de um ciclo está em situação de deadlock.

Figura 2: (a) grafo de recurso; (b) ciclo extraído do grafo de recurso

4.1.2 Detecção de deadlocks com múltiplos recursos de cada tipoO algoritmo baseia-se em um ambiente que possui vários recursos do mesmo tipo e os processos solicitam apenas pelo tipo de recursos, não especificando qual recurso desejam utilizar.

Uma vez que o algoritmo de detecção de deadlocks é bem sucedido, o que se fará em seguida é a recuperação do sistema da situação de deadlock e colocá-lo novamente em condição de funcionamento normal.

As técnicas utilizadas para recuperação são:

4.1.3 Recuperação por meio de preempçãoRetirar o recurso de um processo e dá-lo a outro sem que o processo proprietário do recurso perceba a falta do mesmo. No entanto esta estratégia é muito dependente da natureza do recurso, pois alguns recursos tornam esta operação muito difícil ou até mesmo impossível. A escolha do processo que será suspenso depende amplamente de quais processos tem recursos passíveis de serem facilmente retomados sem serem prejudicados.

4.1.4 Recuperação por meio de reversão de estadoO sistema operacional, ao longo da execução dos processos vai guardando imagens dos estados do processo, para que fique como que um posto de fiscalização do processo. Não guarda apenas os estados dos processos, como guarda

também os recursos associados ao processo no momento em que é criado o posto de fiscalização. O sistema não sobrepõe um posto de fiscalização novo a um já guardado anteriormente. Ele cria sempre uma imagem nova. Depois que o algoritmo de detecção de deadlocks detecta um deadlock os processos incluídos no deadlock voltam a estados anteriores.

4.1.5 Recuperação por meio de eliminação de processosA maneira mais grosseira, mas também a mais simples é matar um ou mais processos envolvidos no deadlock. Com um pouco de sorte os outros processos poderão ser capazes de prosseguir.

De preferência deve ser eliminado um processo que seja capaz de ser re-executado desde seu início de forma a evitar efeitos indesejáveis e inconsistências no sistema.

Por exemplo, processos de atualização de banco de dados nem sempre é passível de ser executado com segurança uma segunda vez, devido a possíveis inconsistências de registro na base de dados.

4.2 Evitar deadlocksO deadlock pode ser evitado, mas só quando certas informações estiverem disponíveis.

O Sistema Operacional que adota esta estratégia, procura evitar a ocorrência de deadlocks por meio de alocação cuidadosa de recursos. O sistema deve ser capaz de saber e decidir se liberar um recurso é seguro ou não.

O sistema deve ser capaz de decidir se liberar um recurso é seguro ou não e somente fazer uma alocação quando ela for segura. Um algoritmo hipotético que faça uma escolha para evitar deadlocks, seria somente alocando recursos quando certas informações estiverem disponíveis antecipadamente.

Abordaremos a seguir alguns processos que objetivam evitar deadlocks.

4.2.1 Trajetória dos recursos

Figura 3:. Trajetória dos recursos de dois processos.

Algo importante a ser visto neste exemplo ilustrado na figura 3, é o ponto t, onde B estará requisitando um recurso. O sistema deve decidir se lhe dá o direito de uso ou não. Se o direito de uso for concedido, o sistema entrará em uma região insegura e acabará por entrar em deadlock. Para evitar o deadlock, B deverá ser suspenso até A requisitar e liberar o plotter.

4.2.2 Estados seguros e não segurosÉ considerado um estado seguros e ele não está em situação de deadlock e se existe alguma ordem de escalonamento na qual todo o processo possa ser executado até sua conclusão, mesmo se de repente, todos eles requisitarem, de uma só vez, o máximo possível de recursos. Um estado não seguro não é uma situação de deadlock. É um estado em que a partir do mesmo, o sistema não pode dar a garantia de que o processo vai acabar.

4.2.3 Algoritmo de banqueiro Usado para determinar se um processo pode executar de maneira segura ou não. Todos os processos declaram o máximo de recursos que vão usar durante a execução. A execução é permitida se a soma dos recursos requisitados é menor que os recursos disponíveis no sistema. O algoritmo verifica se a liberação de uma requisição pode levar a um estado não seguro. Em caso positivo, a requisição é negada. Se a liberação de uma requisição levar a um estado seguro, então ela é atendida.

Evitar deadlocks é, em sua essência, impossível, pois como já dito, requer informações sobre pedidos futuros.

4.3 Prevenção de DeadlockComo já visto, evitar deadlock é praticamente impossível. Por isso, a prevenção de deadlock tenta garantir que pelo menos uma das condições para ocorrência de deadlock não aconteça.

Sabendo que são quatro as condições para que possa ocorrer uma situação de deadlock simultaneamente, a prevenção procura eliminar pelo menos uma delas utilizando as seguintes técnicas:

(i) Condição de exclusão mútua – pode-se usar a técnica de spooling, onde vários processos poderão gerar suas saídas ao mesmo tempo. No entanto, nem todos os dispositivos podem fazer uso de spool.

(ii) Condição de posse e espera – Os processos devem pedir os recursos antes de iniciarem a sua execução. Um problema é que muitos processos só sabem quais são os recursos vão precisar após serem inicializados e executados.

(iii) Condição de não preempção – Se um processo tiver a posse de um dispositivo e estiver no meio do seu uso, uma vez preemptado por um segundo processo, o ato de retornar a posse do dispositivo ao primeiro processo, é complicado na melhor das hipóteses e impossível na pior delas.

(iv) Condição de espera circular – Uma maneira de evitar é fornecer uma numeração global de todos os recursos. Processos podem requisitar recursos sempre que necessário, mas todas essas solicitações devem ser feitas em ordem numérica. O processo pode requisitar o recurso R1 e em seguida o recurso R2 mas se estiver de posse de R2 e quiser requisitar o R1, deve antes liberar o R2 para só após requisitar o recurso R1.

Estas estratégias são fáceis de implementar em certos sistemas, porém a avaliação de custo/benefício deve ser levada em consideração.

5. CANAIS VIRTUAIS E SEU USO NO PROBLEBA DE DEADLOCKS EM REDES INTRA CHIPNas redes diretas, cada nodo de chaveamento possui um nodo de processamento associado, e esse par pode ser visto como um elemento único dentro do sistema, tipicamente referenciado pela palavra nodo. Nas redes indiretas os nodos de processamento possuem uma interface para uma rede de nodos de chaveamento. Somente alguns nodos de chaveamento possuem conexões para nodos de processamento e apenas esses podem servir de fonte ou destino de uma mensagem.

As redes de interconexão são compostas por: nodos de chaveamento e canais físicos. Em geral, cada nodo de chaveamento em uma rede de interconexão possui um conjunto de buffers e um crossbar. Para cada canal físico, há um buffer de entrada associado, o qual armazena os flits recebidos para que depois os mesmos sejam posteriormente enviados. Enquanto um pacote A tem um buffer alocado, nenhum outro pacote poderá utilizar o canal a ele associado até que o pacote A o libere. Se o pacote A ficar bloqueado na rede enquanto ocupa o buffer, o canal associado fica ocupado e nenhum outro pacote pode usá-lo.

Canais virtuais dissociam a alocação de um único buffer por canal físico, dividindo-o em vários canais virtuais, proporcionando assim a associação de vários buffers para cada canal físico. Se um pacote A aloca um buffer associado a um canal virtual, outro pacote pode alocar um outro buffer associado a outro canal virtual do mesmo canal físico. A Figura 4 ilustra a adição de dois canais virtuais para cada canal físico à rede de interconexão. Enquanto o pacote A é transmitido por um dos canais virtuais do canal físico N, o pacote B pode ser transmitido pelo outro canal virtual do mesmo canal físico.

Adicionar canais virtuais a uma rede de interconexão é análogo a adicionar pistas (lanes) em uma estrada. Uma rede sem canais virtuais é formada por estradas de uma só pista. Nesse tipo de rede, um pacote bloqueado ocupando um canal bloqueia todos os demais pacotes que precisam desse canal. Adicionando canais virtuais diminui-se o número de pacotes bloqueados, ou seja, reduz-se o congestionamento na rede.

Figura 4 - Canais físicos divididos em canais virtuais.

Os canais virtuais foram apresentados pela primeira vez, com o intuito de prevenir deadlocks que podem ocorrer em redes que utilizam chaveamento wormhole e roteamento adaptativo. O deadlock ocorre quando existe uma dependência cíclica de recursos na rede. A Figura 5 mostra parte de uma rede de interconexão com quatro roteadores (1, 2, 3 e 4) possuindo cada um quatro portas bidirecionais (N, S, E, e W) conectadas a um núcleo crossbar. Cada um dos roteadores tem um pacote a ser transmitido.

• O roteador 1 tem um pacote A que tem como destino o roteador 4.

• O roteador 2 tem um pacote B que tem como destino o roteador 3.

• O roteador 3 tem um pacote C que tem como destino o roteador 2.

• O roteador 4 tem um pacote D que tem como destino o roteador 1.

Figura 5 – Dependência cíclica que origina o deadlock.

A dependência cíclica ocorre porque existem quatro pacotes sendo transmitidos simultaneamente na rede, e cada um dos pacotes utiliza um canal que é requisitado por outro pacote para que este último atinja seu destino. Por exemplo, os flits do pacote A começam a ser transmitidos para o roteador 2 pela porta de saída E. Chegando no roteador 2 pela porta de entrada W, o pacote requisita a porta de saída S para chegar ao seu destino (roteador 4), porém esta porta já está em uso pelo pacote B. O mesmo ocorre com os demais pacotes que estão sendo transmitidos, fechando o ciclo, dando origem ao deadlock.

A solução para o problema apresentado na Figura 5 pode ser obtida dividindo cada um dos canais físicos em dois canais virtuais, quebrando assim a dependência cíclica, como ilustra a Figura 6. Retomando o exemplo do pacote A, assim que seus flits chegam pela porta de entrada W do roteador 2, ele requisita a porta de saída S. Essa porta já está com um dos canais virtuais ocupado pelo pacote B, porém, o outro canal virtual esta disponível, logo o pacote A passa a utilizá-lo para atingir seu destino.

Figura 6 – Quebrando a dependência cíclica com o uso de canais virtuais.

6. PROPOSTAGarantir que um processo não requisite recursos quando já tem outros recursos em seu poder. Isso pode ser feito, exigindo que todos os recursos de que o processo precisa sejam requeridos no início do seu processamento, ou no início de uma fase dele, quando o processo está sem recurso algum em seu poder. Silberschatz (2000) ilustra a diferença entre esses dois protocolos com um exemplo envolvendo arquivo a ser classificado, drive de fita e uma impressora. Ele conclui que requisitar todos os recursos no início do processamento pode acarretar baixa performance no sistema, pelo fato de recursos serem alocados a um processo e não serem usados durante um grande intervalo de tempo. Além disso, apresenta um problema para o que Tanenbaum (2003) expõe como solução: teria de ser possível garantir que um recurso não fosse inutilizado para o uso do processo no intervalo entre sua liberação (em uma fase) e sua realocação para o mesmo processo (em outra fase). Outro problema seria a possibilidade de preterição indefinida de um processo que requisitasse recursos muito requisitados.

Nossa proposta seria também um sistema operacional onde todo processo, ao iniciar sua execução, informaria ao uma lista de todos os recursos que poderá usar, mas, uma lista ordenada crescente, do primeiro processo que será requisitado até o ultimo.

Fazendo isso o SO não precisa dar ao processo todos os recursos de uma só vez, acarretando em baixo desempenho. O sistema pode liberar os recursos conforme o processo for requisitando, mas sabendo quais os próximos recursos que serão requisitados, o SO pode usar algum tipo de política para

gerenciar esses recursos e assim saber a ordem em que os processos os requisitarão, prevenindo então um possível deadlock.

7. CONCLUSÃODeadlock é um problema potencial em qualquer sistema operacional. Um estado de deadlock ocorre quando dois ou mais processos estão esperando indefinidamente por um evento que só pode ocorrer por um dos processos em espera. Existem alguns métodos para tratar deadlocks, os quais foram citados neste trabalho: detecção e recuperação, evitar deadlock e prevenção de deadlock.

Uma das estratégias mais simples de tratar deadlock, seria ignorá-lo, porém, é necessário uma análise das necessidades da empresa, para o implemento ou não das estratégias de tratamento do deadlock, assim como, avaliar o custo/benefício que essas implantações podem gerar.

Nas décadas de 60 e 70 podemos verificar a existência de muitas pesquisas na áreas de sistemas operacionais com o objetivo de solucionar os problemas de deadlock. Contudo atualmente poucos estudiosos tem se dedicado a este problema devido ao fato de que muitos outros autores já proporam soluções mas que não são de fato implementadas nos sistemas operacionais mais usados, visto que exige um alto grau de processamento para identificar deadlocks, sendo assim um desperdício já que os deadlocks acontecem ocasionalmente.

Deadlocks não ocorrem apenas em sistemas operacionais, o termo também é usado em redes intra chip pelo mesmo motivo de dependência cíclica.

8. REFERÊNCIAS BIBLIOGRÁFICAS[1] CARARA, E.; MELLO, A. V.; CALAZANS, N. L. V.;

MORAES, F. G.: “Canais Virtuais em Redes Intra-Chip - Implementação na rede HERMES”, In: XI Workshop IBERCHIP, 2005, Salvador. IBERCHIP 2005, 2005. v. 1. pp. 320-321.

[2] COFFMAN, E.C.; ELPHICK, M.J.; SHOSHANI, A.: “System Deadlocks”, In: Computing Surveys, vol. 3, Junho 1971, pp. 67-78.

[3] DALLY, W. J.; SEITZ, C. L.: “Deadlock-Free Message Routing in Multiprocessors Interconnection Networks”, In: IEEE Transactions on Computers, v.36(5), 1987, pp. 547-553.

[4] DIJKSTRA, E. W.; “Go To Statement Considered Harmful” Communications of the ACM, Vol. 11, No. 3, Março 1968, pp. 147-148.

[5] HABERMANN, A. N.: “Prevention of system deadlocks”, In: Communications of the ACM – CACM, v.12 n.7, Julho 1969, pp. 373-ff.

[6] HAVENDER, J. W.: “Avoiding Deadlock in Multitasking Systems”, In: IBM Systems Journal, vol. 7, 1968, pp. 74-84.

[7] HOLT, R. C.: “Some Deadlock Properties of Computer Systems”, In: Computing Surveys, vol. 4, Setembro 1972, pp. 179-196.

[8] ISLOOR, S. S.; MARSLAND, T. A.: “The Deadlock Problem: An Overview”, In: Computer, vol. 13, Setembro 1980, pp. 58-78.

[9] NEWTON, G.: “Deadlock Prevention, Detection, and Resolution: An Annotated Bibliography”, In: Operating Systems Review, vol. 13, Abril 1979, pp. 33-44.

[10] SILBERSCHATZ, A.; GALIN, P.; GAGNE, G.: "Sistemas Operacionais: conceitos e aplicações", Editora Elsvier – 8 reimpressão – Rio de Janeiro: 2000

[11] TANENBAUM, A. S.: "Sistemas Operacionais Modernos", Editora Prentice Hall – 2 ed. – São Paulo: 2003

[12] ZOBEL, D.: “The Deadlock Problem: A Classifying Bibliography”, In: Operating Systems Review, vol. 17, Outubro 1983, pp. 6-16.