Pelo que entendi:
- Livelock: um thread não progride, mas continua em execução para sempre (o thread está infinitamente ativo): por exemplo, ele está em um loop infinitamente tentando obter acesso a um recurso compartilhado que nunca estará disponível novamente.
- Deadlock: uma thread não progride, mas nem sequer está em execução (a thread está infinitamente adormecida e, portanto, morta): ela está esperando ser despertada pelo sistema operacional com base em uma condição que nunca acontecerá.
- Fome: uma thread não progride e está bloqueando (como em um deadlock), mas a condição que está sendo aguardada para ser despertada ocorre, acontece que há outras threads que sempre tomam meu lugar antes de mim.
Primeiro, essas definições estão mais ou menos corretas? Se estiverem, elas também se aplicam a programas single thread? Por exemplo:
// begin of useful work
until (some_buggy_condition_that_will_never_be_satisfied())
do_something();
// end of useful work
No exemplo acima, o loop será executado para sempre porque a condição, que não tem nada a ver com recursos compartilhados, tem um bug e nunca será satisfeita. Então o thread:
- Está em execução.
- Para fazer um trabalho útil o loop deve terminar
- O loop nunca terminará porque a condição para terminar nunca será satisfeita
Então essa lista corresponde à minha definição de livelock acima, só que estou usando o termo fora dos contextos de simultaneidade. Tudo bem?
É preciso mais de um thread para ter um live lock. Dizemos "live lock" quando um sistema de threads interagindo repete continuamente algum tipo de comportamento de back-up-and-retry em vez de fazer qualquer trabalho. Imagine uma porta, e imagine dois ou mais cavalheiros obsequiosos que querem passar ao mesmo tempo. Mas tudo o que eles fazem é se revezar dizendo: "Não! Depois de você, eu insisto. " E ninguém nunca passa pela porta.
Um loop infinito não é um live lock. Existem muitos programas nos quais threads ficam em loop para sempre fazendo trabalho útil. Nós só dizemos "live lock" quando nenhum trabalho está sendo feito.
É preciso mais de um thread para haver um deadlock. Dizemos "deadlock" quando há um grupo de threads em que nenhum deles pode fazer nada até adquirir um recurso que um dos outros membros do grupo está segurando. Imagine uma ponte de uma faixa, com filas de veículos querendo cruzar nas duas direções, mas motoristas agressivos na frente de cada fila estão gritando uns com os outros: "Não vou me mover nem um centímetro até você sair do meu caminho."
A fome é como metade de uma fechadura viva. Ela tem o mesmo ciclo contínuo de recuar e tentar novamente, exceto que o ciclo permite que pelo menos um thread progrida enquanto obstrui pelo menos outro thread. Imagine uma pessoa tímida que tem medo de forçar a passagem por uma porta contra uma fila aparentemente interminável de pessoas que vêm na outra direção.
Atualização Você perguntou,
Na minha opinião, não há razão para usar nenhum desses termos ao falar sobre um programa single-threaded. Você só vai confundir as pessoas se fizer isso.
Falando por mim, eu chamaria isso de um loop com uma condição de saída com erros.
Nota! Alguns autores usarão a frase " self deadlock" quando uma thread para de tentar obter um segundo bloqueio em um recurso para o qual ela já possui um bloqueio. Mas, se você está falando de um programa single-threaded, então por que haveria um bloqueio para a thread travar?
Sim, usar o termo livelock fora de contextos de simultaneidade pode ser aceitável, desde que você esteja ciente da distinção e a esclareça no contexto correto.
Embora tradicionalmente o livelock se refira a uma situação em ambientes multithread onde dois ou mais threads estão em execução ativa, mas não conseguem progredir devido à interferência mútua, o conceito pode ser aplicado livremente em cenários de thread único com algumas ressalvas.
No seu caso, você está descrevendo um loop infinito onde o thread continua executando sem fazer progresso devido a uma condição de bug. Isso se assemelha ao livelock no sentido de que o sistema está vivo, mas "travado", não fazendo nenhum progresso útil.