운영체제 6 : Process Synchronization and Mutual Exclusion (4)

지금까지 ME를 해결하기 위한 SW 솔루션, HW 솔루션, OS가 지원하는 SW 솔루션을 알아봤다.

이 방법들은 low-level에서의 접근으로 Flexible하지만 복잡하다.

 

마지막으로 Language-level(high-level)에서 접근해보자.

• Monitor

---

High-level Mechanism은 프로그래밍 언어로 상호배제(ME)를 수행한다.

그래서 사용이 비교적 쉽다.

 

여러 High-level Mechanism 중 Monitor만 살펴보자.

 

Monitor

한 번에 한 프로세스만 들어갈 수 있는 Critical data, Critical sections 영역이 있다.

C#, C++, F#, VB, java 에서 제공

 

• 장점 : 사용이 쉬워서 에러가 발생할 가능성이 낮다.
• 단점 : 지원하는 언어에서만 사용이 가능하다. 컴파일러가 OS를 이해하고 있어야 한다.

 

Monitor의 구조

Entry queue (진입 큐)	모니터 내의 procedure(function) 수만큼 존재
Mutual exclusion	모니터 내에는 항상 하나의 프로세스만 진입 가능. Language가 이를 보장한다.
Information hiding (정보 은폐)	공유 데이터는 모니터 내의 프로세스만 접근 가능
Condition queue (조건 큐)	모니터 내의 특정 이벤트를 기다리는 프로세스가 대기
Signaler queue (신호제공자 큐)	모니터에 항상 하나의 신호제공자 큐가 존재 signal() 명령을 실행한 프로세스가 임시 대기

 

자원 할당 문제

자원(R)은 하나의 프로세스만 쓸 수 있다.

자원을 사용하는 프로세스가 많을 때 어떻게 자원을 할당할 지 결정하는 문제다.

 

아래와 같이 Monitor를 적용할 수 있다.

procedure requestR() : 프로세스가 자원을 빌려가는 함수

• 자원이 없으면 R_Free에서 기다린다.
• 자원이 있으면 R_Available을 False로 만들면서 가져간다.

procedure releaseR() : 프로세스가 자원을 반납하는 함수

• R_Available을 True로 만들면서 자원을 반납한다.
• R_Free에 시그널을 보낸다. (자원을 기다리고 있는 한 프로세스에게 신호를 보낸다.)

 

자원 할당 시나리오

자원 할당 문제를 단계별로 살펴보자.

처음에는 위와 같은 상황이다.

• R_Available이 1로 자원을 가져갈 수 있는 상황이다.
• Monitor 안에는 프로세스가 없다.

Monitor state 1

Pj가 자원을 가져가기 위해서 requestR() queue를 통해 Monitor에 들어온다.

requestR()을 수행하여 R_Available을 0으로 만들면서 자원을 가져간다.

Monitor state 2

Pj가 Monitor 밖으로 나와서 자원으로 작업을 수행한다.

Pk, Pm이 requestR() queue를 통해 순차적으로 Monitor에 들어온다.

자원이 없기 때문에 R_Free queue에 들어가서 기다린다.

Monitor state 3

releaseR() queue를 통해 Pj가 들어온다.

releaseR()을 수행하여 R_Available을 1로 만들면서 자원을 반납한다.

Pj가 잠시 Monitor 밖에 있는 Signaler queue에 들어가서 R_Free queue에서 기다리고 있는 Pk에게 신호를 보낸다.

Pk가 Monitor에 들어와서 requestR()을 수행하여 자원을 가져간다.

Monitor state 4

Pk가 Monitor 밖으로 나가서 자원으로 작업을 수행한다.

Pj가 다시 들어와서 남은 작업을 수행하고 나간다.

 

이 모든 과정을 Language가 보장해준다.

 

Producer-Consumer Problem

