원문
의미
- 태스크 스케쥴링에 있어서 고순위 태스크가 저순위 태스크에 사실상 밀려서 실행이 늦어지는 문제 상황
- 일반적인 상황에서는 심각한 문제가 아닐 수도 있으나 Realtime OS에서는 심각한 문제로 인식됨
실제 사례
- 화성에 보낸 탐사선인 Path Finder에서 이런 문제가 발생하여 그 심각성이 알려지게 됨
- 자원을 획득하지 못하고 태스크가 starvation에 빠지는 문제가 생기자 watch dog timer가 전체 시스템을 reboot해버리는 방식으로 해결하려고 시도하고 이 현상이 무한 반복되는 문제로 확대되었음
예제
- 가정
- 저순위 태스크 L
- 중순위 태스크 M
- 고순위 태스크 H
- L이 가장 먼저 시작해서 자원 R을 사용하고 있음
- H이 나중에 시작해서 자원 R을 필요로 함
- L이 R을 내려놓을 때까지 H는 기다려야 함
- M이 가장 늦게 시작하는데 R을 필요로 하지 않음
- H는 여전히 실행이 안 되고 있는 상태
- M은 L보다는 우선순위가 높고 자원을 필요로 하지 않으므로 block되지 않음
- 원칙 상, M이 L을 pre-empt할 수 있음
- M이 CPU를 얻어서 실행됨. 끝남
- L이 실행됨. 최소한 자원 R을 내려놓을 때까지는 쭉 실행됨
- H는 L이 R을 내려놓을 때까지는 대기함
- M이 H보다 먼저 실행되는 우선순위 역전이 발생함
해결책
- critical section을 보호하기 위해 모든 인터럽트를 방지
- pre-emptible, interrupt-disabled라는 두 가지 우선순위만 설정함
- 우선순위 제한 (Priority Ceiling)
- 어떤 태스크가 mutex에 lock을 걸면 다른 태스크들은 그 태스크의 우선순위(ceiling priority)보다 더 높게 우선순위를 가질 수 없음
- 우선순위 상속
- 자원을 기다리는 태스크에 높은 우선순위를 부여하는 방법