Priority Inversion이란? 높은 우선순위 작업이 낮은 우선순위 작업 때문에 늦어지는 이유 쉽게 이해하기
Priority Inversion은 High가 Low의 Lock 때문에 막히고 Medium이 Owner를 밀어내며 실제 처리 순서가 뒤집히는 현상입니다. Priority Inheritance·Critical Section·Bulkhead까지 초보 기준으로 정리합니다.
Priority는 보통 `H > M > L`처럼 High를 먼저 돌리려는 약속입니다. 그런데 High `H`가 필요한 Lock을 이미 Low `L`이 갖고 있으면 `H`는 기다려야 합니다. 여기까지는 평범한 Lock 대기입니다. 문제는 그 사이 Medium `M`이 CPU를 계속 쓰는 경우입니다. `H`는 Block이라 Scheduler가 못 돌리고, `M`은 `L`보다 Priority가 높아 `L`을 밀어냅니다. `L`이 Lock을 못 푸니 `H`도 계속 기다립니다. 결과적으로 가장 급한 `H`가 `M`보다 늦게 처리됩니다. 좁은 골목의 트럭(L)을 구급차(H)가 기다리는데, 일반 승용차(M)들이 트럭의 빠져나감을 방해하는 비유와 같습니다. 이것이 Priority Inversion(우선순위 역전)입니다.
약속: H > M > L 실제: L이 Lock 보유 → H Block → M이 L을 밀어냄 → H 지연
Priority Inheritance · Ceiling · Deadlock·Starvation
대표 완화는 Priority Inheritance입니다. `H`가 `L`의 Lock을 기다리면 `L`의 Priority를 일시적으로 `H` 수준까지 올려 `M`보다 먼저 실행되게 합니다. Lock을 풀면 원래 Priority로 돌아갑니다. 「내가 기다리니 네 Critical Section을 빨리 끝내」라고 Priority를 빌려주는 셈입니다. Priority Ceiling은 Resource를 잡는 순간 미리 정해 둔 높은 Ceiling을 적용하는 Real-Time 기법으로 Inheritance와는 타이밍이 다릅니다. 모든 Mutex가 Inheritance를 자동 지원하지는 않습니다. Deadlock은 서로 기다려 진행 불가, Inversion은 Owner가 실행되면 결국 진행 가능합니다. Starvation은 특정 작업이 계속 기회를 못 얻는 문제이고, Inversion이 심하면 `H` 입장에선 Starvation처럼 보일 수 있습니다. Nested Lock·Transitive Inheritance·Chain Blocking은 Dependency가 여러 단계로 이어질 때 더 복잡해집니다.
Inheritance: H 대기 → L Priority↑ → L 실행 → unlock → H 실행 Ceiling: Resource 획득 시 미리 높은 Priority 적용
Critical Section · 웹·DB · 모니터링
Shared Resource가 없으면 Scheduler가 `L`을 Preempt하고 `H`를 바로 돌리면 됩니다. 문제는 `H`가 `L`의 결과에 의존할 때입니다 — Contention과 Dependency입니다. Lock 안에서 외부 API·긴 I/O를 하면 Blocking이 커집니다. Critical Section은 짧게, I/O는 가능하면 Lock 밖입니다. OS Thread Priority를 직접 안 다뤄도, 긴급 API가 Background Job의 DB Row Lock을 기다리거나 High Queue가 Low 선행 작업에 묶이면 같은 구조입니다. High/Low Worker를 나누는 것은 Bulkhead와 Isolation↔Utilization Trade-off입니다. Timeout은 피해를 제한할 뿐 근본 원인(긴 Lock)은 남습니다. Lock Wait·Owner·Priority별 Tail을 모니터링하고, Distributed Tracing에서 「계산 20ms + Lock Wait 4.8초」처럼 쪼갭니다. Inheritance로 Priority가 바뀌면 Context Switch가 날 수 있어 비용이 있지만 Real-Time Correctness에는 필요할 수 있습니다. Bounded Inversion — Critical Section 최대 시간을 알면 Worst-Case를 분석하기 쉽습니다. SEO 전용 개념은 아닙니다.
완화 요약 Priority Inheritance / Ceiling Critical Section 단축 · Shared State 감소 Dependency-Aware Scheduling · Pool 분리 Lock/Transaction Timeout · 모니터링
자주 묻는 질문
Priority Inversion이란?
높은 Priority가 낮은 Priority가 가진 Resource 때문에 Block되고, Medium이 Owner를 밀어내며 High가 예상보다 늦어지는 현상입니다.
왜 High가 Low를 기다리나?
High가 필요로 하는 Shared Resource(Lock 등)를 Low가 이미 보유하고 있기 때문입니다.
Medium이 왜 문제인가?
High는 Block이라 못 돌고, Medium은 Low보다 높아 Low의 실행을 미뤄 Lock 해제를 늦춥니다.
Priority Inheritance란?
High가 기다리는 Resource Owner(Low)의 Priority를 일시적으로 올려 빨리 unlock 하게 하는 기법입니다.
Deadlock과 같나?
아닙니다. Inversion은 Owner가 CPU를 받으면 진행 가능하고, Deadlock은 서로 기다려 진행 불가입니다.
웹에서도 생기나?
OS Thread Priority 형태는 드물지만, 긴급 요청이 Background Job의 DB Lock·공유 Pool에 묶이면 비슷한 Dependency가 납니다.
정리
Priority Inversion = High가 Low의 Resource 때문에 기다리며 실제 처리 순서가 뒤집히는 현상입니다. `H`를 빨리 끝내려면 역설적으로 `L`을 먼저 실행시켜야 합니다. Priority Inheritance·짧은 Critical Section·Dependency 인식 Scheduling·Pool 분리로 완화합니다. Priority 숫자만으로는 Deadline이 보장되지 않습니다. Shared Resource와 Lock Dependency까지 함께 봐야 합니다. 여러 Thread가 하나의 CPU를 나눌 때 운영체제는 Priority만 보는 것이 아니라, 지금 누구를 얼마나 돌리고 언제 바꿀지도 계속 결정합니다. 이처럼 여러 Process·Thread 중 어떤 작업에 CPU 시간을 배분할지 정하는 과정을 CPU Scheduling(프로세서 스케줄링)이라고 합니다.