Deadlock

Importante: Este wiki é informativo. Repasse a seu desenvolvedor e caso mesmo assim perceba lentidão excessiva em seu site, contacte nosso suporte para maiores orientações e verificação de desempenho do servidor.

Atenção: É comum em sites, onde a atualização é constante e, caso não se tenha uma boa estrutura de código, um processo pode acabar bloqueando outro, deixando o site lento na hora do carregamento.

O que é um Deadlock?

Deadlock (interbloqueio, blocagem, impasse), no contexto de banco de dados(MS-SQL/MySQL), caracteriza uma situação em que ocorre um impasse e dois ou mais processos ficam impedidos de continuar suas execuções, ou seja, ficam bloqueados.

O deadlock ocorre com um conjunto de processos e recursos não-preemptíveis, onde um ou mais processos desse conjunto está aguardando a liberação de um recurso por um outro processo que, por sua vez, aguarda a liberação de outro recurso alocado ou dependente do primeiro processo.

É comum em sites de noticias, onde a atualização é constante e, caso não se tenha uma boa estrutura de código, um processo pode acabar matando outro, deixando o site lento na horá do carregamento.

A definição textual de deadlock normalmente, por ser muito abstrata, é mais difícil de se compreender do que a representação por grafos, que será resumida mais adiante. No entanto, algumas observações são pertinentes:

O deadlock independe da quantidade de recursos disponíveis no sistema;

Um exemplo onde erros de deadlock ocorrem é no banco de dados. Suponha que uma empresa tenha vários vendedores e vários pontos de venda/caixas. O vendedor A vendeu 1 relógio e 1 pulseira. O sistema então solicita o travamento do registro da tabela ESTOQUE que contém o total de relógios em estoque e em seguida solicita o travamento do registro que contém o total de pulseiras em estoque. De posse da exclusividade de acesso aos dois registros, ele lê a quantidade de relógios, subtrai 1 e escreve de novo no registro, o mesmo com o registro de pulseiras. Observe, no entanto que existem diversos caixas operando simultaneamente de forma que se algum outro caixa naquele exato instante estiver vendendo uma pulseira, ele ficará aguardando a liberação do registro das pulseiras para depois alterá-lo. Note que ele só altera os registro depois que for dada exclusividade para ele de TODOS os recursos que ele precisa, ou seja, de todos os registro. Suponha agora que em outro caixa foram vendidos 1 relógio e 1 pulseira e que o outro caixa solicitou o travamento do registro com a quantidade de pulseiras e agora quer o acesso ao de relógios, no entanto o de relógios está travado para o primeiro caixa. Nenhum deles devolve o recurso (registro) sobre o qual tem exclusividade e também não consegue acesso ao outro registro que falta para terminar a operação. Isto é um deadlock.

Comparação

Deadlock

Tratamento de DeadLock

As situações de deadlock podem ser tratadas ou não em um sistema, e cabe aos desenvolvedores 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.

Existem três estratégias para tratamento de deadlocks:

Ignorar a situação;
Detectar o deadlock e recuperar o sistema;
Evitar o deadlock;

Algoritmo do Avestruz (Ignorar a situação)

A estratégia mais simples para tratamento (ou não) do “deadlock”, conhecida como Algoritmo do Avestruz, é simplesmente ignorá-lo. Muitos defendem que a freqüência de ocorrência deste tipo de evento é baixa demais para que seja necessário sobrecarregar o processamento com códigos extras de tratamento, e que, ocasionalmente, é tolerável reiniciar o sistema/banco como uma ação corretiva.

Detectar o deadlock e recuperar o sistema

Nessa estratégia, o sistema permite que ocorra o deadlock e só então executa o procedimento de recuperação, que resume-se na detecção da ocorrência e na recuperação posterior do sistema. É na execução desse procedimento que ocorre a sobrecarga, pois existem dois grandes problemas: primeiramente, como/quando detectar o deadlock e depois, como corrigi-lo.

Para detectar o deadlock, o sistema deve implementar uma estrutura de dados que armazene as informações sobre os processos e os recursos alocados a eles. Essas estruturas deverão ser atualizadas dinamicamente, de modo que reflitam realmente a situação de cada processo/recurso no sistema.

Só o mero procedimento de atualização dessas estruturas já gera uma sobrecarga no sistema, pois toda vez que um processo aloca, libera ou requisita um recurso, as estruturas precisam ser atualizadas.

Além disso, o banco precisa verificar a ocorrência da condição de espera circular nessas estruturas para a efetiva detecção do deadlock. Esse procedimento, por sua vez, gera outra sobrecarga, que pode ser mais intensa se não for definido um evento em particular para ser executado, como a liberação de um recurso, por exemplo. Assim, ou o banco verifica periodicamente as estruturas (o que não é aconselhável, pois pode aumentar consideravelmente o tempo de espera dos processos não-bloqueados), ou pode-se implementar uma política, onde o banco verifica as estruturas quando o mesmo realizar algum procedimento de manutenção do sistema, por exemplo.

Finalmente, só após detectar a presença do deadlock no sistema, o tratamento precisa corrigi-lo, executando um procedimento de recuperação.