우선순위 상속 (Priority Inheritance, PI)

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

본질: 우선순위 상속 (Priority Inheritance)은 공유 자원의 락(Lock)을 쥐고 있는 저순위 태스크(L)의 우선순위를, 그 락을 기다리는 고순위 태스크(H)의 우선순위만큼 일시적으로 끌어올려주는(승급시켜 주는) 동기화 구제 프로토콜이다.

가치: 실시간 시스템에서 데드라인을 박살 내는 주범인 '우선순위 역전 (Priority Inversion)' 현상을 가장 적은 오버헤드로 완벽하게 차단하여, 중간 순위(M) 태스크가 락 해제를 방해하는 것을 물리적으로 불가능하게 만든다.

융합: 소유권(Ownership)의 개념이 없는 세마포어(Semaphore)에서는 절대 구현할 수 없으며, 오직 "누가 잠갔는지"를 명확히 추적할 수 있는 뮤텍스(Mutex) 환경에서 OS 커널 스케줄러와 깊게 결합(PREEMPT_RT 패치 등)되어야만 동작하는 정밀한 아키텍처다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 스케줄러가 동기화 객체(Mutex)의 대기열을 감시하다가, 우선순위가 높은 프로세스가 락을 요청하며 대기(Block) 상태에 빠지는 순간, 현재 그 락을 쥐고 있는 낮은 우선순위 프로세스에게 높은 프로세스의 우선순위 번호를 '상속(Inheritance)'하여 복사해 주는 매커니즘이다. 락을 푸는 순간 상속받은 권력은 즉시 반납된다.
필요성: 화성 탐사선 패스파인더의 무한 리셋 버그에서 증명되었듯, 락을 쥔 저순위(L)가 중순위(M)에게 CPU를 빼앗기면, 고순위(H)는 M이 끝날 때까지 락을 못 얻고 멈춰버린다. 고순위(H)가 자력으로 이 굴레를 깰 방법이 없으므로, 커널이 개입하여 "L이 빨리 락을 풀 수 있게 L에게 M을 이길 수 있는 방패(H의 우선순위)를 잠시 빌려주어야" 했다.
💡 비유: VIP(H)가 급하게 식당 룸을 써야 하는데, 말단 직원(L)이 먼저 룸을 쓰고 있다. 직원이 빨리 밥을 먹고 나와야 하는데 과장(M)이 밖에서 직원에게 계속 잡일을 시킨다. 이때 VIP가 **"얘 지금 내 심부름(상속) 하는 거니까 과장 넌 건드리지 마!"**라고 말단 직원에게 자신의 명찰을 씌워주어 과장을 물리치는 것과 같다.
등장 배경: 1990년 Sha, Rajkumar, Lehoczky의 기념비적 논문에서 처음 정립되었다. 기존에는 락을 쥐자마자 무조건 우선순위를 최고로 올려버리는 무거운 PCP(Priority Ceiling Protocol)를 썼으나, "문제가 발생했을 때(H가 대기할 때)만 임시로 올려주자"는 가볍고 지연된(Lazy) 방식인 PIP가 등장하며 현대 POSIX 스레드(Pthreads)의 실시간 표준(rt_mutex)으로 등극했다.

  [우선순위 상속(PI)이 역전 현상을 파괴하는 매커니즘 시각화]

  (상황: 락을 쥔 L(우선순위 10), 락을 대기하는 H(우선순위 1))
  
  ▶ 1단계: H가 락을 요청하며 Block됨.
            커널 스케줄러 개입! "어? 1등이 10등을 기다리네?"
  
  ▶ 2단계 (상속 발동): 커널이 L의 우선순위를 10에서 [ 1 ]로 강제 뻥튀기함.
            (L은 이제 H와 동급의 무적 방패를 얻음)
            
  ▶ 3단계 (방어): 중간 순위 M(우선순위 5)이 도착하여 CPU를 뺏으려 시도함.
            하지만 L의 현재 순위가 1이므로 M은 L을 이길 수 없어 쫓겨남!
            
  ▶ 4단계 (해결): M의 방해를 받지 않은 L이 초고속으로 연산을 마치고 락(Lock) 해제.
            락 해제 즉시 L은 원래의 찌질한 10으로 [강등]됨.
            
  ▶ 5단계 (정상화): 기다리던 H가 즉시 락을 획득하고 연산 시작! (데드라인 세이브)