• fillBuf() : 프로세스가 버퍼에 데이터를 채우는 함수
• emptyBuf() : 프로세스가 버퍼의 데이터를 가져가는 함수
• bufHasData, bufHas Space : Producer와 Consumer의 대기 버퍼가 따로 존재한다.
• in, out : Producer와 Consumer가 데이터를 채우고 가져갈 위치
• validBufs : 버퍼에 들어있는 데이터의 총 개수

 

procedure fillBuf()

• 버퍼에 데이터를 채우기 위한 프로세스가 들어온다.
• 버퍼에 데이터가 가득 찼다면 bufHasSpace에 들어가서 기다린다.
• 버퍼에 빈공간이 있다면 데이터를 넣는다.
• validBufs 를 증가시킨다.
• 다음에 데이터를 넣을 위치를 이동시킨다.
• 데이터를 가져가기 위해 기다리는 프로세스가 vufHasData 에 있다면 신호를 보내서 깨운다.

 

procedure emptyBuf()

• 버퍼에서 데이터를 가져가기 위해 프로세스가 들어온다.
• 버퍼에 데이터가 없다면 bufHasData에 들어가서 기다린다.
• 버퍼에 데이터가 있다면 데이터를 꺼낸다.
• validBufs를 감소시킨다.
• 다음에 데이터를 가져갈 위치를 이동시킨다.
• 데이터를 넣기 위해 기다리는 프로세스가 bufHasSpace 에 있다면 신호를 보내서 깨운다.

 

Reader-Writer Problem

• Reader 프로세스는 여러 개가 동시에 동작할 수 있다.
• Writer 프로세스는 동시에 하나만 동작할 수 있다.
• 읽고 있을 때 쓸 수 없고, 쓰고 있을 때 읽을 수 없다.

 

procedure beginReading

• 어떤 프로세스가 데이터를 write하고 있거나 쓰기 위해 기다리고 있다면 readingAllowed 에서 기다린다.
• 그게 아니라면 reader의 수를 증가시킨다.
• 읽기 위해 기다리고 있는 프로세스가 있다면 깨우고 같이 읽는다.

procedure finishReading

• reader의 수를 줄인다.
• reader의 수가 0이라면 writingAllowed에 가서 쓰기 위해서 기다리고 있는 프로세스를 깨운다.

procedure beginWriting

• reader가 하나라도 있거나 writer가 실행중이라면 writingAllowed에서 기다린다.
• 그게 아니라면 wrting을 true로 만들고 write를 시작한다.

procedure finishWriting

• write를 끝내고 wrting을 False로 만든다.
• 읽기 위해 기다리고 있는 프로세스가 있다면 readingAllowed 에 가서 깨운다.
• 읽기 위해 기다리고 있는 프로세스가 없다면 writingAllowed 에 가서 깨운다.

 

Dining philosopher problem

• 5명의 철학자가 있고, 사이사이에 포크가 하나씩 있다.
• 공유 자원 : 스파게티, 포크
• 스파게티를 먹기 위해서는 좌우 포크를 2개 모두 들어야 한다.
• 철학자(프로세스)는 이 순서로 동작을 한다.
  • 포크를 든다.
  • 먹는다.
  • 포크를 내려놓는다.
  • 생각한다.

위 상황에서 철학자들이 스파게티를 먹도록 Monitor을 활용해서 공유 자원을 할당하자.

 

• numForks 에는 철학자들이 사용가능한 포크의 수가 들어있다.
• 각 철학자마다 기다리는 queue가 따로 있다.

 

procedure pickup()

• 쓸 수 있는 포크가 2개가 아니라면 기다린다.
• 포크가 있으면 양쪽 포크의 수를 줄이고 Monitor를 빠져나온다.

procedure putdown()

• 포크를 내려 놓는다.
• 양쪽의 철학자들이 포크 2개를 기다리고 있었는지 확인한다.
• 기다리고 있었다면 신호를 보내서 깨운다.

 

---

본 글은 HPC Lab. KOREAHECH YOUTUBE 채널의 김덕수 교수님 강의를 보고 작성되었습니다.

[Course] Operating System (CPA310) - 운영체제 강의