<aside> 💡

Ready_list에 현재 실행중인 스레드보다 더 높은 순위를 가진 스레드가 추가된다면? → 현재 스레드는 CPU를 양보해야함

</aside>

• 스레드는 언제나 자신의 우선순위를 높이거나 / 내릴 수 있음

<aside> 💡

KAIST-PintOS Gitbook 참고

</aside>

• 스레드 우선순위는 PRI_MIN (0) 에서 PRI_MAX (63) 까지의 범위를 가지며, 숫자가 낮을수록 낮은 우선순위를 의미
• 스레드의 초기 우선순위는 thread_create()의 인자로 전달

우선순위 역전 문제

<aside> 💡

예를 들어, 높은 우선순위 스레드 H, 중간 우선순위 스레드 M, 낮은 우선순위 스레드 L이 있다고 가정

• 만약 H가 L을 기다려야 하는 상황(예: L이 보유한 lock을 H가 필요로 하는 경우)이 발생
• M이 ready list에 있다면, L은 CPU 시간을 거의 얻지 못해 H가 영원히 실행되지 못하는 상황이 발생 </aside>

이 문제에 대한 부분적인 해결책은 우선순위 기부(Priority Donation)

• 즉, H가 기다리는 동안 자신의 우선순위를 L에게 기부하여, L이 높은 우선순위를 갖고 실행
• 그리고 L이 lock을 해제하고, H가 해당 lock을 획득하게 되면, 기부된 우선순위를 원래대로 되돌림

구현

• 여러 스레드가 동시에 하나의 스레드에게 우선순위를 기부하는 다중 기부 상황 처리
• 중첩 기부 처리
  • H가 M이 보유한 lock을 기다리고 있고
  • M이 L이 보유한 lock을 기다리고 있다면
  • H의 우선순위가 M에게 기부되고, 다시 L에게도 기부
  • 합리적 제한을 둘 수 있음?
    • 최대 깊이를 8 레벨 정도로 제한?