Qual é a diferença entre deadlock e livelock?

Alguém pode explicar com exemplos (de código) qual é a diferença entre deadlock e livelock ?

Retirado de http://en.wikipedia.org/wiki/Deadlock :

Na computação simultânea, um impasse é um estado no qual cada membro de um grupo de ações está aguardando que outro membro libere um bloqueio

Um livelock é semelhante a um impasse, exceto que os estados dos processos envolvidos no livelock mudam constantemente um em relação ao outro, nenhum progredindo. Livelock é um caso especial de inanição de recursos; a definição geral afirma apenas que um processo específico não está progredindo.

Um exemplo do mundo real de livelock ocorre quando duas pessoas se encontram em um corredor estreito, e cada uma tenta ser educada movendo-se para o lado para deixar o outro passar, mas elas acabam balançando de um lado para o outro sem progredir, porque ambas se movem repetidamente da mesma maneira ao mesmo tempo.

Livelock é um risco em alguns algoritmos que detectam e se recuperam de um conflito. Se mais de um processo executar uma ação, o algoritmo de detecção de deadlock poderá ser acionado repetidamente. Isso pode ser evitado, garantindo que apenas um processo (escolhido aleatoriamente ou por prioridade) tome medidas.

Livelock

Um encadeamento geralmente atua em resposta à ação de outro encadeamento. Se a ação do outro encadeamento também for uma resposta à ação de outro encadeamento, poderá ocorrer livelock.

Como no impasse, os threads com bloqueio de transmissão não conseguem fazer mais progressos . No entanto, os threads não estão bloqueados - eles estão ocupados demais respondendo um ao outro para retomar o trabalho . É comparável a duas pessoas que tentam passar uma pela outra em um corredor: Alphonse se move para a esquerda para deixar Gaston passar, enquanto Gaston se move para a direita para deixar Alphonse passar. Vendo que eles ainda estão se bloqueando, Alphonse se move para a direita, enquanto Gaston se move para a esquerda. Eles ainda estão se bloqueando, e assim por diante ...

A principal diferença entre livelock e deadlock é que os threads não serão bloqueados; eles tentarão responder um ao outro continuamente.

Nesta imagem, os dois círculos (threads ou processos) tentarão dar espaço ao outro movendo-se para a esquerda e para a direita. Mas eles não podem avançar mais.

Todo o conteúdo e exemplos aqui são de

Sistemas operacionais: Internos e princípios de design
William Stallings
8º Edição

Impasse : uma situação em que dois ou mais processos não podem prosseguir porque cada um deles espera um dos outros para fazer alguma coisa.

Por exemplo, considere dois processos, P1 e P2, e dois recursos, R1 e R2. Suponha que cada processo precise acessar os dois recursos para desempenhar parte de sua função. É possível ter a seguinte situação: o sistema operacional atribui R1 a P2 e R2 a P1. Cada processo está aguardando um dos dois recursos. Nem liberará o recurso que ele já possui até adquirir o outro recurso e executar a função que requer os dois recursos. Os dois processos estão em um impasse

Livelock : uma situação em que dois ou mais processos alteram continuamente seus estados em resposta a alterações nos outros processos sem realizar nenhum trabalho útil:

Inanição : uma situação em que um processo executável é ignorado indefinidamente pelo planejador; embora possa prosseguir, nunca é escolhido.

Suponha que três processos (P1, P2, P3) requeiram acesso periódico ao recurso R. Considere a situação em que P1 está de posse do recurso e ambos, P2 e P3, estão atrasados, aguardando esse recurso. Quando P1 sai de sua seção crítica, P2 ou P3 devem ter acesso a R. Suponha que o SO conceda acesso a P3 e que P1 novamente exija acesso antes de P3 concluir sua seção crítica. Se o SO conceder acesso a P1 após a conclusão de P3 e, posteriormente, conceder acesso alternadamente a P1 e P3, P2 poderá indefinidamente ser negado o acesso ao recurso, mesmo que não haja situação de conflito.

APÊNDICE A - TÓPICOS EM CONCORRÊNCIA

Exemplo de impasse

