정글 사관학교 W08[핀토스]_WIL

[8주차 개괄]

😳 하하하 8주만에 돌아온 정글 기록이다. 😳

pintOS 과정이 시작되었고, 2.5주간 함께할 조원들이 정해졌다.
두 팀원들(노 & 문)과 함께 은방울자매를 이을 대한의 자랑, 세자매를 결성했다.
남은 1.5주차도 잘 해보자구!

[Project 1-1: Alarm Clock]

⏰ interrupt를 잠시 꺼보자!

• OS 책에서는 공유자원에 접근하는 경우 원자성을 보장하는 방법 몇 개를 소개한다.
  1) 타이머 인터럽트를 잠시 끄기 ( 지양 👺 )
  2) 락을 사용하기
  3) 세마포어를 사용하기
  4) 모니터를 사용하기

• 타이머 인터럽트를 잠시 끄는걸 왜 지양해야 하는데?
  AND 왜 project1-1에서는 타이머 인터럽트를 잠시 끄는 방식을 선택해야만 할까?
  -> https://thunder-year-be8.notion.site/Q-A-ac31512cbf07451399d86c3210d6f28e
  

[Project 1-2: Priority Scheduling]

♻️ 스레드의 우선순위가 높은 순으로 스케줄링을 하자!

• 위의 Project 1-1에서는 모든 스레드들의 우선순위가 동일했다.
  즉, 우선순위를 따질 필요 없이, 먼저 ready_list로 들어오는 순서대로 CPU를 점유하면 되었다. (Round robin 방식)
• Project 1-2부터는 스레드마다 우선순위가 다를 수 있다.
• 따라서 현재 running 상태인 스레드보다 높은 우선순위인 스레드가 ready 상태가 되면, CPU 제어권이 넘어가게 된다.

💤 공유자원에 대한 접근이 불가능하다면, 기다리자(BLOCKED)!

• Thread A (우선순위: 11)가 RUNNING 상태라고 하자.
  그리고 X라는 lock을 가지고 있다고 하자. (계속 running 중)
• Thread B (우선순위: 31)가 새롭게 만들어졌다고 하자.
• 이때 Thread B (31)의 우선순위가 높으므로 CPU 제어권을 넘겨받고 RUNNING 상태가 되고, Thread A (11) 는 ready_list에 들어가 READY 상태가 된다.
• 공교롭게도 Thread B (31)가 X을 가지고 싶어한다고 하자.
• X은 이미 Thread A (11)에게 있기 때문에 Thread B (31)는 해당 lock의 waiting list에서 대기하며 상태는 BLOCKED가 된다.
• 이때 Thread B (31)는 ready_list에 들어가는 것이 아니다❗️

🐸 두꺼바 두꺼바, 내 우선순위 줄게. 빨리 lock을 놓아다오!

• (위의 예시를 계속 이어서 설명해보자면)
• Thread B (31)가 Thread A (11)보다 우선순위가 높음에도 X라는 lock을 가지지 못해서 BLOCKED상태가 되었다.
• Thread A (11)가 아직 X을 놓지 않았는데, Thread C (21)가 만들어졌다고 하자.
• 우선순위 스케줄링으로 인해 Thread C (21) 가 RUNNING 상태로 바뀌게 된다.
• Thread B (31)는 때문에 X라는 lock을 갖지 못해서 BLOCKED 상태가 되었던 것 뿐만 아니라, 우선순위가 더 낮은 Thread C (21)보다도 늦게 CPU 제어권을 얻게 된다.

  이것이 "우선순위 역전(Priority Inversion)" 현상이다.

• 이를 해결하기 위해서, Thread B (31)는 Thread A (11)에게 CPU 제어권을 넘기면서 빨리 lock을 놓을 수 있도록 == 다른 스레드에게 CPU 제어권 넘기지 말라고 본인의 우선순위인 31을 Thread A (11)에게 기부한다.

  이것이 우선순위 역전 현상을 해결하기 위한
  "우선순위 기부(Priority Inheritance)"이다.