점유하며 대기 (Hold-and-Wait)

핵심 인사이트 (3줄 요약)

1. 본질: 점유하며 대기 (Hold-and-Wait)는 교착 상태 발생 4조건 중 하나로, 프로세스가 최소한 하나의 자원을 이미 쥐고(Holding) 있으면서 다른 프로세스가 쥐고 있는 추가 자원을 얻기 위해 블로킹 상태로 기다리는(Waiting) 상황이다.
2. 가치: 이 조건이 충족되면 나의 진입 장벽(내가 가진 락)으로 인해 남의 진행을 막으면서, 정작 나 자신은 남의 자원 해제만을 하염없이 대기하는 동기화의 이기적 교착망이 시작된다.
3. 융합: 이 조건을 원천 부정(Prevention)하기 위해 "실행 전 모든 자원을 일괄 할당(All-or-Nothing)"하거나 "자원이 필요할 때 기존 점유 자원을 모조리 반납 후 재요청"하는 기법이 제안되었으나, 심각한 기아(Starvation) 현상과 자원 낭비율로 인해 트랜잭션 단위의 타임아웃 롤백(Timeout Rollback) 등으로 완화하여 해결한다.

Ⅰ. 개요 및 필요성

한 사람이 양손에 망치와 못을 동시에 들어야만 액자를 걸 수 있다고 가정하자. A 스레드가 망치(점유)를 들고 못을 기다리고, B 스레드가 못(점유)을 들고 망치를 기다린다면 영원히 액자를 걸 수 없다.

A가 최소한 자기가 쥔 손(망치)을 풀고(반납) 다시 줄을 서면 B가 액자를 마저 걸 텐데, 아무도 자기 손의 자원을 포기하지 않으면서 남의 자원을 더 달라고 요구할 때 발생하는 것이 점유 대기(Hold-and-Wait) 현상이다.

💡 비유: 양손 가득 짐을 든 채로, 다른 사람이 보관함 키를 주길 기다리며 입구를 가로막는 상황 — 조금이라도 짐을 내려놓고 비켜주면 상대가 키를 챙겨 나올 텐데, 절대 놓지 않고 뭉개는 이기적 대기.

┌───────────────────────────────────────────────────────────────┐
│         점유 대기 (Hold-and-Wait) 역학 비교                   │
├───────────────────────────────────────────────────────────────┤
│                                                               │
│  [일반적 실행 흐름 (No Hold-and-Wait)]                        │
│  프로세스 P1:                                                 │
│  R1 요청 → R1 사용 → R1 반납.                                 │
│  R2 요청 → R2 사용 → R2 반납.                                 │
│  → 독립적인 자원 요청으로 교착 위험도 제로.                   │
│                                                               │
│  [교착의 불씨 (Hold-and-Wait 발생)]                           │
│  프로세스 P1:                                                 │
│  R1 요청 → (R1 점유 완료!) → R2 요청(대기...)                 │
│                                                               │
│  프로세스 P2:                                                 │
│  R2 요청 → (R2 점유 완료!) → R1 요청(대기...)                 │
│                                                               │
│  결과: P1은 R1을 안 놓은 채 R2 기다림,                        │
│        P2는 R2를 안 놓은 채 R1을 기다림 → 영구 교착(Deadlock) │
└───────────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: 점유 대기는 뷔페에서 포크만 잔뜩 모아둔 채, 수프가 나오기 전까진 포크를 아무에게도 안 내어주는 얌체 행동 — 포크가 없어 수프 요리사조차 시식을 못해 주방이 스톱됩니다.

Ⅱ. 아키텍처 및 핵심 원리

점유 대기 부정 (Prevention) 기법 2가지

이론적으로 이 조건을 예방하려면, **"기다리게 될 거면 애초에 점유하지 마라"**를 코드로 강제하면 된다.

