SW, HW, OS supported의 방식들은 유연한 방식이지만 복잡하여 오류가 생기기 쉽다.
따라서 High Level인 Language level에서 제안하는 방안이다.

Monitor Solution

프로그래밍이 ME를 서포팅
장점:
OOP와 유사
사용이 쉽다
Dead lock 등 에러 발생 가능성이 낮음
단점:
지원하는 언어에서만 사용가능
컴파일러가 OS를 이해하고 있어야 함
(임계영역 접근을 위한 코드 생성)

Monitor

공유 데이터와 임계영역Critical section을 모아둔 방(집합) 개념
마찬가지로 한명씩만 들어갈 수 있는 영역이다.
이 monitor에 접근하기 위한 용도로 wait(), signal() 연산이 있다,

Monitor의 구조

Entry queue(진입 큐)

모니터 내의 procedure(function) 수만큼 존재

Mutual exclution(상호배제)

모니터 내에는 항상 하나의 프로세스만 진입 가능하며 이는 OS가 보장한다

Information hiding(정보 은폐)

공유 데이터는 모니터 내의 프로세스만 접근 가능

Condition queue(조건 큐)

모니터 내의 특정 이벤트를 기다리는 프로세스가 대기

Signaler queue(신호제공자 큐)

모니터에 항상 하나의 신호 제공자 큐가 존재
signal() 명령을 실행한 프로세스가 임시 대기하는 공간
대기실에 잠들어 있는 프로세스를 깨우는 공간이라 생각하면 된다

모니터 자원할당 시나리오

1. 임계영역 진입 요청 프로세스가 requestR() entry queue에 쌓임

2. requestR()이 비어있고, R_Available이 1이면 임계영역 진입(진입시 requestR은 비게 됨)

3. 새로운 프로세스가 진입. requestR이 비어있지만, R_Available이 1이 아니라면
   condition queue R_Free에 적재되어 대기하게 됨

4. 임계영역에서 작업을 마친 프로세스는 releaseR entry queue에 쌓임

5. 적재된 프로세스는 releaseR()에 들어가게 되고, 다시 signaler queue에 옮겨짐
   why? releaseR()에 계속 존재한다면 wake up시킨 프로세스가 모니터 내로 못들어가니까
   why? monitor에는 한번에 한명만 들어갈 수 있으니까

6. wake up시킨 프로세스가 리소스를 읽으려 모니터 밖으로 나가면 signaler queue에 대기시켜뒀던
   프로세스를 다시 releaseR로 불러와 남은 일을 수행한다.(자원 할당해제 이후의 추가작업 등)