[운영체제] Process Synchronization 3 : 고전적인 Synchronization Problem 예제

본 포스팅은
https://core.ewha.ac.kr/publicview/C0101020140408134626290222?vmode=f
을 정리했습니다.

---

고전적으로 Synchronization과 관련된 3개의 문제가 있다. 하나씩 살펴보자.

1. Bounded - Buffer Problem(Producer-Consumer Problem)

원형인 자료구조에, 데이터를 만들어 채우는 생산자, 꺼내서 쓰는 소비자가 있다.
여기서 발생하는 문제는 크게 두 가지다.

• 생산자들(혹은 소비자들)이 동시에 같은 공간(혹은 데이터)를 사용하려고 할 때
• 버퍼가 꽉 차서 생산자가 더 이상 만들 수 없거나, 버퍼가 비어서 소비자가 쓸 데이터가 없을 경우

이 문제를 해결하기 위해선 Buffer를 하나의 공유 자원으로 보고, lock을 걸어야 한다.(mutual exclusion)
또한 남은 공간, 남은 데이터의 갯수(resource count)를 표시해줘야 한다.
(다음에 여기서 쓰라고 포인터도)

이것을 코드로 풀어내면 이렇다.

생산자든 소비자든 단 한놈만 공유자원(버퍼)에 접근할 수 있다.

empty는 공간이며, full은 누가 생산해놓은 데이터가 있다는 것이다.

파란 P와 V는 버퍼에 들어가는 세마포어고,
P(empty)는 생산자가 데이터를 쓸 공간이 있는지를 쳌 하는 것이다.
데이터를 쓴 후에는 V(full)을 해줘 여기 데이터 있다를 표현해준다. 그래야 다음 소비자가 P(full)로 사용 가능한 데이터가 있는지 체크하니까.

2. Readers-Writers Problem

• 한 프로세스가 DB에 write 중일 때, 다른 프로세스가 접근하면 안됨

• read는 동시에 여럿이 해도 됨

• 해결 방법
  -Writer가 DB에 접근 허가를 얻지 못한 상태면 모든 대기중인 Readr들은 DB에 접근하게 한다.
  -Writer는 대기 중인 Reader가 하나도 없을 때 DB 접근이 허용된다.
  -일단 Writer가 DB에 접근 중이면 Reader들은 접근이 금지된다.
  -Writer가 DB를 빠져나가면 Reader의 접근이 허용된다.
  

여기서 필요한 공유 데이터 : DB 자체, readcount(동시에 카운트를 올릴 수 있으니 여기도 접근 제한 걸어줘야 한다.)
synchronization variables : mutex, db

되게 당연해 보이지만, reader들은 동시에 접근이 가능하다는 점이 까다로울 수 있다.

Reader 부분을 보자.
readCount도 공유 변수라고 했으니, 동기화 문제 나지 않게 P(mutex)를 해준 것이다.
만약 내가 첫번째 reader면, writer가 접근 못하게 P(db)를 걸어버린다.
이제 reader들은 동시에 몰려도 상관이 없다.
나갈 때는 readcount--를 하고, 혹시 내가 마지막 reader인지를 체크해서, 마지막이면 writer도 사용 가능하게 V(db)로 풀어준다.
참 쉬워보이는데, 수준 높은 코드라고 한다.

여기서도 Starvation이 발생 가능하다. 리더가 계속 몰리면, 작가는 글을 쓸 수가 없다.

3. Dining-Philosophers Problem

지난 포스팅에서 다뤘었는데,자세히 살펴보자.
철학자는 두 가지 행동만 한다. 생각하거나, 먹거나.
먹을 때는 젓가락 두개를 모두 집어야만 먹을 수 있다.

이 상황에서는 데드락, 스타베이션 둘 다 발생할 수 있음을 이미 확인했다. 어떻게 해결해야 할까?

• 5명이 아니라 4명만 앉게 한다.
• 젓가락을 두 개 집을 수 있을 때만 집게 하라

등이 있을 수 있겠다.(걍 읽고 넘어가자.)

코드로 확인하자면,

세마포어라고 했는데 여기서는 enum을 쓰는 것이 특이하다.
(교수님은 이를 세마포어라고 부르기 좀 애매할 수도 있다고 하신다.)

난 어려워서 그냥 넘어갔다.

Monitor

세마포어 문제점

• 코딩하기 힘들다.
• 자발적 협력이 필요하다.
• 한번의 실수가 모든 시스템에 치명적 영향을 미친다.

개발자 입장에서 코딩하기 ㅈㄴ 까다롭다는 것이다.

이를 위해 요즘엔 Monitor를 많이 쓴다고 한다.

위 그림과 같이 공유 데이터와 operation들을 하나의 모니터 바운더리 안에 넣어놓고, 이 모니터 접근을 하나씩 하게 하는 것이다. 이미 operation들이 다 정해져 있으니 개발자 입장에서 편한 것이다.

• 모니터 내에서 한번에 하나의 프로세스만 활동 가능
• 프로그래머가 동기화 제약 조건 명시적으로 코딩할 필요 없음
• 프로세스가 모니터 안에서 기다릴 수 있도록 하기위해 condition variable 사용