Priority Inversion (우선순위 역전)
배경
- 1997년 7월 4일 Mars Pathfinder 임무 도중 해당문제를 발견함. 며칠 후 데이터를 수집하려고 할 때 전체 시스템이 초기화(reset)되는 현상이 나타났다. 이것을 "software glitches"에 의한 조건에서 문제가 발생한 것을 보고.
- 자세한 원인을 설명하면 중간의 우선순위를 가진 communiaction task가 높은 우선순위의 짧은 간격의 information bus 스레드가 스케쥴되어 있다고 한다. 하지만 높은 우선순위를 가진 communication task가 그것보다 낮은 우선순위의 meteorological data 스레드를 blocking 해서 결과적으로 가장 높은 우선순위의 communication task가 실행되지 못하였다. 시간이 지나면서 data를 수집 못하니 timer가 만료되어 system reset되는 현상이 나타났다고 한다.
출처: https://www.cs.cornell.edu/courses/cs614/1999sp/papers/pathfinder.html
정의
높은 우선순위의 스레드가 낮은 우선순위 스레드를 기다리는 현상임.
특히 real-time scheduling에서 관련 깊음.
원리
위의 그림을 보면 T1>T2>T3 순으로 우선순위가 있다고 가정하자.
먼저 T3가 스케쥴 되어 실행 도중 공유자원 s를 lock하였다.
그 후 T1이 스케쥴 되었지만 공유자원 s는 T3에 의해 lock 되어있는 상태라 선점하지 못했다. 따라서 T1은 처리되지 못한채로 T3에의 블락된다. 그 후 T2가 처리되고 T3가 가진 s를 언락한 후에야 T1이 실행된다.
즉 T1은 공유자원 s를 얻지 못하고 블락되고 우선순위 낮은 T2가 먼저 실행 되었다.
-> 우선순위 역전 발생!!
Priority Inheritance (우선순위 상속)
앞서 말했던 우선순위 역전 현상을 해결하기 위해 보다 낮은 스레드 또는 프로세스에게 우선순위를 넘겨줘(우선순위를 상속 받음) 해결!
원리
T3가 공유자원 s를 lock하고 T1이 실행 되었을 때, T3는 T1으로 부터 우선순위를 상속 받음.
우선순위를 상속받은 T3가 s를 unlock 할 수 있게 됨.
T1은 s를 lock하고 수행 -> T2 수행
공유자원을 가진 T3가 우선순위를 상속 받아 정상적으로 임무 수행!
