Process Synchronization
앞서 프로세스 동기화문제를 해결하기 위한 방법설명
- 소프트웨어적으로 해결방법
- test&set이라는 하드웨어적인 해결방법
- 추상자료형 세마포어 해결방법
세마포어
세마포어의 p연산과 v연산이 있는 추상자료형이 있다.
p는 자원을 획득하는 연산이고, v는 자원을 반납하는 연산이다.
p연산과 v연산으로 프로세스 동기화를 지원한다.
세마포어는 block/wakeup형태로 구현할 수 있다.
하지만 프로그래머가 실수를 하게 되면 동기화가 깨지게 된다.
동기화와 관련된 3가지 고전적 문제
- Bounded-Buffer Problem(Producer-Consumer Problem)
- Readers and Writers Problem
- Dining-Philosophers Problem
Bounded-Buffer Problem
데이터를 저장하는 버퍼의 크기가 유한한 환경에서 발생하는 문제이다.
프로세스가 두가지 종류(producer, consumer)가 있다. 또한 여러개의 producer, consumer가 있다.
- producer(생산자)
- consumer(소비자)
생산자는 공유버퍼에다가 데이터를 만들어서 집어넣는 역할을 한다.
소비자는 공유버퍼에서 데이터를 꺼내간다.
생산자가 둘이 동시에 도착해서 동시에 하나의 공간에 데이터를 넣게되면 문제가 발생한다. 그렇기 때문에 공유버퍼에 락을 걸어서 데이터를 집어넣고, 다 집어넣고 락을 풀어서 공유버퍼에 접근할 수 있게 해야한다.
소비자도 여러 소비자가 동시에 하나의 공유버퍼에 접근하려고 하면 문제가 발생하므로 락을 걸고 풀어서 접근을 제한하는 것이 필요하다.
버퍼가 유한하기 때문에 발생하는 문제
생산자입장
생산자가 동시에 여러명이 도착해서 버퍼에 데이터를 저장했는데 꽉찼다.
그러면 생산자 입장에서는 사용할 수 있는 자원이 없게 된다.
소비자가 데이터를 꺼내 가기 전까지 빈 버퍼는 발생하지 않는다.
생상자 입장에서는 비어있는 버퍼의 갯수가 자원이다.
비어있는 버퍼가 없다면, 생산자 프로세스는 소비자 프로세스가 버퍼에 있는 데이터를 꺼내가기 전까지 기다려야 한다.
소비자입장
소비자 입장에서는 많은 소비자가 버퍼에 있는 공유자원을 모두 꺼내가서 더이상 꺼내갈 데이터가 없다면, 생산자프로세스가 데이터를 버퍼에 집어 넣을 때 까지 기다려야 한다.
세마포어를 이용해서 해야할 업무가 두가지 있다.
- 동시에 공유버퍼에 접근하는 것을 막아야 한다.
- 버퍼가 가득 차거나, 없을 때 가용자원의 갯수를 세는 세마포어 변수가 필요하다.
공유데이터는 공유버퍼자체가 된다.
락을 걸고 푸는 역할로 세마포어변수가 필요하다.
자원의 갯수를 세는 역할로 세마포어변수가 필요하다.
mutex=1 락을걸기 위한 세마포어
empty=n 비어있는 것을 세기 위한 세마포어
full=0 가득차있는것을 세기 위한 세마포어
Readers and Writers Problem
읽는 프로세스와 쓰는 프로세스 두가지가 있다.
여기도 공유데이터가 있다. 여기서는 db라고 명명을 했다.
db에서 데이터를 읽어가거나 쓰는 두 종류의 프로세스가 있다.
공유데이터인 db를 동시에 접근하면 안 되기 때문에 락을 걸어서 제한해주어야 한다.
쓰는 작업은 동시에 하면 안되지만, 읽는 작업은 동시에 작업이 가능하다.
누군가가 쓰는 동안에는 디비에 접근을 못하게 하지만, 읽는 것에 대해서는 공유가 할 수 있게 하는게 문제이다.
읽을 때도 락은 걸어야 되지만 읽는 프로세스에 락을 거면, 다른 프로세스가 와도 읽을 수 있게 해야한다.
db가 공유데이터인데 읽는 것은 동시에 가능하게 되어야하므로 몇명이 읽는지 readcount라는 공유데이터를 두어서 mutex 락을 걸고, 다 읽고 나갈 때 mutex를 풀어서 write가 기다리고 있다면 접근할 수 있게 해야한다.
위의 수도 코드상에서는 읽고 있는 상태에서 동시에 읽을 수 있으므로 계속 읽는 프로세스가 들어오게 되면, 뒤에서 기다리는 write프로세스는 계속 기다려야 한다. 이때 기아현상이 발생할 수 있다.
Dining-Philosophers Problem
데드락의 가능성이 있다. 아무것도 진행이 되지 않고 멈추어 있는 상태
모두가 왼쪽 젓가락을 잡고 있다면, 오른쪽 젓가락을 잡고 있기 때문에 아무도 먹지 못하고, 진행도 된지 않기 때문에 데드락이 발생할 수 있다.
Monitor
모니터에서는 세마포어와 같이 락을 걸고 풀 필요가 없다.
프로세스가 동시에 동작하면 생기는 문제를 해결하는 것이라는 측면에서 같다.
프로그래밍 언어 차원에서 공유데이터에 접근하는 것을 모니터가 자동으로 제공함으로써 프로그래머의 부담을 줄여준다.
공유데이터를 접근할 때는 코드를 모니터안에다가 공유데이터와 접근코드를 정의해서, 프로세스가 공유데이터에 접근하려고 하면, 모니터안에 있는 코드로만 접근하게 한다.
공유데이터를 동시에 접근하려고 하면, 모니터가 초기에 막아서 제어한다.
프로그래머가 락을 걸고, 락을 푸는 것을 할 필요가 없이 모니터가 접근을 제어한다.
예를들어 특정 프로세스가 모니터안에 들어와서 공유데이터를 접근하는 코드를 실행하고 있는데 접근하는 도중에 프로세스가 cpu를 빼앗끼고, 그때 또 다른 프로세스가 공유데이터에 접근하려고 한다면,
이미 모니터 안에 cpu를 빼앗긴 프로세스가 엑티브한 상태로 남아 있게 되는데, 다른 프로세스가 공유데이터에 접근하지 못하게 막고 밖의 q에서 대기하게 된다.
q에 있는 프로세스들은 모니터 안의 프로세스가 없게 되면, 들어와서 작업을 할 수 있다.
모니터에서는 락을 걸고 푸는 작업이 필요가 없다.
모니터에는 condition variable을 둘수 있다.
모니터안에서 코드를 실행하다가 조건이 충족되지 않아서 다른 프로세스들이 오래 기다려야 한다면, 해당 프로세스를 잠들게 한다. 조건에 해당하는 것을 변수로 둘 수 있고, 이 변수를 condition variable이라고 한다.
condition variable은 세마포어처럼 어떠한 값을 가지는 변수가 아니라 프로세스를 잠들게 하고 줄세우기 위한 변수이다.
wait 와 signal 연산이 있다.
프로세스를 잠들게 하기 위해서는 x.wait()연산을 하면 condition에 가서 줄을 서게 된다.
x.signal은 잠들어 있는 프로세스가 있으면 그 중에 하나를 깨워주라는 연산이다.
생산자-소비자 문제
세마포어의 경우는 락을 걸고 푸는 작업이 있다면, 모니터에서는 락을 걸고 푸는 작업이 없다.
세마포어와 모니터의 목적이 다르다.
모니터는 동시접근을 하는 것을 모니터 차원에서 막는 것이고,
세마포어는 자원을 획득하기 위해서 p연산 v연산을 하는 것이다.
하지만 코드를 구현하면 비슷한 형태가 된다.
