Qual é a diferença entre a estratégia de bloqueio de recursos pessimista e otimista em sistemas?

As estratégias de bloqueio pessimista e otimista diferem na abordagem para gerir o acesso concorrente:

• Bloqueio pessimista assume que ocorrerão conflitos de acesso, por isso o recurso é bloqueado imediatamente ao começar a trabalhar com ele. Outros processos ou threads aguardam a liberação do bloqueio. Isto reduz a probabilidade de conflitos, mas pode levar a atrasos e bloqueios.

• Bloqueio otimista assume que os conflitos são raros, por isso o bloqueio não é aplicado imediatamente. Em vez disso, ao guardar as alterações, verifica-se se o recurso mudou desde a leitura (por exemplo, por versão ou timestamp). Se for detectado um conflito, a operação é repetida ou revertida.

Em Go, por exemplo, o bloqueio pessimista é implementado através de mutex (sync.Mutex), e o otimista através de comparação e troca (sync/atomic ou verificação de versões).

Exemplo de bloqueio pessimista:

var mu sync.Mutex

mu.Lock()
// trabalho com o recurso
mu.Unlock()

O bloqueio otimista requer lógica adicional para verificar alterações, por exemplo:

version := resource.Version
// trabalho com o recurso
if resource.Version != version {
    // conflito, repetir operação
}

A escolha da estratégia depende da frequência de conflitos e dos requisitos de desempenho.