Se os dois processos definirem seus sinalizadores como true antes de qualquer um executar a instrução while, cada um deles pensará que o outro entrou em sua seção crítica, causando um conflito.

/* PROCESS 0 */
flag[0] = true;            // <- get lock 0
while (flag[1])            // <- is lock 1 free?
    /* do nothing */;      // <- no? so I wait 1 second, for example
                           // and test again.
                           // on more sophisticated setups we can ask
                           // to be woken when lock 1 is freed
/* critical section*/;     // <- do what we need (this will never happen)
flag[0] = false;           // <- releasing our lock

 /* PROCESS 1 */
flag[1] = true;
while (flag[0])
    /* do nothing */;
/* critical section*/;
flag[1] = false;

Exemplo de Livelock

/* PROCESS 0 */
flag[0] = true;          // <- get lock 0
while (flag[1]){         
    flag[0] = false;     // <- instead of sleeping, we do useless work
                         //    needed by the lock mechanism
    /*delay */;          // <- wait for a second
    flag[0] = true;      // <- and restart useless work again.
}
/*critical section*/;    // <- do what we need (this will never happen)
flag[0] = false; 

/* PROCESS 1 */
flag[1] = true;
while (flag[0]) {
    flag[1] = false;
    /*delay */;
    flag[1] = true;
}
/* critical section*/;
flag[1] = false;

[...] considere a seguinte sequência de eventos:

• P0 define o sinalizador [0] como verdadeiro.
• P1 define o sinalizador [1] como verdadeiro.
• P0 verifica o sinalizador [1].
• P1 verifica o sinalizador [0].
• P0 define o sinalizador [0] como falso.
• P1 define o sinalizador [1] como falso.
• P0 define o sinalizador [0] como verdadeiro.
• P1 define o sinalizador [1] como verdadeiro.

Essa sequência pode ser estendida indefinidamente, e nenhum processo pode entrar em sua seção crítica. Estritamente falando, isso não é um impasse , porque qualquer alteração na velocidade relativa dos dois processos interromperá esse ciclo e permitirá a entrada na seção crítica. Essa condição é conhecida como livelock . Lembre-se de que o conflito ocorre quando um conjunto de processos deseja inserir suas seções críticas, mas nenhum processo pode ser bem-sucedido. Com o livelock , existem possíveis sequências de execuções com êxito, mas também é possível descrever uma ou mais sequências de execução nas quais nenhum processo entra em sua seção crítica.

Não há mais conteúdo do livro.

E os spinlocks?

Spinlock é uma técnica para evitar o custo do mecanismo de bloqueio do SO. Normalmente você faria:

try
{
   lock = beginLock();
   doSomething();
}
finally
{
   endLock();
}

Um problema começa a aparecer quando beginLock()custa muito mais do que doSomething(). Em termos muito exagerados, imagine o que acontece quando o beginLockcusto é de 1 segundo, mas doSomethingcusta apenas 1 milissegundo.

Nesse caso, se você esperasse 1 milissegundo, evitaria ser prejudicado por 1 segundo.

