동시성 — 공유 자원의 함정과 자물쇠

스레드는 힙을 공유한다고 했다. 이 공유가 통신을 공짜로 만들지만 — 두 스레드가 같은 데이터를 동시에 건드리면 데이터가 깨진다. 이게 동시성의 핵심 함정 — *"공유 가변 상태를 조심하라"*는 경고의 밑바닥이다. 왜 깨지는지, 그리고 그걸 막는 자물쇠들이 어떻게 다른지를 본다.

왜 깨지나 — counter++의 비밀

counter++ 한 줄이 원자적일 것 같지만, 기계어로 보면 세 단계다 — 읽고(read) → 1 더하고(modify) → 쓴다(write). 두 스레드가 동시에 이걸 하면 끔찍한 순서가 가능하다.

둘 다 10을 읽고, 각자 11을 써서 — 2가 늘어야 하는데 1만 늘었다. 이 "중간에 끼어들어 망가지는" 상황이 **경쟁 조건(race condition)**이다. 문제의 핵심은 — 읽고-수정하고-쓰는 사이에 다른 스레드가 끼어든 것이다. 그래서 그 구간(임계 영역)을 한 번에 한 스레드만 들어가게 막아야 한다 — 이게 **상호 배제(mutual exclusion)**다.

자물쇠들 — 뮤텍스·세마포어·스핀락·원자연산

상호 배제를 이루는 도구는 여럿이고, 성격이 다르다. **뮤텍스(mutex)**는 가장 기본 자물쇠다 — lock()으로 잠그고 unlock()으로 푼다. 잠근 스레드만 풀 수 있고, 다른 스레드는 잠겨 있으면 잠들어(block) 기다린다. **세마포어(semaphore)**는 카운트가 있는 신호등이다 — N개까지 동시 입장을 허용하고(N=1이면 뮤텍스처럼), P(대기, 카운트 감소)·V(신호, 증가) 연산을 쓴다. 뮤텍스와 달리 잠근 쪽과 푸는 쪽이 달라도 되어 — 생산자-소비자(한쪽이 만들고 다른 쪽이 소비)에 잘 맞는다. **스핀락(spinlock)**은 *잠들지 않고 락이 풀릴 때까지 계속 확인(바쁜 대기)*한다 — 임계 영역이 아주 짧으면 잠들었다 깨는 비용보다 싸지만, 길면 CPU를 낭비한다(짧은 임계 영역 전용). **원자 연산(atomic)**은 아예 자물쇠 없이 — compare-and-swap(CAS: "값이 여전히 10이면 11로 바꿔") 같은 하드웨어가 보장하는 단일 명령으로 끼어들 틈을 없앤다(락-프리). (출처: Mutex vs Semaphore, Spinlock vs Mutex.)

보이지 않는 함정 — 가시성과 메모리 배리어

경쟁 조건만 문제가 아니다. 현대 CPU는 각 코어의 캐시에 값을 들고 일하고 순서를 재배치하기도 해서 — 한 스레드가 바꾼 값을 다른 스레드가 한참 못 볼 수 있다(가시성 문제). 그래서 메모리 배리어로 "여기까지의 쓰기를 다른 코어에 보이게 하라"를 강제한다. 프로그래밍 언어의 가시성·순서 보장 키워드(예: 한 변수의 변경을 모든 스레드가 즉시 보게 하는 한정자)나, 데이터베이스의 격리수준도 결국 같은 질문 — "누가 무엇을 언제 보나" — 을 각자의 계층에서 다루는 것이다.

왜 이 페이지가 토대인가 — 우리가 쓰는 고수준 동기화 도구는 거의 다 이 원시 도구의 포장이다. 언어의 동기화 블록·락은 뮤텍스, 세마포어 클래스는 세마포어, 원자 정수는 CAS, 가시성 한정자는 메모리 배리어를 감싼 것이다. 공유 객체에 상태를 두지 마라(여러 스레드가 공유), 분산 락(여러 프로세스 간 상호 배제), 버전 기반 낙관적 갱신(CAS의 응용) — 전부 *"공유 자원에 동시 접근하면 막아야 한다"*는 한 원리의 변주다. 세마포어로 동시 입장 수를 N개로 제한하는 발상은 — 동시 작업 수에 상한을 두어 자원을 격리하는 패턴으로도 그대로 쓰인다.

정리하면, 동시성의 함정은 여러 스레드가 공유 데이터를 동시에 수정할 때 생기는 경쟁 조건이다(counter++도 안 원자적). 막으려면 임계 영역을 상호 배제해야 하고 — 뮤텍스(소유자만 해제), 세마포어(N개 입장·생산자/소비자), 스핀락(짧은 임계 영역·바쁜 대기), 원자 연산/CAS(락-프리)라는 성격 다른 도구를 상황에 맞게 쓴다. 가시성은 메모리 배리어로 다룬다. 그런데 이 자물쇠들을 여럿 쓰다 보면 — 서로가 서로를 기다려 영원히 멈추는 새로운 재앙이 생긴다. 그게 다음 편, 데드락이다.