생산자-소비자 문제
- 버퍼 : 데이터를 한 곳에서 다른 곳으로 옮길때 임시적으로 사용하는 메모리공간
비어있는 버퍼에 공유데이터를 삽입하는 생산자와 꽉찬 버퍼의 데이터를 꺼내 사용하는 소비자가 있다.
이 역시 프로세스 동기화에 관한 문제다.
생산자가 동시에 한 버퍼에 데이터를 삽입하거나, 소비자가 동시에 한 버퍼의 데이터를 꺼내 사용하는 경우 예기치 않은 결과를 반환한다.
이를 해결하기 위해 전에 설명했던 semaphore방식을 꺼내보자
해결방법
semaphore방식에 mutex변수까지 추가해서 사용한다!
아래는 생산자의 루틴이다
1. empty버퍼가 비어있으면, empty버퍼를 획득
2. 버퍼 전체에 mutex로 lock을 건다.
3. 조작이 끝나면, unlock후, full버퍼를 하나 추가!
소비자는 empty와 full버퍼만 반대로 하면된다!
읽기-쓰기 문제
여러 프로세스가 동시에 한 DB에 접근해 쓰기를 한다면, 예상치 못한 결과를 반환한다.
하지만 읽기는 상관없다.
해결방법 1
쓰기면 db자체에 lock을 걸거나, 읽기라면 mutex방식으로 락을 건후(자기 차례), db에 락을 건다.
하지만 문제점이 있다.
읽기가 계속해서 들어오면, 쓰기에 starvation이 발생한다. P(db)로 잠궈버리기 때문이다
writer-starvation의 해결법은 간단하다.
읽기요청이 일정 카운트 이상 지나면, 쓰기에 db를 넘겨주는것이다.
식사하는 철학자 문제(해결방법)
전에 소개했던 문제다. 이를 해결하는 법은 여러가지가 있다.
- 비대칭 : 짝수번째 철학자는 왼쪽 젓가락만 든다.
- 동시 : 식기를 동시에 들 수 있을때만 들게한다.
- 숫자를 줄인다 : 5자리니까, 4명의 철학자만 앉게한다.
우린 이중 동시에 들 수 있게 하는 방법을 코드로 알아보겠다.
Monitor
semaphore는 mutex와 비교하면 많은 경우의 수를 처리할 수 있지만, 단점도 있다.
인간은 누구나 실수를 한다. 한번만 잘못 해도 deadlock이나 starvation이 걸릴 수 있다.
또한, 정확성의 입증(디버깅)이 어렵다
따라서 이를 해결하기 위한 방법이 Monitor이다.
그래서 monitor가 정확히 뭐지?
공유데이터와 프로세스를 위한 환경을 따로 만드는 것이다.
- 기본적으로 한번에 하나의 프로세스만 들어올 수 있다.
- wait()와 signal()연산에 의해서만 접근이 가능하다.
monitor을 활용한 생산자-소비자 문제 해결
semaphore코드와 비슷하지만, lock이 없다.
생산자는 비어있는 버퍼가 없으면 suspend.
아니라면 버퍼를채우고 full 변수에 signal을 보낸다.
소비자는 꽉차있는 버퍼가 없으면 suspend
아니라면 버퍼에서 데이터를 빼내고 empty 변수에 signal을 보낸다.
monitor을 활용한 식사하는 철학자 문제 해결
