6강-4. Process Synchronization 4

---

생산자 - 소비자 문제

주황색이 데이터가 들어있는 버퍼

mutual exclusion : 상호 배제

• Shared data
  • lock을 걸고, 풀고 해서 접근을 해야 한다.
• Synchromization variable
  • binary semaphore
    • ex) mutex = 1 ---> lock을 거는 semaphore 변수
  • integer semaphore
    • ex) empty = n, full = 0

p : 자원을 획득,  v : 자원 반납

 

---

 

• write : 동시에 하면 안 됨.
  • 아무도 없을 때만 배타적으로 해야 함.
• read : 동시에 해도 됨.
• 공유 데이터를 접근할 때는 lock을 걸어서 다른 프로세스의 접근을 막고 작업을 한 뒤에 lock을 풀어야 한다.

DB : 동유 데이터

읽을 때도 lock을 걸어야 함. writer 가 접근할 수 있기 때문이다.

readcount : 공유 변수

• readcount는 공유변수이기 때문에 그냥 증가시키면 문제 발생. 여러 명의 reader가 접근할 수 있기 때문.
  • 따라서 readcount에 대해서 lock을 걸 필요가 있다.
    • P(mutex) : readcount(공유변수)에 대한 lock을 걸기 위한 semaphore 변수이다.
• 읽기 위해서 lock을 건 상태에서, read 프로세스도 도착하고 writer 프로세스도 도착한 상태일 경우?
  • 먼저 도착한 순서대로 처리한다고 가정
  • 읽고 있는 도중에 1. writer 도착 2. reader 도착
  • 일단 writer는 앞에서 누가 read 작업을 하고 있으므로 대기해야 함.
  • reader는 대기 없이 바로 read 가능(같이 읽기 가능)
  • writer는 마지막으로 빠져나가는 reader가 lock을 풀어줄 때까지 대기해야 함.
    • reader가 계속 투입된다면 writer는 계속 대기해야 한다. ===> starvation
  • 그러면 어떻게 starvation을 피해야 할까?
    • 큐에 우선순위를 둬서 writer가 일정 수준을 기다리지 않게 한다.
      • 이때 reader를 잠깐 대기하도록 시키고, writer를 처리한다. 

---

 

밥먹고 생각하고 무한 반복...

• 밥을 먹기 위해서는 젓가락 2개를 잡아야 함.
  • P(chopstick [i]) : 왼쪽 젓가락
  • P(chopstick[(i+1)%5] : 오른쪽 젓가락
• 각각의 젓가락은 1로 초기화 : 동시에 2명이 잡을 수 없도록

• 모든 철학자들이 배가 고파서 동시에 젓가락을 잡을 때, 왼쪽 젓가락을 잡게 되는데 이때 아무도 오른쪽 젓가락을 잡지 못해서 deadlock이 발생한다.
• solution
  • 철학자가 밥을 먹을 때만 식탁에 앉도록 함
  • 모두 젓가락을 집을 수 있을 때 만, 젓가락을 집을 수 있게 함.
  • 비대칭

이 코드는 세마포어에 맞게 잘 짜여진 코드는 아니다. 그래서 이해하는데 불편할 수 있다.

위의 코드는 모니터 코드를 세마포어 코드로 바꿔놓은 것이다. 그래서 세마포어 철학에 맞지 않다고 보일 수 있다.

 

세마포어가 끝나면 모니터를 배울 것이다.

• 세마포어와 모니터는 프로세스 Synchronization 문제를 프로그래머 입장에서 쉽게 제공을 하기 위한 것이다.
• 세마포어를 사용해도 불편한 점이 있다.
  • 프로그래머가 실수를 하면 큰 문제가 생김
    • 모니터를 제공해서 프로그래머를 좀 더 편하게 해 줌.
    • 식사하는 철학자 문제는 모니터 코드가 더 이해가 쉽다.
  • 모니터와 세마포어는 코드가 굉장히 비슷하다.

 

• semaphore self [5] = 0; : 각각의 5명의 철학자가 젓가락 2개를 잡을 수 있어서, 젓가락 잡는 권한을 줄 것인지 말 것인지를 나타내는 세마포어 변수  0 : 권한 없음, 1 : 권한 있음
•  

5명의 철학자의 상태를 나타내는 공유 변수

본인만 상태를 바꿀 수 있게 아니라 옆에 있는 철학자도 상태를 변경할 수 있다. 

여러 철학자가 동시에 state라는 공유 변수에 대한 동시 접근을 막기 위해서 lock을 나타내는 mutex를 하나 두고 있다.

test 함수를 통해서 젓가락을 전부 잡을 수 있는지 확인한다.

왼쪽 철학자

오른쪽 철학자

상태를 eating으로 변경하고, 철학자에 대한 젓가락 잡는 권한을 준다.

v연산은 0이었던 값을 1로 바꾸는 연산이다.

여기서는 젓가락을 얻을 수 있는 권한을 v연산을 통해서 얻게 된다.

P 연산을 통해서 1이였던 값을 0으로 바꾼다.

• 만약에 test 함수에서 왼쪽, 오른쪽 철학자 중에 밥을 먹고 있었다면?
  • 젓가락 잡을 수 있는 권한을 얻지 못하고 test 함수가 끝난다.
  • p 연산을 하더라도, 젓가락 잡을 권한이 0이기 때문에 젓가락을 못 얻는다. 기다려야 한다.
  • 그러면 self [i]를 누가 1로 만드는가?
    • 인접한 철학자가 밥을 다 먹고 내려놓았을 때, 내가 젓가락을 잡을 수 있는 권한이 생길 수 있다.

왼쪽 철학자, 오른쪽 철학자를 test를 한다.

• 세마포어는 원래 자원의 개수를 세는 것
  • 초기값이 얼마냐를 두고 일을 하게 된다.
  • 근데 위에 코드는 세마포어의 철학에 맞지 않아서 

---

세마포어는 검증이 어렵다.

• 모니터는 프로그래밍 언어 차원에서 synchronization 문제를 해결하는 high level synchronization construct이다.
• 객체 지향 프로그래밍
  • 객체를 중심으로 operation이 정의가 됨.
  • 공유데이터를 접근하기 위해서는 내부 프로시저를 통해서만 접근할 수 있다.
  • 모니터는 원천적으로 내부에 있는 프로시저는 동시에 여러 개가 실행이 안되도록 통제를 한다.
    • 이렇게 되면 lock을 걸 필요가 없다. => 세마포어와 다른 점.

• 자원을 세는 건 세마포어처럼 모니터에도 필요하다.
  • condition variable
    • wait : 프로세스 대기
    • signal : 프로세스 resume

모니터 : 생산자 - 소비자 문제

• 세마포어에서는 공유 버퍼를 접근하기 위해서 lock을 걸고 풀고 했어야 했다.

세마포어 : 생산자 - 소비자

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

• empty.wait() : 비어있는 버퍼가 없다면 blocked 상태로 기다리게 한다.
• full.signal() : 내용이 들어있는 버퍼가 없어서 잠들어 있는 소비자 프로세스가 있다면 깨워준다.

• full.wait() : 내용이 들어있는 버퍼가 없다면 기다려야 한다.
• empty.signal() : 비어있는 버퍼를 기다리는 생산자가 잠들어 있다면 깨워준다.