[다이어그램 해설] 상속의 핵심은 "문제가 생겼을 때만(On-demand)" 권력을 융통해 준다는 점이다. H가 오기 전까지 L은 그냥 10등이었다. M이 와도 H가 없으면 L은 M에게 자리를 내주는 게 맞다. 오직 "H가 L을 기다릴 때"만 상속이 터지므로, 스케줄링의 본래 계급 체계를 최대한 덜 훼손하면서도 치명적 버그를 완벽하게 막아내는 극도의 효율성을 보여준다.

📢 섹션 요약 비유: 평소에는 평범한 시민(L)이지만, 암행어사(H)의 길 안내를 맡은 순간만큼은 암행어사의 마패(상속)를 빌려 받아, 동네 사또(M)가 앞길을 막아도 "어사 출두야!"를 외치며 뚫고 지나갈 수 있는 특권입니다. 목적지에 도착해 마패를 반납하면 다시 평범한 시민으로 돌아갑니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

재귀적 상속 (Transitive Priority Inheritance)

실무 시스템에서는 락 하나만 잡는 게 아니라, 락 A를 잡은 상태에서 락 B를 또 잡는(Nested Lock) 끔찍한 꼬임이 빈번하다. 이때 커널은 어떻게 대처할까?

상황: L1이 락 A를 쥠. ─▶ L2가 락 B를 쥐고 락 A를 대기 중. ─▶ H가 락 B를 대기 중.
동작: H가 L2를 기다리므로 L2의 우선순위가 H급으로 치솟는다. 그런데 L2는 지금 L1을 기다리고 있다!
재귀적 전파: 커널은 L2가 높아진 권력을 다시 L1에게 **연쇄적으로 전파(Transitive)**한다. 결국 L1도 H급으로 승급하여 가장 밑바닥 병목부터 초고속으로 뚫어낸다.

뮤텍스(Mutex)의 소유권(Ownership) 절대 법칙

우선순위 상속이 작동하기 위한 유일무이한 하드웨어/소프트웨어적 전제 조건이다.

동기화 기법	소유권 (Ownership) 존재 여부	상속 (PI) 가동 가능성
세마포어 (Semaphore)	없음. A스레드가 `wait()` 하고 B스레드가 `signal()` 할 수 있음.	❌ 절대 불가. H가 기다릴 때, 누가 락을 풀지 모르므로 누구의 우선순위를 올려줘야 할지(타깃) 커널이 찾을 수 없다.
뮤텍스 (Mutex)	있음. 잠근 놈(Owner)이 아니면 절대 풀 수 없음.	✅ 가동 가능. 커널이 `mutex->owner` 포인터를 보고 즉시 그 스레드의 멱살을 잡아 우선순위를 끌어올린다.

따라서 실시간 시스템 개발자가 "우선순위 역전을 막겠다"고 세마포어를 쓰면 시스템이 폭발한다. 반드시 POSIX의 pthread_mutex_t를 사용하고 속성에 PTHREAD_PRIO_INHERIT를 명시해야 한다.

📢 섹션 요약 비유: 세마포어는 비밀번호가 걸린 공중화장실입니다. 안에 누가 있는지 모르니까, 밖에 VIP가 와도 누구한테 마패를 던져줄지 모릅니다. 뮤텍스는 직원 사원증을 찍어야 열리는 화장실이라서, VIP가 "아, 김대리가 안에 있네! 김대리 승진!" 하고 정확히 타겟팅해서 권력을 줄 수 있습니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

우선순위 상속(PIP) vs 우선순위 천장(PCP)

동기화 문제를 푸는 양대 프로토콜의 차이다. PIP는 "맞고 나서 치료하기"이고, PCP는 "애초에 안 맞게 예방하기"다.

특성	PIP (상속 프로토콜)	PCP (천장 프로토콜 / Priority Ceiling)
발동 시점	고순위 태스크가 실제로 락을 요청(대기)할 때 사후 발동	저순위 태스크가 락을 쥐는 그 순간 즉시 사전 발동
승급 목표치	날 기다리는 놈의 우선순위와 똑같이 맞춤	이 락을 쓸 수 있는 잠재적 놈들 중 가장 높은 순위(천장)로 풀업
장점	커널 오버헤드가 적고 구현이 자연스러움	데드락(Deadlock)과 체인 블로킹을 수학적으로 100% 예방함
단점	연쇄적인 락 요청 시 데드락 발생 위험 존재	락을 쥐자마자 VIP가 되어버리므로 시스템 전체의 응답성이 경직됨
채택 환경	범용 리눅스(PREEMPT_RT), Java, Windows	엄격한 항공우주 RTOS (Ada 언어, OSEK/VDX 표준)

