RTOS와 GPOS의 우선순위 역전(Priority Inversion) 이해하기

임베디드 분야에서 ** RTOS(실시간 운영체제) **와 ** GPOS(범용 운영체제) **는 서로 다른 설계 목표를 갖고 있습니다. 특히 우선순위 역전(Priority Inversion) 관점에서 두 시스템이 어떻게 다르게 동작하는지 살펴보겠습니다.

---

1. 우선순위 역전(Priority Inversion)이란?

우선순위 역전은 “높은 우선순위 작업(또는 스레드)이 낮은 우선순위 작업 때문에 실행되지 못하는 현상”을 말합니다.
아래 교통 시나리오로 쉽게 이해해 보겠습니다.

1. 차량 우선순위
   • 응급차(High Priority Vehicle)
   • 택시들(Medium Priority Vehicle)
   • 내 차(Low Priority Vehicle)
2. 교차로(공유 자원)
   모두가 지나야 하는 공통 구간을 “교차로”라고 가정합니다.
3. 상황 전개
   • 내 차(저우선순위)가 교차로 중앙에서 길을 막고 있습니다.
   • 여러 대의 택시(중간우선순위)가 뒤에 줄지어 있습니다.
   • 응급차(고우선순위)가 사이렌을 울리며 빠르게 교차로를 통과하려고 다가옵니다.
   그런데 “내 차”가 교차로 한가운데에 머무르고 있고, “택시들”이 내 차를 양보하지 않으면 내 차는 움직일 수 없습니다.
   응급차는 가장 높은 우선순위 차량이지만, 교차로를 비워야만 지나갈 수 있으므로 결국 기다려야만 합니다.
   이는 “높은 우선순위(응급차)가 낮은 우선순위(내 차) 때문에 실행·진행되지 못하고 지연”되는 전형적인 예시입니다.

---

2. 컴퓨터 시스템에서의 우선순위 역전

위 교통 비유를 임베디드/운영체제 관점으로 옮겨보면 다음과 같습니다.

• 낮은 우선순위 작업(Low Priority Task)
  예: 백그라운드 로깅, 통계 수집 등 비교적 긴 시간에 걸쳐 수행해도 되는 작업
• 중간 우선순위 작업(Medium Priority Task)
  예: 주기적인 센서 샘플링, 디스플레이 업데이트 등 그럭저럭 안정적인 타이밍만 보장되면 되는 작업
• 높은 우선순위 작업(High Priority Task)
  예: 안전 제어(에어백 전개), 모터 제어, 알람 발생 등 지연되면 치명적인 결과가 발생할 수 있는 작업
• 공유 자원(Shared Resource)
  예: 공용 버퍼, 뮤텍스(Mutex)로 보호된 주변 장치—예컨대 SPI 버스 등

1. 낮은 우선순위 작업이 어떤 뮤텍스(Mutex)를 획득하여 공유 자원을 사용 중이라고 가정합니다.
2. 중간 우선순위 작업들이 계속해서 CPU를 점유하며 돌아갑니다. 낮은 우선순위 작업은 CPU를 얻지 못해 공유 자원을 해제하지 못한 채 대기합니다.
3. 높은 우선순위 작업이 실행 준비(Ready) 상태가 되자마자 CPU를 선점해야 하지만, 낮은 우선순위 작업이 공유 자원을 놓지 않아 실질적으로 지연됩니다. 즉, 중간 우선순위 작업이 낮은 우선순위 작업보다 CPU 점유를 우선시해, “높은 우선순위 작업이 → 중간 우선순위 작업 → 낮은 우선순위 작업” 순으로 블록된 상태가 됩니다.

이처럼 높은 우선순위 작업이 무조건 처리되어야 할 시점에, 낮은 우선순위 작업이 뮤텍스를 해제하지 못해 공유 자원을 갖고 있는 상황이 발생하면 ‘우선순위 역전’이 발생합니다.

---

3. GPOS(범용 OS) vs RTOS(실시간 OS)의 차이점

3.1 GPOS(범용 운영체제)는 우선순위 역전이 “큰 문제”가 아니지만…

• 스케줄링 목표: 높은 처리량(Throughput)
  GPOS(예: Windows, Linux, macOS 등)는 “가능한 많은 프로세스를 빠르게 처리”하는 데 중점을 둡니다.
  따라서, 중간 우선순위 작업이 CPU 자원을 먼저 차지하더라도, 시스템 전반적인 처리량이 높아지는 편이 더 중요합니다.
