경쟁 상태 (Race Condition)

경쟁 상태(Race Condition)는 둘 이상의 실행 흐름이 공유 자원에 동시에 접근할 때, 접근 순서나 타이밍에 따라 결과가 달라지는 상황을 말한다. 실행할 때마다 결과가 다르고 재현이 어려워 동시성 버그 가운데 가장 잡기 어려운 부류에 속한다. 문제의 근원은 공유 데이터를 건드리는 코드 구간, 즉 임계 구역(critical section)이 원자적으로 실행되지 않는 데 있다.

왜 counter++ 한 줄이 위험한가

고수준 언어의 한 줄이 기계 수준에서는 여러 단계로 쪼개진다는 것이 경쟁 상태의 출발점이다. counter++는 실제로 읽기, 더하기, 쓰기 세 단계다.

// 두 스레드가 counter++ 를 동시에 실행 (초기값 0)
스레드 A: load  counter (0)
스레드 B: load  counter (0)     // A가 쓰기 전에 끼어듦
스레드 A: add 1  -> 1
스레드 B: add 1  -> 1
스레드 A: store counter = 1
스레드 B: store counter = 1     // 최종값 1, 기대값은 2

두 번 증가했는데 결과는 한 번만 반영되었다. 이런 끼어듦은 단일 코어에서는 문맥 교환 타이밍에 따라, 멀티코어에서는 물리적으로 동시에 일어난다. 갱신 손실(lost update) 외에도, 검사와 사용 사이에 상태가 바뀌는 검사 시점과 사용 시점 문제(TOCTOU, Time Of Check To Time Of Use)도 대표적인 경쟁 상태다. 파일 존재를 확인한 뒤 여는 사이에 파일이 바뀌는 보안 취약점이 전형적 예다.

임계 구역 문제와 해법의 세 가지 요건

경쟁 상태를 막으려면 임계 구역에 한 번에 하나의 흐름만 들어가게 해야 한다. 임계 구역 문제의 올바른 해법은 세 조건을 만족해야 한다.

• 상호 배제(Mutual Exclusion): 한 스레드가 임계 구역에 있으면 다른 스레드는 들어올 수 없다.
• 진행(Progress): 임계 구역이 비어 있다면 들어가려는 스레드의 진입을 불필요하게 미루지 않는다.
• 유한 대기(Bounded Waiting): 진입을 요청한 스레드는 유한한 횟수의 양보 후에는 반드시 들어갈 수 있어야 한다.

상호 배제만 지키고 진행이나 유한 대기를 어기면 각각 불필요한 지연과 기아(starvation)가 생기므로 셋 다 필요하다.

해결 도구들

도구	방식	적합한 상황
뮤텍스(Mutex)	락을 잡은 스레드만 임계 구역 진입, 나머지는 잠들어 대기	일반적인 공유 데이터 보호
스핀락(Spinlock)	락이 풀릴 때까지 반복 확인하며 대기	임계 구역이 극히 짧은 커널이나 멀티코어 저수준 코드
세마포어(Semaphore)	카운터로 동시 진입 수를 제한	자원 개수 관리, 스레드 간 순서 신호
원자적 연산(Atomic Operation)	하드웨어의 CAS(Compare-And-Swap) 등으로 락 없이 갱신	카운터 증가 같은 단순 갱신, 락프리 자료구조
불변과 격리 설계	공유 자체를 없애거나 데이터를 읽기 전용으로 유지	메시지 전달 모델, 함수형 스타일, 스레드별 데이터

가장 좋은 해법은 공유 가변 상태 자체를 줄이는 것이다. 경쟁 상태는 공유, 가변, 동시 접근 세 조건이 모두 성립할 때만 생기므로 하나만 제거해도 사라진다. 고(Go)의 채널로 데이터를 소유권째 넘기는 방식, 스레드마다 독립 복사본을 두는 스레드 로컬(thread local) 저장소가 공유 자체를 없애는 대표적 설계다.