RTOS에서 우선순위 역행을 다루는 방법
RTOS의 공유 자원 경쟁에서 발생하는 우선순위 역행의 흐름과 Deadline 위반 위험, Priority Inheritance 및 Priority Ceiling 선택 기준을 정리한다.
2026-08-14 · 최초 발행 2025-12-30
높은 우선순위 Task가 멈추는 순간
우선순위 역행(Priority Inversion)은 높은 우선순위 Task가 낮은 우선순위 Task보다 늦게 실행되는 실시간 스케줄링 문제다. 낮은 우선순위 Task가 공유 자원을 잡고 있는 동안 높은 우선순위 Task가 그 자원을 요청하면 대기 상태가 된다. 이때 자원을 쓰지 않는 중간 우선순위 Task까지 실행되면, 높은 우선순위 Task는 자신보다 낮은 우선순위 Task들의 실행 순서에 묶인다.
RTOS에서는 이 지연이 단순한 성능 저하가 아니라 Deadline 미달로 이어질 수 있다.
공유 자원을 둘러싼 실행 순서
다음 조건을 둔다.
- Task A: 높은 우선순위
- Task B: 중간 우선순위
- Task C: 낮은 우선순위
- 공유 자원 R: 세마포어 또는 뮤텍스로 보호
Task C가 자원 R을 획득한 뒤 임계영역을 실행한다. 이후 Task A가 Ready 상태가 되어 Task C를 선점하지만, 자원 R이 필요하므로 Blocked 상태가 된다. Task C가 다시 실행되어 자원을 사용하던 중 Task B가 Ready 상태가 되면, Task B는 Task C를 선점할 수 있다. Task B는 자원 R이 필요하지 않아도 실행을 계속한다.
Task B가 종료된 뒤에야 Task C가 다시 실행되어 자원 R을 해제하고, 그제야 Task A가 실행된다. 결과적으로 Task A는 Task B보다 늦게 처리된다.
자원 보유 시간이 지연을 키우는 구조
상호배제는 한 번에 하나의 Task만 임계영역에 진입하게 한다. 세마포어와 뮤텍스는 이런 공유 자원 보호에 사용된다. 문제는 자원을 보유한 낮은 우선순위 Task가 자원을 해제하기 전까지 높은 우선순위 Task가 기다려야 한다는 점이다.
비선점 환경에서는 자원을 소유한 Task가 스스로 해제할 때까지 높은 우선순위 Task도 대기한다. 임계영역이 길어질수록 다른 Task의 대기 시간도 길어진다. 여기에 중간 우선순위 Task가 낮은 우선순위 Task를 선점하면, 자원을 해제할 주체의 실행 자체가 밀린다.
Deadline 위반으로 번지는 영향
실시간 제약을 만족해야 하는 환경에서는 대기 시간이 예측되지 않는다는 점이 특히 위험하다. Deadline을 넘기면 Hard Real-Time 시스템에서는 시스템 실패 가능성으로 이어질 수 있다. 항공기 제어 시스템, 의료 기기, 산업 자동화가 여기에 해당한다.
무한정 우선순위 역행(Unbounded Priority Inversion)이 발생하면 높은 우선순위 Task의 대기 시간을 예측할 수 없다. 최악의 경우 무한 대기로 이어지고, 시스템은 응답 불가 상태나 데드락과 유사한 상태에 빠질 수 있다.
대기 시점에 우선순위를 넘겨주는 Priority Inheritance
Priority Inheritance는 낮은 우선순위 Task가 자원을 보유한 상태에서 높은 우선순위 Task가 그 자원을 기다릴 때, 자원 보유 Task의 우선순위를 일시적으로 올리는 방식이다.
Task C가 자원 R을 획득한 뒤 Task A가 자원 R을 요청하면 Task A는 대기한다. 이때 Task C의 우선순위는 Task A 수준으로 올라간다. 따라서 Task B는 Task C를 선점할 수 없고, Task C는 자원 R을 해제한 뒤 원래 우선순위로 돌아간다. 이후 Task A가 실행된다.
이 방식은 구현이 간단하고 중간 우선순위 Task의 간섭을 막아 대기 시간을 줄인다. 반면 자원 의존성이 이어질 경우 연쇄적 상속(Transitive Inheritance)이 발생할 수 있으며, 우선순위를 변경하는 오버헤드가 있다.
자원 획득 때부터 막는 Priority Ceiling
Priority Ceiling은 각 자원에 그 자원을 사용하는 Task 가운데 가장 높은 우선순위를 Ceiling으로 지정한다. Task가 자원을 획득하면 우선순위는 즉시 해당 Ceiling까지 상승한다.
자원 R의 Priority Ceiling이 High인 상태에서 Task C가 자원 R을 획득하면, Task C의 우선순위는 Ceiling인 High로 올라간다. 이후 Task B는 Task C를 선점할 수 없다. Task A가 자원 R을 요청하면 대기하지만, Task C는 자원을 해제한 후 우선순위를 복구하고 Task A가 실행된다.
Ceiling 기반으로 Deadlock을 방지하고 Priority Inversion 시간을 제한할 수 있어 대기 시간을 예측하기 쉽다. 대신 모든 자원의 Ceiling을 계산해야 하며, 필요하지 않은 우선순위 상승도 발생할 수 있다.
| 항목 | Priority Inheritance | Priority Ceiling |
|---|---|---|
| 우선순위 상승 시점 | 대기 발생 시 | 자원 획득 시 |
| Deadlock 방지 | 아니오 | 예 |
| 구현 복잡도 | 낮음 | 높음 |
| Priority Inversion 시간 | 더 김 | 더 짧음 |
| 오버헤드 | 낮음 | 중간 |
Mars Pathfinder에서 드러난 문제
1997년 NASA의 화성 탐사선 Mars Pathfinder는 VxWorks RTOS를 사용했다. 이 시스템에서는 우선순위 역행으로 시스템 재부팅이 반복되며 임무가 위협받았다.
높은 우선순위의 통신 Task와 낮은 우선순위의 데이터 관리 Task가 공유 자원인 뮤텍스를 두고 경쟁했고, 중간 우선순위의 기상 Task가 그 사이에 개입했다. VxWorks에서 Priority Inheritance 기능을 활성화하면서 문제가 해결됐다.