• 스케줄링 정책:
  • **공정성(Fairness)**을 바탕으로 우선순위를 어느 정도 반영하되, 중간/저우선순위 프로세스에게도 실행 기회를 충분히 줍니다.
  • 고우선순위 작업이라 할지라도, 다른 셀 수 없이 많은 데몬(백그라운드 프로세스)들이 실행 중이라면 실제로 CPU를 받기까지 기다려야 할 수 있습니다.
  결과적으로 GPOS 환경에서는 우선순위 역전이 일어나더라도 전체 시스템에 큰 치명적 장애를 주지는 않습니다.
  단지 일시적으로 기대치보다 응답 속도가 느려질 뿐, 사용자 경험 관점에서 “아, 버벅이네?” 수준에 그치는 경우가 많습니다.

---

3.2 RTOS(실시간 운영체제)는 우선순위 역전을 “절대 피해야 하는 문제”

• 스케줄링 목표: 실시간성(Deterministic Real-Time)
  RTOS는 “요구된 시점 내에 반드시 작업이 완료되어야”만 제대로 동작합니다.
  동작이 지연되면 제어 신호가 늦어져 시스템이 완전히 실패할 수 있으며, 예컨대 자동차 에어백이나 산업용 로봇 제어 같은 안전·보안 중시 애플리케이션에서는 곧바로 재앙을 불러옵니다.
• 스케줄링 정책:
  • 우선순위 선점형(Priority Preemptive) 스케줄러를 기본으로 사용합니다.
  • CPU는 언제나 가장 높은 우선순위 작업에게 점유 기회를 부여합니다. (단, 자원 보호를 위해 최소한의 임계 영역(Critical Section)만 잠금)
  • 우선순위 역전 문제를 해결하거나 완화하는 다양한 기법(예: 우선순위 상속(Priority Inheritance), 우선순위 천장(Priority Ceiling), 작업-대리(Task Proxy) 기법 등)을 반드시 도입합니다.

1) 우선순위 상속(Priority Inheritance)

• 개념: 한 작업(Low Priority Task)이 뮤텍스(Mutex)를 획득하여 공유 자원을 점유하고 있을 때, 더 높은 우선순위 작업(High Priority Task)이 해당 뮤텍스를 요청하면,
  -뮤텍스를 점유 중인 낮은 우선순위 작업에게 높은 우선순위를 임시로 부여합니다.
• 효과: 낮은 우선순위 작업이 빠르게 CPU를 받아 공유 자원을 빨리 해제함으로써, 높은 우선순위 작업이 지연되는 시간을 최소화합니다.
• 풀 흐름:
  1. L 작업(우선순위 1)이 뮤텍스 A 잠금
  2. H 작업(우선순위 3) 뮤텍스 A 요청 → H는 블록 상태
  3. M 작업(우선순위 2) CPU 점유 → L은 CPU 기회를 받지 못함 → H 장기간 대기
  4. 우선순위 상속 발생! → L 작업에게 우선순위 3을 임시 부여
  5. L 작업이 공유 자원을 빨리 해제하고 뮤텍스 반납 → L 본래 우선순위(1)로 복원
  6. H 작업이 즉시 CPU를 받아 실행

2) 우선순위 천장(Priority Ceiling)

• 개념: 리소스당 “우선순위 천장” 값을 미리 정해 놓고, 임계 영역을 실행하는 작업은 시스템 전체 우선순위가 천장 이상으로 올라갑니다.
• 효과: 특정 공유 자원을 점유 중인 동안 다른 작업이 그 자원을 요청하여 우선순위 역전이 발생하는 것을 근본적으로 방지합니다.
• 설정 예시:
  • 뮤텍스 A → 우선순위 천장 = 3
  • 뮤텍스 B → 우선순위 천장 = 2
  • L 작업(우선순위 1)이 A를 잠금 → L은 즉시 우선순위 3이 되어 실행
  • H 작업(우선순위 3)이 A를 요청해도, “천장 우선순위” = 3이므로 우선순위 역전 발생 없음

---

4. RTOS가 갖춘 우선순위 역전 완화 기술

RTOS는 아래 세 가지 주요 기법을 제공하거나 응용하여 실시간성을 보장합니다.

