📌Eventcount/Sequencer(OS solution)

• Sequencer
  • 정수형 변수
  • 생성시 0으로 초기화, 감소하지 않음
  • 발생 사건들의 순서 유지
  • 은행의 번호표라 생각
  • ticket() 연산으로만 접근 가능
• ticket()
  • 은행에서 실제 번호표 뽑는 함수라 생각
  • Sequencer를 반환 즉, ticket()이 호출 된 횟수를 반환하는 것
• Eventcount
  • 정수형 변수
  • 생성시 0으로 초기화, 감소하지 않음
  • 발생 사건의 횟수 기록
  • 은행의 번호를 알려주는 알림판의 번호
  • read(E), advanced(E), await(E,v) 연산으로 접근 가능
• read(E)
  • 현재 Eventcount 반환 즉, 은행의 번호 알림판의 번호 읽기
• advance(E)
  • E = E + 1 연산 이후
  • E를 기다리고 있는 프로세스 wake up 즉, 번호 + 1 이후 알림 울리기
• await(E,v)
  • V는 정수형 변수(내 번호)
  • if (E < v)이면 E에 해당하는 프로세스에 전달, 본인은 대기

📖ME구현

📖producer-consumer 문제 해결

❗️Eventcount/Sequencer의 특징

• no busy waiting
• no starvation(FIFO scheduling for $Q_{e}$)
• Semaphore 보다 더 low-level control이 가능

📌Monitor(Language-Level solution)

• entry queue : 진입 큐
  • 모니터 내의 procedure 수만큼 존재
• mutual exclusion : 모니터내에 항상 하나의 프로세스만 진입 가능(language가 보장)
• information hiding : 공유 데이터는 모니터내의 프로세스만 접근 가능
• condition queue : 모니터 내 특정 이벤트를 기다리는 프로세스의 대기실
• signaler queue : 신호제공자 큐
  - 모니터에 항상 1개의 신호제공자 큐가 존재
  - signal() 명령을 실행한 프로세스의 임시대기실
  

1. 자원 빌리려는 프로세스A가 entry queue for request에 간다
2. 프로세스A가 모니터내의 requestR에 진입
3. 확인 했더니 모니터 내부에 빌릴 자원이 없어서 condition queue로 가서 기다린다
4. 자원을 다쓴 프로세스B가 entry queue for release로 간다
5. 프로세스 B가 모니터 내의 releaseR에 진입
6. condition queue에 대기하는 프로세스A가 존재하므로 프로세스B는 signaler queue로 이동한다
7. signaler queue에서 condition queue에 대기하고 있는 프로세스A를 wake up 한다

📖producer-consumer 문제 해결

📖reader-writer 문제

📖dining philosopher 문제

• 철학자들은 생각 - 먹기를 반복
• 공유자원 : 스파게티, 포크
• 스파게티를 먹기 위해서는 좌우 포크 2개를 손에 들어아햠
  
• 해결 방법
  

❗️Monitor 특징

• 사용이 쉽다
• 에러 가능성 낮다
• 지원하는 언어에서만 사용 가능
• 컴파일러가 OS를 이해해야함