1. 일괄 할당 (All-or-Nothing):

   • 프로세스가 시작될 때, 자기가 실행 마칠 때짜지의 모든 자원(DB 연결, 파일 I/O, 프린터 등)을 한 번에 모조리 요청.
   • 단 하나라도 부족하면 어떤 자원도 받지 않고 대기(Wait) 상태 진입. (점유 자체가 아예 없음)
   • 치명적 문제: 1시간 뒤 프린터가 딱 1초 필요해도, 1시간 전부터 프린터를 독점하여 낭비 폭발.

2. 할당 전 전면 반납 (Release-and-Request):

   • "새로운 자원을 원하면, 쥐고 있는 걸 먼저 다 내려놓고 새 자원까지 리스트업 해서 다시 요청해라."
   • 치명적 문제: 상태 저장(Context)과 롤백 구현이 엄청난 오버헤드 + 특정 인기 자원을 다시 잡을 확률 저하로 심각한 기아(Starvation) 초래.

📢 섹션 요약 비유: 점유 대기 부정 기법은, 식당 가면 코스 요리 마지막 디저트 스푼까지 한 번에 못 챙기면 아예 밥을 못 먹게 시작도 안 시키는 극단적 통제 — 효율성이 땅에 떨어집니다.

Ⅲ. 융합 비교 및 다각도 분석

📢 섹션 요약 비유: 다 쥐게 해주다 탈 나면 롤백(탐지)하는 게 낫지, 못 쥐면 시작도 못 하게 하는 조건 부정은 현대 컴퓨팅에선 빈대 잡자고 초가삼간 태우는 격입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오:

1. DB Two-Phase Locking (2PL): RDBMS 에선 트랜잭션 도중 Lock을 해제하지 않고 계속 쥐어가며(Growing Phase) 점유 대기를 강력히 허용한다(격리성 보장 위해). 대신, 교착 상태를 백그라운드 스레드가 탐지하여 데드락이 터지면 그중 Victim을 타임아웃(Timeout) 에러로 찍어 눌러 강제 롤백시킨다.
2. 동적 자원 요청 최적화 앱: 필요 자원을 락 객체 배열로 묶어서 tryLock(timeout) 패턴 적용. 3초간 기다려봐서 안 되면 내 락을 다 풀고(재시도) 나갔다 돌아오는 소프트웨어 백오프(Backoff)가 가장 보편적인 타협안이다.

안티패턴:

• 블로킹 소켓 I/O를 물고 있는 락: synchronized (this) 구간 안에서 네트워크 I/O(남의 응답)를 점유하며 대기. 다른 스레드들의 서버 접근마저 끊겨버려 대형 장애 유발. 외부 타임아웃을 락 범위와 격리 설계 필요.

📢 섹션 요약 비유: 쥐고 기다리는 동안 잠들면 끝장 — "아무리 쥐고 있어봐야 내가 쥔 건 장난감, 외부 연락처 끊기면 고립무원"이라는 사실을 잊고 블로킹 락 안에 긴급 전화망까지 넣어 잠그는 꼴입니다.

Ⅴ. 기대효과 및 결론

운영체제와 프레임워크는 교착 상태 발생 조건 중 1번 상호 배제와 2번 점유하며 대기를 고차원적으로 부정하길 포기하고, 대신 자연스럽게 허용한다. 대신 3번 비선점을 파괴하거나, 4번 순환 대기(오름차순 락킹 디자인 권고)를 깨트려 동시성 성능을 이끌어 낸다. 실무에서도 점유 대기를 조건부 허용하되 tryLock() 백오프 로직을 쓰는 게 국룰이다.

📌 관련 개념 맵

👶 어린이를 위한 3줄 비유 설명

1. 점유 대기는 양손에 바나나 우유를 들고 있으면서도 초코우유를 달라고 떼쓰며 냉장고 앞을 막아서는 거예요.
2. 내가 바나나 우유를 하나라도 손에서 내려놔야 초코우유 가진 친구가 바꿔줄 텐데, 절대 놓지 않고 고집부리면 아무도 못 움직이죠!
3. 이렇게 서로 "내가 가진 건 안 줘! 근데 네 것도 내놔!" 하고 얼음 땡에서 얼음만 외치는 상황이 바로 '점유 대기'랍니다.