[운영체제] Process Synchronization3

이번엔 Synchronization로 해결할 수 있는 문제 3가지를 알아보자

 

Bounded - Buffer - Problem

버퍼의 크기는 유한하다.

생산자와 소비자가 있다.

생산자는 공유 버퍼에다가 데이터를 만들어서 집어 넣는역할을 한다.

소비자가 데이터를 가져가는 역할

 

이 상황에서 무슨 문제가 있냐?

생산자 둘이 동시에 비어있는 곳에 데이터를 넣을 경우

- 생산자가 데이터를 넣으려고 할때 락을 걸어야한다. ,

소비자도 마찬가지로 가져갈때 락을 걸어야한다.

  

 

 

Readers - Writers Problem

읽는 프로세스와 쓰는 프로세스가 있는 경우다.

Writer 는 Synchronization 을 해야되지만 Reader 는 동시에 해도 상관없는 상황

 

Reader 든 Writer 든

P 연산을 해서 DB 전체에 락을 걸고 접근이 끝나면 V 로 락을 풀어도 되지만,

 

Read 는 동시에 해도 되는데 락을 걸면 비효율적이다.

 

그래서 이 문제는

reader 가 읽고 있을때 또 다른 reader 가 오는건 괜찮지만

reader 가 읽고  있을때 writer 가 오면 writer 는 기다려야한다. - writer는 reader 가 하나도 없을때만 접근이 가능하다.

 

이 문제를 어떻게 푸는지 

 

DB 가 공유 데이터다

 

reader 에서는 최초 reader 가 들어오면 Writer 에 대한 접근을 막기위해 

db 에 락을 건다.

 

그리고 모든 reader 가 나가게 되면 db에 락을 해제시킨다.

 

근데 readcount  도 공유 변수인데

reader 가 동시에 오면 문제가 생길 수 있다.

readcount 가 2개가 와도 1개만 적용되는 경우가 생길 수 있다.

그래서  이 readCount 공유 변수를 위한 mutex 락을 건다.

 

 

 

Dining- Philosophers Problem

식사하는 철학자 문제

밥을 먹기 위해서 왼쪽 과 오른쪽 젓가락이 필요하다고 가정했을때의 문제다

한 사람이 잡으면 양 옆 사람은 기다려야한다.

 

Deadlock 의 문제가 있을 수 있다. 진행되지 않는 상황..

모두 동시에 왼쪽 젓가락을 잡으면 모두 멈추는 상황이 생긴다 이걸 데드락이라고 함

 

해결법 - 4명만 앉도록 한다.

 

5명의 철학자가 하는일은 먹거나 , 생각하거나 가 있다.

만약 semaphore self[3] = 1 이면 3번 철학자는 양 옆에 젓가락을 들 수 있다는 뜻

mutex 락은 철학자의 상태 state 는 양 옆의 철학자가 변경시킬수도 있기 때문에 공유 변수라 생각해야되기 때문에

그 동시 접근을 막기 위해 있는 변수다.

 

test 함수 젓가락을 양 옆 전부 들 수 있는지 확인한다.(양 옆 철학자가 먹지 않고 있고, 내가 배고픈 상태)

 

 

세마포어는 문제가 생겼을때 치명적이다 .  실수에 치명적이다.

 

모니터 내부에 공유 데이터가있고,

모니터 자체가 동시 접속이 불가능하기 때문에 프로그래머가 공유데이터에 락을 걸 필요 없게 만들어준다.

 

세마코어 코드를 모니터코드로 변경

모니터에서는 락을 걸거나 풀 필요가 없다.

비어있는 버퍼가 없다면 wait 하게 해준다.