[OSTEP] 30. Condition Variables

1.1 주요 인터페이스#

POSIX 스레드(Pthreads)에서 자주 쓰는 인터페이스는 다음과 같습니다.

1
int pthread_cond_wait(pthread_cond_t *c, pthread_mutex_t *m);
2
int pthread_cond_signal(pthread_cond_t *c);
3
int pthread_cond_broadcast(pthread_cond_t *c);

여기서 핵심은 pthread_cond_wait()가 mutex를 함께 받는다는 점입니다.

• wait()는 mutex가 잠긴 상태에서 호출되어야 합니다.
• wait()는 내부에서 mutex 해제 + 대기열 진입 + 잠들기를 한 덩어리로 처리합니다.
• 깨어난 뒤에는 mutex를 다시 획득한 상태로 리턴합니다.

이 동작 덕분에, 잠들기 직전에 신호를 놓치는 종류의 경쟁 조건을 피할 수 있습니다.

2.1 올바른 구현 패턴#

조건 변수를 사용할 때는 항상 다음 3개를 함께 둡니다.

• 상태 변수(state variable): 예: done
• mutex: 상태 변수 접근을 보호
• condition variable: 조건이 만족될 때까지 잠들기/깨우기

부모 스레드(대기):

1
Pthread_mutex_lock(&m);
2
while (done == 0)
3
    Pthread_cond_wait(&c, &m);
4
Pthread_mutex_unlock(&m);

자식 스레드(상태 변경 + 신호):

1
Pthread_mutex_lock(&m);
2
done = 1;
3
Pthread_cond_signal(&c);
4
Pthread_mutex_unlock(&m);

2.2 핵심 규칙#

1. 상태 변수는 필수

   • signal()만으로는 충분하지 않습니다.
   • 자식이 먼저 실행되어 signal()을 했는데 그때 아무도 wait 중이 아니라면, 이후 부모는 wait()에서 영원히 잠들 수 있습니다. 상태 변수는 그 사실(done)을 기록합니다.

2. 락은 필수

   • 부모가 done == 0을 확인한 직후 wait()로 들어가기 전에 자식이 끼어들어 done = 1; signal()을 수행하면, 부모는 신호를 놓치고 영원히 잠드는 레이스가 발생할 수 있습니다.
   • wait()의 동작(락 해제와 잠들기의 결합)과 락으로 보호된 상태 변수 접근이 이 문제를 막습니다.

3. 조건 확인은 while

   • 깨어났다고 해서 조건이 참이라는 보장은 없습니다.
   • 따라서 if가 아니라 while로 조건을 재확인합니다.

추가로 실전 팁을 하나만 덧붙이면, signal()도 가능하면 락을 잡은 상태에서 호출하는 습관이 안전합니다. 상태 변수를 바꾼 뒤 같은 락을 잡은 채로 signal() 하면, 신호와 상태 변화의 관계를 읽기 쉬워지고 실수를 줄일 수 있습니다.

3.1 Mesa semantics와 while 루프#

대부분의 시스템에서 signal()은 단지 상태가 바뀌었을 수 있다는 힌트입니다. 깨어난 스레드가 곧바로 실행된다는 보장도 없고, 실행될 때 조건이 여전히 참이라는 보장도 없습니다(Mesa semantics).

따라서 다음이 항상 안전한 규칙입니다.

1
while (count == 0)                 // if가 아니라 while
2
    Pthread_cond_wait(&fill, &mutex);

또한 구현과 스케줄링 세부에 따라 신호 없이도 깨어나는 spurious wakeup이 있을 수 있으므로, while 재확인은 방어적으로도 필요합니다.

3.2 단일 조건 변수로는 부족한 이유#

버퍼가 비었음과 가득 참은 서로 다른 조건입니다. 그런데 단일 조건 변수 하나로 관리하면, 소비자가 signal() 했을 때 다른 소비자를 깨우는 식의 잘못된 깨움이 가능해집니다. 깨어난 스레드는 조건을 만족하지 못해 다시 잠들고, 운이 나쁘면 모두가 잠드는 상태로 빠질 수 있습니다.

3.3 해결책: 두 개의 조건 변수#

따라서 보통 다음처럼 조건 변수를 2개 둡니다.

• empty: 생산자가 기다리는 조건(버퍼에 빈 칸이 생김)
• fill: 소비자가 기다리는 조건(버퍼에 데이터가 생김)

단일 슬롯(1-entry) 버퍼의 올바른 구조는 다음과 같습니다.

1
// Producer
2
Pthread_mutex_lock(&mutex);
3
while (count == 1)                 // 가득 찼으면 대기
4
    Pthread_cond_wait(&empty, &mutex);
5

6
put(i);                            // count, buffer 상태 변경
7
Pthread_cond_signal(&fill);        // 소비자 깨우기
8
Pthread_mutex_unlock(&mutex);

1
// Consumer
2
Pthread_mutex_lock(&mutex);
3
while (count == 0)                 // 비었으면 대기
4
    Pthread_cond_wait(&fill, &mutex);
5

6
tmp = get();                       // count, buffer 상태 변경
7
Pthread_cond_signal(&empty);       // 생산자 깨우기
8
Pthread_mutex_unlock(&mutex);

여러 슬롯(MAX) 버퍼로 일반화하면 조건만 count == MAX / count == 0으로 바뀝니다.

4.1 해결책: broadcast#

이 경우는 signal() 대신 pthread_cond_broadcast()를 사용합니다.

• broadcast는 대기 중인 모든 스레드를 깨웁니다.
• 각 스레드는 깨어난 뒤 락을 획득하고 조건을 재확인합니다.
• 실행 가능한 스레드만 진행하고, 나머지는 다시 잠듭니다.

이런 패턴을 포함 조건(covering condition)이라고 부릅니다. 불필요한 깨움이 생길 수 있지만, 어떤 스레드를 깨워야 하는지 정보가 부족한 상황에서는 가장 보수적이면서 올바른 해결책이 됩니다.