#6-4. Process Synchoronization
: 프로세스 동기화에서 생기는 문제점 3가지를 알아보도록 하겠습니다.

 

 


* Bounded-Buffer Problem
: 버퍼의 크기가 유한

 

 

 

# 상황 설명
- Circular buffer 형태로 되어있다.
- 여러개의 Producer(생산자) 프로세스와
- 여러개의 Consumer(소비자) 프로세스가 있다.

 

# 역할
 - Producer : 공유버퍼에다가 데이터를 하나 만들어서 집어넣는역할.
 - Consumer : 데이터를 꺼내가는 역할
(원형 버퍼의 그림을 보면 주황색 색칠 부분은 producer가 데이터를 넣은것이고, 색칠 안된 동그라미는 consumer가 데이터를 쓴것.

 

???)

여기서 Synchronization과 관련해서 어떤문제들이 발생할까?

 

1) 공유 버퍼이기 때문에 생산자가 둘이 동시에 도착해서 동시에 데이터를 만들어 집어 넣으면 동기화 문제가 발생.
=> 공유 버퍼에 lock을 걸어서 동기화문제를 해결해야 한다.

 

2)공유 버퍼이기 때문에 소비자가 둘이 동시에 도착해서 동시에 데이터를 가져가면 동기화 문제가 발생.
=> 역시 공유 버퍼에 lock을 걸어서 동기화문제를 해결하도록 한다.

 

3) 버퍼가 유한(Bounded) 하기 때문에 생기는 문제
: 즉, 버퍼가 찼는데, 생산자(producer)가 도착하는 경우, 또는 버퍼가 비었는데 소비자(consumer)가 도착하는 경우.
=> producer는 버퍼가 가득 찼는지, consumer는 버퍼가 비었는지 체크 해줘야 한다.

 


----------------------------------------------------------
!!!)

 Semapore 를 이용해서 해결해야할 문제가 2가지가 있다.

 

 

1) 동시에 공유 버퍼에 접근하는것을 막기 위해서 lock을 걸었다가 푸는 작업.

2) 버퍼가 가득 차거나, 비었을 때를 알수 있게 counting Semapore가 필요하다.
----------------------------------------------------------

 

 

 

 

# 세마포어로 구현한 생산자, 소비자 문제


 

 


* Readers - Writers Problem

 

 

 

# 상황 설명

- 프로세스는 2종류(읽는 P, 쓰는 P)
- 공유 데이터 : DB

 

Sol)

Reader는 동시접근이 가능하게 하고,

Writer는 동시접근이 불가능하게 해야한다.


# 세마포어를 통한 문제 해결 코드

 

 

# Reader 부분 설명

 

1) 노란색 부분인 if(readcount == 1) P(db); 을 보면 1일때에만 db(스몰 db)로 lock을 걸어주게 되고, 1이 아니면 이미 lock이 걸려 있기 때문에 DB에 바로 들어갈 수 있다.

2) But, 여기서 readcount도 공유 변수 이므로 동시에 접근할 경우 동기화 문제가 발생할 수 있다. 그래서 mutex변수를 이용하여 readcount에 접근하는 부분에도 lock과 unlock을 걸어주도록 한다.


!!!)

그렇지만 Writer의 Starvation 현상이 발생한다.


readcount가 0이 되어야 V(db)로 lock이 풀리는데,

Reader가 너무 많아 지면 Writer는 Starvation 현상이 발생하게 된다.

 


* Dining - Philosopheres Problem (식사하는 철학자 문제)
:  2가지 업무가 있다. (생각하는 업무, 밥을 먹는 업무)

 

 

 

 

!!!)

노란색 코드 때문에 Deadlock이 발생할 수 있는 위험한 코드이다.


why))

 eat()에 들어가기 전에 모든 철학자가 P(chopstick[i])코드 때문에 자신의 왼쪽 젓가락을 들고 안놓게 된다... 그렇게 될 경우 아무것도 진행이 될 수 없는 Deadlock 현상이 발생하게 된다.

 그럼 어떻게 해결을 해야 할까?

 

 

 

 

 

 

# 식사하는 철학자문제를 세마포어로 해결한 코드

 

 

 

# 변수 설명
- semaphore self : 각각의 5명의 철학자가 젓가락 2개를 잡을수 있어서 젓가락 잡는 권한을 줄것이나 말것인가를 정하는 변수.

 ex>
 - self[1] = 0; // 1번 철학자는 젓가락 잡기 불가능.
 - self[3] = 1; // 3번 철학자는 젓가락 잡기 가능.

- mutex : state변수에 접근에 lock/unlock 을 위한 변수.

- test 함수 : 젓가락 잡을수 있는 권한이 있나?
 즉, 왼쪽 철학자랑 오른쪽 철학자가 먹고 있지 않고, 내가 hungry인 상태일때, 젓가락 잡을수 있는 권한 획득.


* 세마포어의 문제점

 

 


=> 세마 포어를 개발자가 잘 지키면 프로그램이 제대로 돌아가겠지만, 제대로 했는지 확인이 힘들다....

 

 

* Moniter
: 공유데이터를 접근하기 위해서는 모니터라고 정의된 내부에 프로시저를 통해서만 내부의 공유 데이터에 접근할수 있게 만들어 놓는것. 그리고 모니터가 원천적으로 내부에 프로시저가 동시에 여러개가 실행되지 않도록 만드는것.(=> 이렇게 되면 lock을 걸 필요가 없다.)

(프로그래밍 언어 차원에서 동기화 문제를 해결을하는 High-level Synchronization construct)

 

 


semaphore의 lock & unlock기능은 해결!!

 

???)
자원의 개수를 어떻게 셀까?

 

 

 

 

 

# 함수 설명

- wait() : 자원이 없으면 기다리게 하는 함수
- signal() : 접근을 다하고 빠져나갈 때 호출(invoke)하는 함수

 

 

 

* 모니터 내부 형태

 

 

 


* 모니터로 convert한 Bounded-Buffer & Dining - Philosopheres Problem
: 세마포어처럼 lock을 걸 필요가 없다.
(모니터 안에서 하나의 프로세스만 실행되기 때문에!!)

 

 

 

 

 

 

 

 


 

'cs > os' 카테고리의 다른 글

[1]. 세마포어와 뮤텍스  (0) 2018.01.22
#6-3. Process Synchronization  (0) 2018.01.21
#6-2. Process Synchronization  (0) 2018.01.15
#6-1. Process Synchronization  (0) 2018.01.11
#5-3. CPU SCHEDULING  (0) 2018.01.09

+ Recent posts