CS/OS

6. 프로세스 동기화 & 상호배제 (7) - Monitor

🥭맹2 2021. 5. 14. 04:01

강의 링크 : https://www.youtube.com/watch?v=AnYN-kbCbRI&list=PLBrGAFAIyf5rby7QylRc6JxU5lzQ9c4tN&index=18

0. 들어가기에 앞서

이번 포스팅에서 다룰 내용은 Monitor입니다.

이는, 앞에서 다룬 Low-level mechanisms(SW solution, HW solution, OS supported SW solution)과는 달리, Language-Level solution으로써 프로그래밍 언어적으로 상호배제를 해결하는 방법입니다.

그 동안 한 Low-level mechanisms들은 다음과 같은 특징이 있었습니다.

  1. Flexible : 다양하게 적용 가능하다
  2. Difficult to use : 구현이 복잡하다
    • Error-prone: 구현이 복잡하기 때문에 logical error의 발생 확률이 높다

이와 달리 Language-Level Solution의 경우 프로그래밍 언어가 mutual exclusion을 지원해주는 것이기 때문에 사용이 쉽고 구현이 간단하다는 장점이 있습니다.

Monitor, Path expressions, Serializers, Critical regon, conditional critical region 등이 있지만 Monitor만 다루겠습니다.

1. Monitor란?

  • 공유 데이터와 Critical section의 집합
  • Conditional variable
    • wait(), signal() operations

2. Monitor 구조

monitor는 책 방으로 이해하면 편합니다요

  • monitor : 1명만 들어갈 수 있는 책 방이라고 생각.
  • critical data : 책
  • critical sections : 책 반납, 대출 같은 업무를 보는 카운터
  • Entry queue (진입 큐)
    • 한 명씩 책 방에 진입할 수 있게 해주는 queue
    • 모니터 내의 procedure 수 만큼 존재
    • procedure 수 == function마다 하나씩 존재한다고 생각하면 됨
  • Mutual exclusion : 프로그래밍 언어가 보장해줌
    • 모니터 내에는 항상 하나의 프로세스만 진입 가능
  • Information hiding (정보 은폐)
    • 책 방에 한 번에 한 명만 들어갈 수 있으므로 정보의 은폐성 존재
    • 공유 데이터는 모니터 내의 프로세스만 접근 가능
  • Condition queue(조건 큐)
    • 조건을 기다리는 큐 == 대기실
    • 모니터 내의 특정 이벤트를 기다리는 프로세스가 대기
  • Signaler queue (신호제공자 큐)
    • 전화부스 같은거 (signal을 보내기 위해 잠깐 들어가는 공간)
    • 모니터에 항상 하나의 신호제공자 큐가 존재
    • signal()명령을 실행한 프로세스가 임시 대기

3. Monitor in Languages

C#, C++, Visual Basic, JAVA 등에서 지원

  • C#, C++, java에 monitor class가 존재함을 확인할 수 있음

4. 자원 할당

각각의 용어를 이해해봅시다

  • R_Available : 책 (1권만 존재)
  • entry queues for releaseR() : 자원 반납 entry queue
  • entry queues for requestR() : 자원 요청 entry queue
  • requestR() : 대출하는 공간
  • releaseR() : 반납하는 공간
  • condition queue R_Free : 책 대출하기 위해 대기하는 공간
  • signaler queue : 전화부스 같은거 (대기실(condition queue R_Free)에 있는 애를 깨우는 거)

간단히 monitor 로직을 이해해봅시다

  1. 책 대출하러 옴
    1. ~R_Available : 책이 없나요?
      1. 책이 없다면 기다림
      2. 책이 있다면 책 빌려감
  2. 책 반납하러 옴
    1. R_Available <- true : 현재 책 상태 갱신 (빌릴 수 있다고 바꿔줌)
    2. R_Free.signal() : 대기실에 연락 (책 대출 가능 하다고)

5. 자원 할당 시나리오

0) initial monitor state

  • 자원 R 사용 가능
  • 현재 Monitor 안에 프로세스 없음

모니터 초기 상태

1) Monitor state1

  • 프로세스 Pj가 모니터 안에서 자원 R을 요청

Pj가 자원R을 요청한 상태 (현재 모니터에 Pj가 들어있어서 R_Available은 1에서 0으로 값이 변함)

  1. 현재 상황 : requestR()Pj 존재

2) Monitor state2

  • 자원 R이 Pj에게 할당 됨
  • 프로세스 Pk가 R 요청, Pm 또한 R 요청

자원 R이 Pj에 할당된 후 Pk, Pm이 requestR()에 갔다가 대기실(condition queue R_Free)으로 이동

  1. 현재 상황 : entry queues for requestR()Pj, Pk, Pm 존재
  2. requestR()에 있던 PjR로 이동 : monitor에서 빠져 나옴
  3. entry queues for requestR()에 있던 PkreqeustR()로 이동
  4. condition queue R_FreePk이동
  5. entry queues for requestR()에 있던 PmrequestR()로 이동
  6. condition queue R_FreePm이동
  • 2~5는 현재 PjR에 위치해있기 때문에 (monitor 내부에 존재해있지 않음) 가능한 것이다. (왜냐하면 monitor에는 1개만 있을 수 있으므로)

