Quick Comparison
공유 데이터 한 묶음을 보호한다면 mutex 계열을, 동시에 사용할 수 있는 자원 수를 제한한다면 semaphore를 먼저 검토합니다.
| 기준 | Mutex | Semaphore |
|---|---|---|
| 목적 | 한 번에 한 owner가 임계 영역 사용 | 최대 N개의 동시 진입 허용 |
| 상태 | 잠김·해제와 owner 개념 | 남은 permit count |
| 대표 용도 | 공유 상태 상호 배제 | connection pool, worker slot 제한 |
| 해제 | 획득한 실행 흐름의 해제가 원칙 | API 계약에 따라 permit 반환 |
소유권과 허가권
Mutex는 보통 획득한 실행 흐름이 해제해야 한다는 owner 규칙을 가집니다. Semaphore는 permit 수를 감소시키고 반환할 때 증가시키는 counter에 가깝습니다. Binary semaphore의 count가 1이어도 mutex의 owner·abandon 처리와 완전히 같다고 볼 수 없습니다.
Semaphore에서 release 횟수가 acquire보다 많아지면 허용 동시성이 깨지거나 API 오류가 날 수 있습니다. finally, RAII, scope guard로 반환 경로를 묶습니다.
범위 선택
같은 process thread만 보호할지 여러 process 사이의 named kernel object가 필요한지에 따라 primitive 비용과 API가 달라집니다. Language runtime의 lightweight lock은 일반적으로 process 내부에서 더 저렴할 수 있습니다.
자주 틀리는 점
- semaphore를 이벤트 알림 하나와 같은 의미로 사용하지 않습니다. Permit은 누적될 수 있습니다.
- mutex 획득 순서가 여러 개면 deadlock 가능성을 함께 설계합니다.
- timeout 실패 뒤 lock을 얻었다고 가정하지 않습니다.
- 동기화 primitive 이름만 보고 memory visibility 보장을 추측하지 말고 해당 API 계약을 확인합니다.
참고 링크
2 sources