O que são race conditions, e como mutexes e semáforos as previnem?

Question

IT Interview Practice · Accepted Answer

Quando múltiplas threads compartilham dados, suas operações podem intercalar (interleave) no meio de uma atualização de várias etapas, produzindo uma race condition — um bug onde o resultado depende de um timing imprevisível. Sincronização é o conjunto de ferramentas que força uma ordenação segura.

O problema: uma race condition

parece atômico mas na verdade é read-modify-write:

## O problema: uma race condition

`count++` parece atômico mas na verdade é read-modify-write:

```c
// two threads, shared int count = 0, each does count++ once
// thread A: read count (0) ─┐           interleaving loses an update:
// thread B: read count (0) ─┤  both read 0, both write 1 → count == 1, not 2
// thread A: write 1         │
// thread B: write 1         ┘
```

A janela entre a leitura e a escrita é uma **critical section** — código que toca estado compartilhado e não pode rodar concorrentemente.

## As ferramentas

- **Mutex (lock)** — exclusão mútua: apenas uma thread o mantém por vez; as outras bloqueiam até ele ser liberado. Envolva a critical section:

```c
pthread_mutex_lock(&m);
count++;                 // critical section — exclusiva
pthread_mutex_unlock(&m);
```

- **Semáforo** — um contador que permite até *N* detentores concorrentes. Um semáforo binário (N=1) age como um lock; um semáforo de contagem limita, digamos, um connection pool a N usuários. Também usado para **sinalização** entre threads (producer/consumer).
- **Condition variable** — permite que uma thread durma até um predicado se tornar verdadeiro (ex. "queue não vazia"), acordando sem busy-waiting.
- **Operações atômicas** — instruções de hardware como compare-and-swap (CAS) que fazem read-modify-write de forma indivisível, permitindo contadores lock-free.

## Armadilhas

Locks resolvem races mas introduzem novos riscos: **deadlock** (threads esperando pelos locks umas das outras), **priority inversion**, e **contention** (as threads serializam, matando o paralelismo). A regra prática: mantenha as critical sections **curtas**, e sempre adquira múltiplos locks em uma **ordem global consistente**.

## Por que isso importa

Bugs de concorrência estão entre os mais difíceis de encontrar — são não determinísticos e muitas vezes desaparecem sob um debugger. Os entrevistadores querem ver que você consegue *identificar* uma critical section, escolher a primitive certa (mutex vs semáforo vs atômico), e raciocinar sobre os modos de falha (deadlock, contention). Isso se aplica diretamente a qualquer servidor multithread, cache compartilhado, ou contador.

O problema: uma race condition

As ferramentas

Armadilhas

Por que isso importa

Perguntas relacionadas