KOCW.이화여자대학교.반효경.운영체제
위 강의를 바탕으로 학습 및 정리했습니다

---

1

• 세마포 연산에서 생길 수 있는 문제인 데드락과 동기화와 관련된 전통적인 세 가지 문제에 대해 알아본다.

전통적인 동기화 문제

• Bounded-Buffer Problem (Producer-Consumer Problem)
• Readers and Writers Problem
• Dining-Philosophers Problem

Semaphores

• P : 공유데이터 획득하는 과정
• V : 공유데이터를 반납하는 과정

2 Types of Semaphore

• 자원을 세는 것을 왜 Semaphore로 햇느냐
  • P연산을 해서 하나 남은거 획득 하는 도중에 CPU 빼았기고
    다른 프로세스 입장에서 하나 남았네? 하고 가져간다면
    두 프로세스가 공유데이터 하나를 가지고 경쟁하는 상황 발생

근데 Semaphore는 코딩을 조금만 잘못해도 문제 발생 -> Deadlock and Starvation

Deadlock and Starvation

• S, Q 중 S를 먼저 획득해야 한다 같은 조건을 걸어주면 데드락 해결 가능

Bounded-Buffer Problem (Producer-Consumer Problem)

• 버퍼 자체가 공유데이터

• 이 공유 버퍼 문제도 비슷함

• 생산자가 비어있는 버퍼를 확인하고 데이터를 집어넣으려는 순간 CPU를 뺏기고
  다른 생산자가 같은 자리의 버퍼를 보고 비어있는걸 확인하고 데이터를 넣으려 하면
  두 생산자가 같은 버퍼 자리를 경쟁하는 상황 발생

• 소비자 프로세스도 똑같음 (같은 데이터를 노리는 상황)

• 이런문제가 있는데 공유버퍼를 어떻게 관리해야하는가
  -> 공유 버퍼에 Lock을 걸어서 다른 생산자, 소비자의 접근을 막고 확실히 처리한 뒤 다음 위치를 가르키도록 짜서 해결 (동시접근 막기)

• Lock 걸기 -> binary Semaphore 이용

• 내용이 들어있는 버퍼/ 비어있는 버퍼 세는 것-> Counting Semaphore

Bounded-Buffer Problem

• 위 문제에 대한 코드
• mutex == Lock

1. 소비자 프로세스가 버퍼 하나 떼감
2. Lock 검
3. 해당 데이터 이용함
4. 다 쓰고 Lock 풀어주고 빈 버퍼 생김
5. 생산자 프로세스가 버퍼 비어서 가져감
6. Lock 검
7. 채워진 버퍼 내놓음
8. 1~6 반복

Readers and Writers Problem

• 읽고 쓰는 문제가 DB에서 주로 발생하기 때문에 공유 데이터 == DB
• 읽는 프로세스는 여럿이 읽어도 문제가 없음
  -> Reader들은 동시에 접근 가능하게 함
• Writer는 무조건 하나만 접근 가능
• readcount도 공유데이터임
  -> 얘도 Lock(mutex) 필요

• 위 문제에 대한 코드
• if readcount == 1
  • DB 쓰는 사람이 없던거니까 DB에 Lock걸어야함
• if readcount != 1
  • DB 쓰던 사람이 있었으니까 누군가 이미 Lock 안걸어도됨 (다른 reader가 이미 걸어놓음)
• 나갈때도 마찬가지
  내가 마지막으로 나가는거면 DB Lock 풀고나가고
  마지막으로 나가는거아니면 안풀어도됨

Starvation 발생
왜냐? reader가 끊임없이 도착하면 writer는 계속 기다려야함
-> 횡단보도처럼 일정시간까지 도착한 reader들만 읽게하고 끊은다음 신호등 파란불처럼 writer에게 write 기회를 줌

Dining-Philosophers Problem

• 철학자 모두 배고파지는 시간이 다름
  -> 근데 동시에 배고파지고 모두 왼쪽젓가락을 잡아버리면 ? (잡은 젓가락은 절대 놓지 않음)
  -> 데드락 발생
  
• 1번 해결책
  • 최대 4명만 앉히자
• 2번 해결책
  • 젓가락 두개 다 잡을 수 있을 때만 잡게하자
  • 오른쪽 젓가락 잡았는데 왼쪽 젓가락이 사용중일 때 문제가 발생하므로
• 3번 해결책
  • 
  • S, Q 중 S를 먼저 획득해야 한다 같은 조건을 걸어주면 데드락 해결 가능
  • 이거랑 같은 개념

-> 사용하는 코드는 2번 해결책임

• 이 코드는 Monitor 방식을 고스란히 Semaphore 방식으로 전환시킨 거라 Semaphore 본연의 특징을 이용한 코드랑 다르게 좀 복잡함

• Semaphore self 초기값 0 으로 출발

  • test해서 양쪽 젓가락을 들 수 있을 때 1로 바꿔주는거임

• enum(상태를 나타내는 변) 을 보면 hungry 상태 추가함

  • 이 상태를 나타내는 변수를 건드릴때 Lock을 위해 semaphore mutex 사용

• 내려 놓을 땐 test로 양 옆 철학자 헝그리 상태인지 확인하고 젓가락 내려놓음

2

• 동기화 문제 해결을 위해 세마포 이외의 모니터 방식에 대해 알아본다.

Monitor

• Semaphore는 공유데이터 카운트, Lock을 거는 것 같은 연산을 제공했을 뿐 개발자가 공유데이터 접근 및 동기화 문제 자체를 해결해줬던 게 아님

• 근데, 모니터는 모니터 안의 프로시저를 이용해서 공유데이터에 접근 가능하므로 자연스럽게 동기화문제 해결 가능

• 모니터를 추상적으로 그림으로 그린 것
• 공유데이터를 모니터 안에 정의를 해놓음
  -> 공유데이터 쓰려면 모니터 안으로 들어와야함
  -> 이미 모니터 안에 공유데이터 쓰는 프로세스가 있으면
  -> 다른 프로세스의 접근을 아예 막는 것으로 동기화 문제 해결 가능

• 모니터는 condition 변수를 사용해서 자원의 유무를 파악 및 관리
  • 자원이 없으면 프로세스를 wait() 함수 불러서 큐에 대기시켜놓음

• condition이 자원의 개수를 세진 않음
  • 있는지 없는지만 확인하고 처리함
    -> 코딩하기/이해하기 편리함 (세마포를 이용할 땐 P,V 연산 하나하나 다 이해하는 등의 행위가 필요)

• 철학자 문제 모니터로 해결한거