상속(Inheritance)의 어두운 그림자: 푸시-풀(Push-Pull) 오버헤드

우선순위를 올려주는(Push) 것도 일이고, 락을 풀었을 때 다시 원래 찌질한 계급으로 돌려놓는(Pull) 것도 일이다. 특히 재귀적 락(L1 -> L2 -> H)이 10개쯤 얽혀있을 때 H가 락을 요청하면, 커널은 10개의 스레드를 줄줄이 타고 내려가며 우선순위를 갱신하는 $O(N)$의 거대한 락 그래프 탐색을 수행해야 한다. 이는 디스패치 지연(Dispatch Latency)을 튀게 만드는 커널 내부의 또 다른 폭탄이다.

📢 섹션 요약 비유: PIP(상속)는 불이 나면(역전) 그때 소방차를 부르는 방식이고, PCP(천장)는 성냥을 켜는 순간(락 획득) 즉시 건물 전체에 스프링클러를 터뜨려버리는 극단적 예방책입니다. 소방차 부르는 시간(오버헤드)이 아까우면 PCP를 쓰고, 물바다(시스템 경직)가 싫으면 PIP를 씁니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무 시나리오

리눅스 PREEMPT_RT 패치의 rt_mutex 도입: 리눅스가 실시간 성능을 얻기 위해 가장 피를 토하며 갈아엎은 부분이 바로 커널 내부의 스핀락(Spinlock)들을 rt_mutex로 바꾼 것이다. rt_mutex는 이름 그대로 실시간(RT)을 위해 만들어졌으며, 내부에 PI(우선순위 상속) 알고리즘이 하드코딩되어 있다. 따라서 커널 내부에서 블록 디바이스 드라이버나 파일 시스템을 건드릴 때, 이 rt_mutex 덕분에 커널 데몬들의 우선순위가 춤을 추며 서로의 길을 즉각 터주는 기적이 일어난다.
C++ / Java 실무 코드에서의 PI 설정 누락 버그: 수년 차 백엔드 시니어 개발자도 흔히 하는 실수다. pthread_mutex_init()을 호출할 때 속성(attr)에 PTHREAD_PRIO_INHERIT를 명시하지 않으면, 커널은 성능을 아끼기 위해 기본적으로 PI를 꺼버린다(None 모드). 이 상태에서 스트레스 테스트(Load Test)를 돌리면 가끔 이유 없이 API 지연(Latency)이 10초씩 튀는 구간이 발견되는데, 이것이 100% 확률로 상속이 안 터져서 발생한 숨겨진 우선순위 역전 버그다.

  ┌──────────────────────────────────────────────────────────────────┐
  │     안전한 실시간 멀티스레딩(동기화) 아키텍처 설계 의사결정      │
  ├──────────────────────────────────────────────────────────────────┤
  │                                                                  │
  │   [요구사항: 3개의 스레드가 1개의 설정(Config) 구조체를 공유함]  │
  │                │                                                 │
  │                ▼ 스레드 간의 우선순위가 동일한가?                │
  │      [ 예 (모두 같은 일반 스레드) ]                              │
  │       ├─▶ 판단: 우선순위 역전이 구조적으로 발생 불가             │
  │       └─▶ 설계: 일반 Mutex나 Spinlock 편하게 사용                │
  │                                                                  │
  │      [ 아니오 (H, M, L 등 계급이 나뉘어 있음) ]                  │
  │       ├─▶ 🚨 경고: M 스레드가 L을 짓밟고 H를 멈추게 할 위험!     │
  │       │                                                          │
  │       ▼ (해결책 분기)                                            │
  │       1. 최고 존엄: Lock-free (RCU 등) 자료구조 사용 (락 제거)   │
  │       2. 차선책: PI(Priority Inheritance) 속성을 켠 Mutex 사용   │
  │       3. 절대 금지: Semaphore, PI 없는 기본 Mutex, Spinlock      │
  └──────────────────────────────────────────────────────────────────┘

