6-3~4. Process Synchronization 3,4

6-3 Process Synchronization 3

Semaphores, Implementation, Classical Problems of Syncronization, Bounded-Buffer Problem, Readers-Writers Problem, Dining-Philosophers Problem, Monitor

6-4 Process Synchronization 4(Concurrency Control)

Semaphores, Monitor, Bounded-Buffer Problem, Dining Philosophers Example

Classical Problems of Synchronization (고전적인 3가지 문제!)

Bounded-Buffer Problem(Producer-Consumer Problem)

버퍼 (임시로 데이터를 저장하는 공간)의 크기가 유한한것! 생산자-소비자 문제로도 불림.

이 문제는 프로세스가 두가지 종류가있는데, 프로듀서와 컨슈머가 있는데 여러개가 있는 상황

생산자는 공유버퍼에 데이터를 하나 만들어 집어 넣는 역할 주황색이 데이터를 만들어서 넣는 것! 

주황색은 생산자가 만들어 넣어놓은 상태

synchronization 문제 : 공유버퍼이기에 생산자가 동시에 도착해서 비어있는 버퍼를 생산자 둘이 동시에 데이터를 만들어 넣으면 문제가 생김. 공유버퍼에 락을 걸어 다른 프로세서의 접근을 막아서 해야함. 

또다른 문제: 버퍼가 유한하기에, 생산자들이 한번에 도착해서 다 만들어서 다 채웠는데 생산자가 또 도착해서 만들고싶으면 

생산자 입장에서는 자원의 개수가 0이라 볼 수 있음. 데이터를 집어넣을 빈 버퍼가 없으니 (소비자가 나타나 데이터를 꺼내가야만 새롭게 만들어야함) 생산자 입장에서의 자원은 버퍼의 개수! 비어있는 버퍼가 있으면 만들 수 있으니까!!!

소비자 입장에서는 내용이 들어있는 버퍼가 자원인거지!

semaphore를 이용해서 2가지 일을 해줘야함!

1. 둘이 동시에 공유버퍼를 접근하는 것을 막기 위해서 공유버퍼 전체에 Lock을 걸어서 배타적으로 접근 할 수 있게하고, 접근이 끝났으면 lock을 풀어줘야함

2. 버퍼가 가득 차거나 비었을때, 가용 자원의 갯수를 세는 counting semaphore

Readers and Writers Problem

Reader는 여럿이 같이 할 수있고, readcount는 reader들이 몇명인지 세는것 

readcount 변수에대한 Lock을 걸기위한 mutex를 둠!

DB에 대한 lock을 걸기 위해 db를 사용했고, readcount라는 변수에대해 lock을 걸기 위해 mutext사용

 

Dining-Philosophers Problem

젓가락을 두 개 모두 집을 수 있을 때에만 젓가락을 집을 수 있게한다!

semaphore self[1]=0 //이러면, 1번 철학자가 젓가락 2개를 다 잡을 수 없다는 것!

semaphore self[3]=1 //이러면, 3번 철학자가 젓가락 2개를 모두 다 잡을 수 있는 권한이 있다는 것

 

Monitor

Semaphore문제점 

- 코딩하기 힘들다

- 정확성 (correctness)의 입증이 어렵다

- 자발적 협력(voluntary cooperation)이 필요하다.

- 한번의 실수가 모든 시스템에 치명적 영향

 

예시

V(mutex)                                              P(mutex)

Critical Section                                   Critical Section       

P(mutex)                                              P(mutex)

⬇️                                                          ⬇️

Mutual exclusion 깨짐                         Deadlock 발생

 

동시 수행중인 프로세스 사이에서 abstract data type의 안전한 공유를 보장하기 위한 High-level synchronization construct

monitor monitor-name
{
	shared variable declarations
    procedure body P1(...){
    - - -
    }
	procedure body P2(...){
    - - -
    }
	procedure body Pn(...){
    - - -
    }
    {
    	initialization code
    }

}

semaphore와의 차이점은 lock을 걸 필요가없다는것

모니터는 모니터 내부에 공유변수에대한 변수를 선언을 해두고, 공유데이터를 접근하기 위한 프로시져들은 모니터 내부함수로 구현해놓음 초기화 함수도 포함이 되어있음

semaphore에서 자원의 갯수를 세거나 이런건 필요함

락을 거는것을 할 필요는 없지만, 자원이 몇개인지를 세고 자원이 있으면 접근할 수 있게 해주고 자원이 없으면 기다리게하는 것이 여전히 모니터에도 필요함 그걸 위해 semaphore 변수처럼 비슷한 역할을 해주는 condition variable이 모니터에 있음

Condition variable

• x.wait(): x.wait()을 invoke한 프로세스는 다른 프로세스가 x.signal()을 invoke하기 전까지 suspend된다.
• x.signal(): x.signal()은 정확하게 하나의 suspend된 프로세스를 resume한다. suspend된 프로세스가 없으면 아무 일도 일어나지 않는다.

x라는 자원이 여분이 있으면, 바로 접근을 하게 해주고, 여분이없어서 기다려야한다면 기다리게 해주는것이 x.wait(), 접근을 다 하고 빠져나갈때에는 signal 호출해서 혹시 기다리고 있는 프로세스가 있으면, 빠져나갈 수 있게 해줌.

 

모니터에서는 lock을 걸거나 풀 필요가 없다. 공유 버퍼가 모니터안에 정의가 되어있기 때문에!!!! 생산하거나 소비하려면 모니터 내부 코드를 실행을 해야하고, 생산자든 소비자든 하나의 프로세스만 모니터안에서 활성화 되기 때문에!! 굳이 lock을 걸지않아도 됨

full 은 내용이 들어있는 buffer를 기다리면서 줄세우는 역할을 하고, empty는 빈 buffer를 줄 세우는 방식

공유데이터에 대한 접근은 모니터가 막아주고 있고, 어떤 조건이 충족되지 않으면 특정 줄에가서 줄세워놓는 코드는 자연스러운것