Questão de Sistemas Operacionais — Threads — FUNDATEC 2026

Deadlock em programas com múltiplos mutex (pthreads)

Gabarito: letra E. O programa pode entrar em deadlock caso cada thread adquira um mutex diferente e fique aguardando indefinidamente pelo outro, configurando a espera circular característica do deadlock. A alternativa correta descreve exatamente o cenário clássico de deadlock com dois mutex, que pode ocorrer mesmo com o uso correto das primitivas de sincronização da biblioteca POSIX Threads.

O deadlock é uma condição em que duas ou mais threads (ou processos) ficam permanentemente bloqueadas, cada uma esperando por um recurso que a outra detém. Para que o deadlock ocorra, quatro condições devem ser satisfeitas simultaneamente: exclusão mútua (cada recurso só pode ser usado por uma thread por vez), posse e espera (uma thread detém um recurso e espera por outro), não preempção (os recursos não podem ser retirados à força) e espera circular (existe um ciclo de threads, cada uma esperando por um recurso detido pela próxima). No programa da questão, há dois mutex (vamos chamá-los de mutex A e mutex B) e duas threads (thread1 e thread2). Se a thread1 adquirir o mutex A e, antes de liberá-lo, tentar adquirir o mutex B, enquanto a thread2 adquiriu o mutex B e tenta adquirir o mutex A, temos exatamente a espera circular: thread1 espera por B (detido por thread2) e thread2 espera por A (detido por thread1). Nenhuma das duas consegue progredir, e o programa fica travado para sempre.

É importante destacar que o uso de mutex é uma técnica de sincronização para evitar condições de corrida (acesso concorrente a dados compartilhados), mas não previne deadlock por si só. Pelo contrário, o uso inadequado de múltiplos mutex é uma das causas mais comuns de deadlock. Para evitá-lo, uma estratégia é estabelecer uma ordem global de aquisição dos mutex (por exemplo, sempre adquirir o mutex A antes do B), garantindo que não haja ciclo. Outra abordagem é usar pthread_mutex_trylock para tentar adquirir o mutex sem bloquear e, se falhar, liberar os já adquiridos e tentar novamente.

A banca explora exatamente a confusão entre sincronização (mutex) e prevenção de deadlock. O candidato pode pensar que, como cada thread libera os mutex ao final, o programa sempre executará corretamente — mas isso ignora a possibilidade de as threads ficarem bloqueadas antes de chegar ao final. A alternativa E captura precisamente essa possibilidade, descrevendo o cenário de deadlock com dois mutex.

Guarde a distinção: mutex garante exclusão mútua, mas não garante ausência de deadlock. É nessa fronteira que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Afirma que pthread_mutex_lock impede automaticamente a ocorrência de deadlock. Isso é falso: o mutex é uma primitiva de exclusão mútua, mas o deadlock pode ocorrer justamente pelo uso inadequado de múltiplos mutex, como no cenário da questão. O mutex não tem mecanismo para detectar ou evitar espera circular.

Alternativa B — ❌ Incorreta

Afirma que o programa apresenta erro de compilação devido ao uso simultâneo de dois mutex. Não há erro de compilação: a biblioteca pthreads permite declarar e usar múltiplos mutex normalmente. O problema é de execução (deadlock), não de compilação.

Alternativa C — ❌ Incorreta

Afirma que o programa executará sempre na mesma ordem, primeiro thread1 e depois thread2. A ordem de execução das threads é determinada pelo escalonador do sistema operacional e não é previsível. As threads podem executar em qualquer ordem, e é justamente essa imprevisibilidade que pode levar ao deadlock.

Alternativa D — ❌ Incorreta

Afirma que o programa sempre executará corretamente, pois cada thread libera os mutex ao final. Isso ignora a possibilidade de deadlock: se as threads ficarem bloqueadas esperando uma pela outra, nunca chegarão ao final para liberar os mutex. A liberação ao final só ocorre se a execução chegar até lá, o que não é garantido.

Alternativa E — ✅ Correta ⟵ GABARITO

Descreve exatamente o cenário de deadlock: cada thread adquire um mutex diferente e fica aguardando indefinidamente pelo outro. Isso configura a espera circular, uma das quatro condições necessárias para o deadlock. A alternativa está correta porque reconhece que o programa pode entrar em deadlock, dependendo da ordem de execução das threads.

Gabarito: letra E