[다이어그램 해설] "우선순위가 다른 스레드들이 락을 공유한다"는 문장 자체에서 아키텍트는 사이렌을 울려야 한다. 스케줄러가 아무리 완벽해도 락 앞에서는 무용지물이 되기 때문이다. 최선의 아키텍처는 아예 락을 없애는 것(RCU, Lock-free)이고, 차선책이 바로 OS가 제공하는 PI 기능을 믿고 뮤텍스 속성을 켜는 것이다.

📢 섹션 요약 비유: 신분(우선순위)이 다른 사람들이 같은 문(Lock)을 써야 한다면, 회전문(Lock-free)을 만들어서 부딪히지 않게 하거나, 그게 안 되면 신분이 높은 사람이 문을 열어줄 수 있는 마스터키(PI Mutex)를 달아놓아야 합니다. 그냥 일반 자물쇠(기본 Mutex)를 달아놓으면 신분이 꼬여서 대형 사고가 납니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

기대효과

우선순위 상속(PI)을 시스템에 올바르게 체결하면, 고순위 태스크가 겪을 수 있는 블로킹 시간이 "자신이 요청한 락을 쥔 저순위 태스크들의 연산 시간의 합"으로 완벽히 수리적으로 제한(Bounded)된다. 무한 대기라는 블랙박스가 걷히고, 데드라인 100% 사수라는 RTOS의 본질이 완성된다.

결론 및 미래 전망

우선순위 상속은 스케줄링(CPU 분배)과 동기화(자원 보호)라는 운영체제의 두 거대한 기둥이 서로의 모순을 해결하기 위해 악수(합의)를 맺은 가장 극적인 결합 포인트다. 현재 안드로이드의 Binder IPC(프로세스 간 통신) 메커니즘도 호출하는 클라이언트의 우선순위를 백그라운드 서비스 프로세스에게 통째로 상속해 주는 등 범용 시스템 전반에 이 철학이 깊게 이식되었다. 미래에는 소프트웨어가 락(Lock)을 잡고 우선순위를 조작하는 무거운 오버헤드를 아예 하드웨어 단으로 내리기 위해, CPU 코어 내부에 **HTM (Hardware Transactional Memory)**을 탑재하여 락 자체가 필요 없는 궁극의 하드웨어 트랜잭션 동기화 시대로 넘어가고 있다.

📢 섹션 요약 비유: 우선순위 상속은 스케줄러와 자물쇠가 만든 위대한 조약이었습니다. 하지만 조약은 서류 작업(오버헤드)이 많아 귀찮습니다. 미래에는 아예 자물쇠를 없애고, 충돌 나면 시간을 되돌려버리는 마법의 문(하드웨어 트랜잭셔널 메모리)으로 건물을 짓는 시대로 인류는 나아가고 있습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
우선순위 역전 (Priority Inversion)	상속(PI) 프로토콜이 태어난 유일한 이유이자, 반드시 칼을 찔러 죽여야 하는 타깃 버그다.
뮤텍스 (Mutex)	누가 자원을 쥐고 있는지 '소유권'을 기록해 두어, 커널이 상속의 대상을 정확히 찾게 해주는 유일한 동기화 객체다.
세마포어 (Semaphore)	소유권이 없어서 우선순위 상속을 절대 쓸 수 없게 만드는, 실시간 시스템의 절대 악이자 기피 대상이다.
실시간 커널 (PREEMPT_RT)	리눅스가 실시간성을 쟁취하기 위해 커널 내부의 스핀락을 뜯어내고 상속이 내장된 rt_mutex로 피 터지게 도배한 결과물이다.
우선순위 스케줄링 (Priority)	이 상속이라는 개념 자체가 성립하기 위해 전제되어야 하는 "계급 사회" 스케줄링 철학이다.

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

사장님이 청소부 아저씨가 쓰고 있는 화장실 앞에서 빨리 나오라고 발을 동동 구르고 있어요 (우선순위 역전 위기).
그런데 밖에서 중간 관리자가 청소부 아저씨에게 "화장실 안에 들어가서 전구도 좀 갈아!"라며 자꾸 딴일을 시켜서 아저씨가 못 나오고 있어요.
이때 사장님이 청소부 아저씨에게 **"지금부터 너도 사장이야! 관리자 무시하고 원래 하던 청소만 딱 끝내고 나와!"**라며 파워(우선순위)를 잠시 빌려주어 문제를 시원하게 해결하는 마법이랍니다!