[PintOS] Project1 - Monitor System Deep Dive

목차

1. 모니터의 구조
   • Semaphore vs Monitor
   • 모니터는 언제 사용되어야 하는가
   • 모니터의 구성요소
2. TestCase 톺아보기
3. Language
   • Java에서의 Monitor
4. Q & A

---

모니터의 구조

Semaphore vs Monitor

• 모니터의 경우 직접적으로 signal과 wait 을 사용하지않고 요청이된다.
• 모니터는 요청받은 작업을 모니터 큐(Entry_queue, Waiting_queue)에 저장한 후 순서대로 처리하고 그 결과만 해당 프로세스에 알려준다.

모니터는 언제 사용되어야 하는가?

• 한번에 하나의 스레드만 순차적으로 처리하여야할 때 (Mutex의 성질)
• ➡️ Race Condition, DeadLock 방지
• 임계구역(Critical Section)에서 여러 스레드와 협업이 필요할 때
• 특정 조건 하에서 스레드의 동기화와 통신을 효율적으로 관리하기 위해서

모니터의 구성요소

• Mutex
  • Entry Queue : 임계구역의 진입을 기다리는 큐
• Condition Variables
  • Wait Queue : 개발자가 정한 조건이 충족되길 기다리는 큐

1. 공유 자원을 요청하는 모든 Thread는 Lock을 요청하고 이미 Lock을 사용중이라면 Entry Queue에 저장
2. 이후 쓰레드가 작업을 수행하며 조건 변수에 부합하지 않는다면, Lock을 반납하고 Wait Queue 에 저장
3. 이후 Entry Queue에 존재하던 다른 Thread(조건에 부합한)가 작업을 수행 후 Signal을 요청
4. Signal이 Wait Queue에 있는 Thread들이 Awake 할 수있는지 notify해준다.
5. Signal을 받은 Wait Queue의 Thread가 이후 작업 수행

---

TestCase 톺아보기

• 기존 Condition Variable을 적용하고 이를 검증하는 TestCase는 priority-convar.c 였다.
• 하지만 실제 코드적으로 조건변수를 사용하여 cond_wait() 중인 쓰레드를 우선순위에 맞게 깨우는지 확인하는 테스트이다.

원래 TestCase 결과값

 

• 순차적으로 우선순위별로 정렬을 하기에 단순히 조건 상관없이 출력만 이루어진다.
  • struct condition → waiters 에 담기자마자 wakeup되는 구조

새로 작성한 TestCase 전체적인 프로세스

변경코드

• 우선 순위가 특정값(26)보다 높다면 broadcast(or signal)을 보내 wait_queue를 전부 꺠움

---

실행 결과

• 결과적으로 처음 26보다 큰 값인 30 을 만나는 순간 wait queue 에 broadcast를 전달

---

다른 언어에서는 Monitor를 어떻게 구현하고 있나?

• 다른 Language에서는 언어 레벨에서 동기화와 상호배제 방법을 Application Level에서 제공한다.

Java

• Java는 모든 객체가 내부적으로 모니터를 구현되어 있어야한다.
  • 최상단 객체 Object에 정의 되어있다.
• synchronized 키워드를 통해 Mutex를 구현한다.
• 또한 Condition Variable을 하나만 가진다.
• 이를 위한 signal , wait , broadcast 를 각각 아래와 같이 정의하고있다.
  • wait
  • notify
  • notifyAll