3) Monitor state 3

  • Pj가 R 반환
  • R_Free.signal() 호출에 의해 Pk가 wakeup

Pj가 R을 반환하고 signaler queue로 가서 Pk를 깨울 때 R_Available이 1로 바뀌었다가 Pk가 requestR()로 들어와서 R_Available이 0으로 바뀜

  1. Pjentry queues for releaseR()로 가게 됨.
  2. releaseR()Pj이동
  3. signaler queuePj이동
  4. signaler queue에 담겨있던 Pjcondition queue R_Free에서 대기하고 있던 Pk를 깨워줌
  5. requestR()Pk들어감

4) Monitor state 4

  • 자원 R이 Pk에게 할당됨
  • Pj가 모니터 안으로 돌아와서, 남은 작업 수행

자원 R은 Pk로 할당되고, 잠시 Pj가 남은 일을 마저하기 위해서 monitor 내부로 들어옴

  1. PkR로 이동 (자원이 Pk에게 할당됨)
  2. signaler queue에 존재하고 있던 Pj가 남은 작업을 수행하기 위해 realeaseR()로 이동 (현재, PkR로 이동했기 때문에 모니터에는 프로세스가 없음)
  3. Pk가 작업을 다하고 releaseR()을 벗어남

6. Producer-Consumer Problem

이제는 익숙해진 ~! 생성자-소비자 문제

  • 사이즈가 N인 원형 큐
  • shared data (= critical data)
    • in(P), out(C) : 위치 정보
    • validBufs : 물건 수
  • entry queue for fillBuf() : 물건을 넣을 때 (P가 접근)
  • entry queue for emptyBuf() : 물건을 뺄 때 (C가 접근)
  • bufHasData : 가져갈 것이 있나? (C의 큐)
  • bufHasSpace : 공간이 있나? (P의 큐)
  • signaler queue : 전화부스

생성자 소비자 로직

  1. 프로듀서가 채우려고 옴
    1. 공간이 다찼는지 확인
      1. 공간이 다찼다면 대기
    2. 공간이 있으면 물건을 놓고
    3. 물건 수 증가
    4. 공간 idx 갱신 (원형 큐이므로 나머지 연산 이용)
    5. 물건 넣었다는 signal 보냄
  2. 컨슈머가 물건 가지러가려고 옴
    1. 물건이 없는지 확인
      1. 물건이 생길 때까지 대기
    2. 물건이 있으면 물건을 꺼내고
    3. 물건을 줄이고
    4. idx 갱신 (원형 큐이므로 나머지 연산 이용)
    5. 나가면서 공간 생겼다는 signal보냄

7. Reader-Writer Problem

  • reader/writer 프로세스들 간의 데이터 무결성 보장 기법
  • writer 프로세스에 의한 데이터 접근 시에만 상호 배제 및 동기화 필요함

1) 모니터 구성

  • 변수 2개
    • 현재 읽기 작업을 진행하고 있는 reader프로세스의 수
    • 현재 writer 프로세스가 쓰기 작업을 진행 중인지 표시
  • 조건 큐 2개
    • reader/writer 프로세스가 대기해야할 경우에 사용
  • 프로시져 4개
    • reader(writer) 프로세스가 읽기(쓰기) 작업을 원할 경우에 호출, 읽기(쓰기) 작업을 마쳤을 때 호출

reader-writer 문제 로직

8. Dining philosopher problem

철학자의 저녁식사 문제

  • 5명의 철학자
  • 철학자들은 생각하는 일, 스파게티 먹는 일만 반복함
  • 공유 자원 : 스파게티, 포크
  • 스파게티를 먹기 위해서는 좌우 포크 2개 모두 들어야함.
    • but 현재 포크 5개만 존재

P는 철학자.. 아니 프로세스 ..

  • pickup(i), putdown(i) : procedure

철학자의 저녁식사 문제 로직

  1. 포크 들기
    1. 현재 내가 쓸 수 있는 포크 수가 2개가 아니라면
      1. 내 방에 와서 나를 깨울 때까지 기다리기
    2. 내 오른쪽, 왼쪽에 있는 사람들이 쓸 수 있는 포크수 각각 -1
  2. 포크 내려놓기
    1. 내 오른쪽, 왼쪽에 있는 사람들이 쓸 수 있는 포크 수 각각 +1
    2. 혹시 오른쪽, 왼쪽 사람들이 각자의 방에서 쉬고 있었다면 signal 보내 부르기

여기서 각각의 프로세스들은 각각의 방을 가지고 이써욧

9. Monitor의 특징

1) 장점

  • 사용이 쉽다 => 실수할 가능성이 줄어든다
  • Deadlock 등 error 발생 가능성이 낮음

2) 단점

  • 지원하는 언어에서만 사용 가능
  • 컴파일러가 OS를 이해하고 있어야 함
    • Critical section 접근을 위한 코드 생성