1. 우선순위 선점형 스케줄링 (Priority Preemptive Scheduling)
   • 항상 “실행 준비(Ready) 상태 중 가장 높은 우선순위 작업”에게 CPU 사용 권한을 넘깁니다.
   • Critical Section(임계 영역) 내에서도 필요 최소한으로만 인터럽트를 비활성화하여 응답 지연 최소화.
2. 우선순위 상속(Priority Inheritance)
   • 공유 자원을 점유 중인 낮은 우선순위 작업이, 더 높은 우선순위 작업에 의해 지연될 경우, 낮은 우선순위 작업에게 해당 작업 우선순위를 잠시 물려줌 → 자원 반납 속도 향상.
3. 우선순위 천장(Priority Ceiling)
   • 공유 자원별로 미리 천장 우선순위를 설정 → 어떤 작업이 해당 자원을 잠그면, 그 작업 우선순위를 천장으로 올려놓고 실행 → 자원 점유 중 다른 작업에 의한 대기 방지.

이러한 기법들을 적절히 조합·활용함으로써 RTOS는 우선순위 역전 상황에서도 ‘긴급 작업이 최대한 빨리 실행되도록’ 보장합니다.

---

5. GPOS와 RTOS의 특징 비교 정리

구분 GPOS (범용 OS) RTOS (실시간 OS)

최우선 목표	시스템 전반의 처리량(Throughput) 극대화	작업의 기한(Deadline) 내 실행 보장 (Determinism)
스케줄러 정책	공정성(Fairness) / 다중 레벨 피드백 큐 등	우선순위 선점형(Highest Priority First)
우선순위 역전	상대적으로 큰 문제 아님 (처리량 최적화)	치명적인 문제 → 우선순위 상속/천장으로 해결 필요
인터럽트 지연(Interrupt Latency)	시스템 부하에 따라 비례적으로 증가할 수 있음	짧고 일정하게(예: 수μs~수십μs) 제한됨
스케줄링 지연(Context Switch Latency)	부하 증가 시 변동폭 큼 (수 ms~수십 ms)	결정론적(Deterministic)으로 짧고 변동 적음 (수μs~수 ms)
임계 구역 실행	비교적 길게 인터럽트 비활성화 가능 → 우선순위 역전 일어나더라도 시스템 안정 위주	가능한 최소 길이만 인터럽트 비활성화 → 실시간성 유지
사용 분야	데스크톱, 서버, 일반 임베디드(속도·기능 강조)	자동차, 항공, 산업제어, 의료기기 등 안전·실시간 요구 시스템

---

6. 마무리: “왜 RTOS에서 우선순위 역전이 반드시 해결되어야 하는가?”

• GPOS
  • ‘많은 프로세스를 동시에 돌린다’는 목표로 설계되어 있으며, 우선순위 역전 발생 시에도 전체 처리량을 더 중시합니다.
  • 결과적으로 데스크톱 환경에서 일시적인 지연 정도는 큰 문제가 되지 않습니다.
• RTOS
  • ‘엄격한 기한 내부에 작업을 끝내야 한다’는 보장을 제공해야 하므로, 우선순위 역전은 시스템 전체 신뢰성에 치명적입니다.
  • 따라서 상술한 우선순위 상속, 우선순위 천장 등의 기법을 통해 “높은 우선순위 작업이 최대한 빨리 실행”되도록 반드시 설계합니다.

모바일 기기나 범용 임베디드(Linux 기반 Android 등)는 실시간성보다는 풍부한 기능과 편의성, 처리량을 우선시합니다. 반면 항공기 제어, 자동차 안전 시스템, 산업용 로봇, 의료 장비 등은 “단 1ms의 지연도 치명적”일 수 있으므로 RTOS가 반드시 필요합니다.

요약

• 우선순위 역전은 “높은 우선순위 작업이 낮은 우선순위 작업 때문에 실행되지 못하는 현상”
• GPOS는 처리량 최적화 관점으로 설계되므로 우선순위 역전이 발생해도 큰 차질이 없지만,
• RTOS는 기한 내에 반드시 작업을 처리해야 하므로 우선순위 역전을 절대 허용하지 않고 우선순위 상속/천장 등의 기법으로 해결해야 함

이렇게 RTOS와 GPOS가 “우선순위 역전”을 대하는 방법의 차이를 이해하면, 앞으로 RTOS 기반 시스템을 설계·개발할 때 왜 특정 기법을 필수로 도입해야 하는지 더 분명해질 것입니다.