Por beginLockque custaria tanto? Se o bloqueio é gratuito, não custa muito (consulte https://stackoverflow.com/a/49712993/5397116 ), mas se o bloqueio não estiver livre, o sistema operacional "congelará" seu encadeamento, configure um mecanismo para acordá-lo quando o bloqueio for liberado e, em seguida, acordá-lo novamente no futuro.

Tudo isso é muito mais caro do que alguns loops verificando a trava. É por isso que às vezes é melhor fazer um "spinlock".

Por exemplo:

void beginSpinLock(lock)
{
   if(lock) loopFor(1 milliseconds);
   else 
   {
     lock = true;
     return;
   }

   if(lock) loopFor(2 milliseconds);
   else 
   {
     lock = true;
     return;
   }

   // important is that the part above never 
   // cause the thread to sleep.
   // It is "burning" the time slice of this thread.
   // Hopefully for good.

   // some implementations fallback to OS lock mechanism
   // after a few tries
   if(lock) return beginLock(lock);
   else 
   {
     lock = true;
     return;
   }
}

Se sua implementação não for cuidadosa, você poderá usar o livelock, gastando toda a CPU no mecanismo de bloqueio.

Veja também:

https://preshing.com/20120226/roll-your-own-lightweight-mutex/
Minha implementação de bloqueio de rotação está correta e ideal?

Resumo :

Impasse : situação em que ninguém progride, não faz nada (dorme, espera etc.). O uso da CPU será baixo;

Livelock : situação em que ninguém progride, mas a CPU é gasta no mecanismo de bloqueio e não no seu cálculo;

Fome: situação em que um processo nunca tem a chance de correr; por pura má sorte ou por algumas de suas propriedades (baixa prioridade, por exemplo);

Spinlock : técnica de evitar o custo de espera para liberar o bloqueio.

DEADLOCK Deadlock é uma condição na qual uma tarefa aguarda indefinidamente por condições que nunca podem ser satisfeitas - tarefa reivindica controle exclusivo sobre recursos compartilhados - tarefa mantém recursos enquanto aguarda a liberação de outros recursos - tarefas não podem ser forçadas a redesignar recursos - uma espera circular condição existe

LIVELOCK As condições do Livelock podem surgir quando duas ou mais tarefas dependem e usam algum recurso, causando uma condição circular de dependência em que essas tarefas continuam em execução para sempre, impedindo a execução de todas as tarefas de nível de prioridade mais baixa (essas tarefas de prioridade mais baixa sofrem uma condição chamada inanição)

Talvez estes dois exemplos ilustrem a diferença entre um impasse e um livelock:

Exemplo de Java para um conflito:

import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

public class DeadlockSample {

    private static final Lock lock1 = new ReentrantLock(true);
    private static final Lock lock2 = new ReentrantLock(true);

    public static void main(String[] args) {
        Thread threadA = new Thread(DeadlockSample::doA,"Thread A");
        Thread threadB = new Thread(DeadlockSample::doB,"Thread B");
        threadA.start();
        threadB.start();
    }

    public static void doA() {
        System.out.println(Thread.currentThread().getName() + " : waits for lock 1");
        lock1.lock();
        System.out.println(Thread.currentThread().getName() + " : holds lock 1");

        try {
            System.out.println(Thread.currentThread().getName() + " : waits for lock 2");
            lock2.lock();
            System.out.println(Thread.currentThread().getName() + " : holds lock 2");

            try {
                System.out.println(Thread.currentThread().getName() + " : critical section of doA()");
            } finally {
                lock2.unlock();
                System.out.println(Thread.currentThread().getName() + " : does not hold lock 2 any longer");
            }
        } finally {
            lock1.unlock();
            System.out.println(Thread.currentThread().getName() + " : does not hold lock 1 any longer");
        }
    }

    public static void doB() {
        System.out.println(Thread.currentThread().getName() + " : waits for lock 2");
        lock2.lock();
        System.out.println(Thread.currentThread().getName() + " : holds lock 2");

        try {
            System.out.println(Thread.currentThread().getName() + " : waits for lock 1");
            lock1.lock();
            System.out.println(Thread.currentThread().getName() + " : holds lock 1");

            try {
                System.out.println(Thread.currentThread().getName() + " : critical section of doB()");
            } finally {
                lock1.unlock();
                System.out.println(Thread.currentThread().getName() + " : does not hold lock 1 any longer");
            }
        } finally {
            lock2.unlock();
            System.out.println(Thread.currentThread().getName() + " : does not hold lock 2 any longer");
        }
    }
}

Saída de amostra:

Thread A : waits for lock 1
Thread B : waits for lock 2
Thread A : holds lock 1
Thread B : holds lock 2
Thread B : waits for lock 1
Thread A : waits for lock 2

Exemplo de Java para um livelock:

import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

public class LivelockSample {

    private static final Lock lock1 = new ReentrantLock(true);
    private static final Lock lock2 = new ReentrantLock(true);

    public static void main(String[] args) {
        Thread threadA = new Thread(LivelockSample::doA, "Thread A");
        Thread threadB = new Thread(LivelockSample::doB, "Thread B");
        threadA.start();
        threadB.start();
    }

    public static void doA() {
        try {
            while (!lock1.tryLock()) {
                System.out.println(Thread.currentThread().getName() + " : waits for lock 1");
                Thread.sleep(100);
            }
            System.out.println(Thread.currentThread().getName() + " : holds lock 1");

            try {
                while (!lock2.tryLock()) {
                    System.out.println(Thread.currentThread().getName() + " : waits for lock 2");
                    Thread.sleep(100);
                }
                System.out.println(Thread.currentThread().getName() + " : holds lock 2");

                try {
                    System.out.println(Thread.currentThread().getName() + " : critical section of doA()");
                } finally {
                    lock2.unlock();
                    System.out.println(Thread.currentThread().getName() + " : does not hold lock 2 any longer");
                }
            } finally {
                lock1.unlock();
                System.out.println(Thread.currentThread().getName() + " : does not hold lock 1 any longer");
            }
        } catch (InterruptedException e) {
            // can be ignored here for this sample
        }
    }

    public static void doB() {
        try {
            while (!lock2.tryLock()) {
                System.out.println(Thread.currentThread().getName() + " : waits for lock 2");
                Thread.sleep(100);
            }
            System.out.println(Thread.currentThread().getName() + " : holds lock 2");

            try {
                while (!lock1.tryLock()) {
                    System.out.println(Thread.currentThread().getName() + " : waits for lock 1");
                    Thread.sleep(100);
                }
                System.out.println(Thread.currentThread().getName() + " : holds lock 1");

                try {
                    System.out.println(Thread.currentThread().getName() + " : critical section of doB()");
                } finally {
                    lock1.unlock();
                    System.out.println(Thread.currentThread().getName() + " : does not hold lock 1 any longer");
                }
            } finally {
                lock2.unlock();
                System.out.println(Thread.currentThread().getName() + " : does not hold lock 2 any longer");
            }
        } catch (InterruptedException e) {
            // can be ignored here for this sample
        }
    }
}

Saída de amostra:

Thread B : holds lock 2
Thread A : holds lock 1
Thread A : waits for lock 2
Thread B : waits for lock 1
Thread B : waits for lock 1
Thread A : waits for lock 2
Thread A : waits for lock 2
Thread B : waits for lock 1
Thread B : waits for lock 1
Thread A : waits for lock 2
Thread A : waits for lock 2
Thread B : waits for lock 1
...

Ambos os exemplos forçam os encadeamentos a adquirir os bloqueios em ordens diferentes. Enquanto o impasse aguarda o outro bloqueio, o bloqueio realmente não espera - ele tenta desesperadamente adquiri-lo sem a chance de obtê-lo. Cada tentativa consome ciclos da CPU.

Imagine que você tenha o segmento A e o segmento B. Ambos estão synchronisedno mesmo objeto e, dentro desse bloco, há uma variável global que eles estão atualizando;

static boolean commonVar = false;
Object lock = new Object;

...

void threadAMethod(){
    ...
    while(commonVar == false){
         synchornized(lock){
              ...
              commonVar = true
         }
    }
}

void threadBMethod(){
    ...
    while(commonVar == true){
         synchornized(lock){
              ...
              commonVar = false
         }
    }
}

Portanto, quando o segmento A entra no whileloop e mantém a trava, ele faz o que tem que fazer e define commonVarcomo true. Então a linha B entra, entra no whileloop e, como commonVaré trueagora, é capaz de segurar a trava. Faz isso, executa o synchronisedbloco e commonVarvolta para false. Agora, o thread A novamente obtém sua nova janela da CPU, estava prestes a sair do whileloop, mas o thread B acabou de configurá-lo novamente para falseque o ciclo se repita novamente. Os threads fazem alguma coisa (para que não sejam bloqueados no sentido tradicional), mas praticamente para nada.

Talvez também seja bom mencionar que o livelock não precisa necessariamente aparecer aqui. Estou assumindo que o agendador favorece o outro thread quando o synchronisedbloco terminar de executar. Na maioria das vezes, acho que é uma expectativa difícil de atingir e depende de muitas coisas acontecendo sob o capô.