race condition이란 무엇이며, mutex와 semaphore는 그것을 어떻게 막는가?

Question

IT Interview Practice · Accepted Answer

여러 thread가 데이터를 공유할 때, 그들의 연산은 여러 단계로 이루어진 갱신 도중에 끼어들(interleave) 수 있어 race condition — 결과가 예측 불가능한 타이밍에 좌우되는 버그 — 을 만든다. **Synchronization(동기화)**은 안전한 순서를 강제하는 도구들의 집합이다.

문제: race condition

count++는 원자적(atomic)으로 보이지만 실제로는 읽기-수정-쓰기(read-modify-write)다:

c

## 문제: race condition

`count++`는 원자적(atomic)으로 보이지만 실제로는 읽기-수정-쓰기(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         ┘
```

읽기와 쓰기 사이의 창(window)이 **critical section**(임계 영역) — 공유 상태를 건드리며 동시에 실행되어서는 안 되는 코드 — 이다.

## 도구들

- **Mutex (lock)** — 상호 배제(mutual exclusion): 한 번에 한 thread만 보유하고, 나머지는 해제될 때까지 block된다. critical section을 감싼다:

```c
pthread_mutex_lock(&m);
count++;                 // critical section — 배타적
pthread_mutex_unlock(&m);
```

- **Semaphore** — 최대 *N*개의 동시 보유자를 허용하는 카운터. 이진 semaphore(N=1)는 lock처럼 동작하고, counting semaphore는 예를 들어 connection pool을 N명으로 제한한다. thread 간 **신호 전달(signaling)**(producer/consumer)에도 쓰인다.
- **Condition variable** — thread가 어떤 술어가 참이 될 때까지(예: "queue가 비지 않음") busy-wait 없이 잠들었다 깨어나게 한다.
- **Atomic operation** — compare-and-swap(CAS) 같은 하드웨어 명령으로 읽기-수정-쓰기를 분리 불가능하게 수행하여 lock-free 카운터를 가능케 한다.

## 함정

lock은 race를 해결하지만 새로운 위험을 들여온다: **deadlock**(thread들이 서로의 lock을 기다림), **priority inversion**, 그리고 **contention**(thread들이 직렬화되어 병렬성을 죽임). 경험칙: critical section을 **짧게** 유지하고, 여러 lock은 항상 **일관된 전역 순서**로 획득하라.

## 왜 중요한가

동시성 버그는 가장 찾기 어려운 축에 든다 — 비결정적이며 디버거를 붙이면 종종 사라진다. 면접관은 당신이 critical section을 *알아채고*, 알맞은 primitive(mutex vs semaphore vs atomic)를 고르며, 실패 모드(deadlock, contention)를 추론할 수 있는지 보고 싶어 한다. 이는 어떤 멀티스레드 서버, 공유 캐시, 카운터에도 그대로 적용된다.

문제: race condition

도구들

함정

왜 중요한가

관련 질문