DBMS - Deadlock

Em um sistema multiprocessos, deadlock é uma situação indesejada que surge em um ambiente de recursos compartilhados, onde um processo aguarda indefinidamente por um recurso mantido por outro processo.

Por exemplo, suponha um conjunto de transações {T 0 , T 1 , T 2 , ..., T n }. T 0 precisa de um recurso X para completar sua tarefa. O recurso X é mantido por T 1 , e T 1 está aguardando um recurso Y, que é mantido por T 2 . T 2 está esperando por Z de recursos, que é realizada por T 0 . Assim, todos os processos esperam uns pelos outros para liberar recursos. Nesta situação, nenhum dos processos pode terminar sua tarefa. Essa situação é conhecida como deadlock.

Deadlocks não são saudáveis ​​para um sistema. No caso de um sistema ficar preso em um conflito, as transações envolvidas no conflito são revertidas ou reiniciadas.

Prevenção de deadlock

Para evitar qualquer situação de deadlock no sistema, o SGBD inspeciona agressivamente todas as operações, onde as transações estão prestes a ser executadas. O SGBD inspeciona as operações e analisa se elas podem criar uma situação de conflito. Se descobrir que pode ocorrer uma situação de conflito, essa transação nunca poderá ser executada.

Existem esquemas de prevenção de conflito que usam o mecanismo de ordenação de registro de data e hora de transações para predeterminar uma situação de conflito.

Esquema Wait-Die

Nesse esquema, se uma transação solicitar o bloqueio de um recurso (item de dados), que já está em conflito com o bloqueio por outra transação, então uma das duas possibilidades pode ocorrer -

  • Se TS (T i ) <TS (T j ) - isto é, T i , que está solicitando um bloqueio conflitante, é mais antigo que T j - então T i pode esperar até que o item de dados esteja disponível.

  • Se TS (T i )> TS (t j ) - isto é, T i é mais jovem que T j - então T i morre. T i é reiniciado mais tarde com um atraso aleatório, mas com o mesmo carimbo de data / hora.

Este esquema permite que a transação mais antiga espere, mas mata a mais jovem.

Esquema de Espera de Ferida

Neste esquema, se uma transação solicitar o bloqueio de um recurso (item de dados), que já foi mantido com bloqueio conflitante por alguma outra transação, uma das duas possibilidades pode ocorrer -

  • Se TS (T i ) <TS (T j ), então T i força T j a ser revertido - isto é, T i feridas T j . T j é reiniciado posteriormente com um atraso aleatório, mas com o mesmo registro de data e hora.

  • Se TS (T i )> TS (T j ), então T i é forçado a esperar até que o recurso esteja disponível.

Este esquema permite que a transação mais jovem espere; mas quando uma transação mais antiga solicita um item mantido por uma mais jovem, a transação mais antiga força a mais jovem a abortar e liberar o item.

Em ambos os casos, a transação que entra no sistema posteriormente é abortada.

Prevenção de deadlock

Abortar uma transação nem sempre é uma abordagem prática. Em vez disso, os mecanismos de prevenção de deadlock podem ser usados ​​para detectar qualquer situação de deadlock com antecedência. Métodos como "gráfico de espera" estão disponíveis, mas são adequados apenas para os sistemas onde as transações são leves e têm menos instâncias de recursos. Em um sistema volumoso, as técnicas de prevenção de deadlock podem funcionar bem.

Gráfico de Espera

Este é um método simples disponível para rastrear se qualquer situação de deadlock pode surgir. Para cada transação que entra no sistema, um nó é criado. Quando uma transação T i solicita um bloqueio em um item, digamos X, que é mantido por alguma outra transação T j , uma aresta direcionada é criada de T i para T j . Se T j liberar o item X, a borda entre eles será eliminada e T i bloqueará o item de dados.

O sistema mantém este gráfico de espera para cada transação que aguarda alguns itens de dados mantidos por outros. O sistema continua verificando se há algum ciclo no gráfico.

Aqui, podemos usar qualquer uma das duas abordagens a seguir -

  • Em primeiro lugar, não permita qualquer solicitação de um item que já esteja bloqueado por outra transação. Isso nem sempre é viável e pode causar fome, onde uma transação espera indefinidamente por um item de dados e nunca pode adquiri-lo.

  • A segunda opção é reverter uma das transações. Nem sempre é viável reverter a transação mais recente, pois pode ser importante do que a mais antiga. Com a ajuda de algum algoritmo relativo, é escolhida uma transação que deve ser abortada. Esta transação é conhecida comovictim e o processo é conhecido como victim selection.