[CS/운영체제] CH6. 프로세스 동기화(동기화 관련 문제, 모니터)

CH3. 프로세스 동기화(동기화시 발생할 수 있는 문제, 모니터)

 

목차

1. Classical Problems of Syncronization

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

2. Monitor

 

---

 

1. Classical Problems of Syncronization

 

동기화시 발생 할 수 있는 대표적인 문제들 3가지를 알아봅니다

 

아래 나오는 코드들은 Semaphores연산을 block/wakeup으로 구현한 코드를 이용합니다

(block/wakeup은 busy-wait보다 효율적인 방법)

 

Semaphores와 Block/Wakeup

 

Semaphores

Block/Wakeup 1

Block/Wakeup 2

 

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

 

 

Buffer

 이렇게 생긴 공유 데이터에서 Producer는 빈 버퍼칸에 데이터를 생산하고 Consumer는 데이터가 들어 있는 버퍼칸에서 데이터를 가져오고 있는 상황입니다.

 

 

이 경우에 발생 할 수 있는 동기화 문제들입니다.

 

1. 같은 buffer 칸에 여러 Producer가 동시에 buffer에 data를 생산하거나

    같은 buffer칸에 있는 data를 여러 Consumer가 동시에 소비하는 경우 어떻게 해결해야 할까요?

 

2. 너무 많은 Producer가 buffer에 data를 생산하여 공유 데이터칸이 꽉 찼는데 또 다른 Producer가 data를 생산하려 합니다. 어떻게 해결해야 할까요?

 

아래 그림을 같이 보시죠

 

 

1번 문제는 Producer나 Consumer가 한 buffer에대해 data를 쓰거나 가져올 때 그 공유데이터에 lock을 걸어 자신만이 그 buffer를 조작하고 일이 끝나면 lock을 푸는 것으로 해결 할 수 있습니다

 

2번 문제는 full buffer와 empty buffer의 수를 관리하면서 Producer의 경우 empty buffer가 없다면 기다리다가 empty buffer가 생기면 다시 buffer에 data를 채워넣는 일을 진행하는 식으로 해결 할 수 있습니다.

 

 

 

문제를 해결한 Semaphores 코드를 살펴봅시다

Producer의 경우 일단 empty buffer가 있는지 확인을 해보고 없다면 blocked로 기다립니다

empty buffer가 있다면 P(mutex)로 공유 데이터에 lock을 걸고 buffer에 data를 넣은 뒤

끝나면 V(mutex)로 lock을 풉니다. V(full)은 data가 들어있는 buffer의 수를 하나 늘립니다

 

V(full)이 일어날 때

Consumer쪽에서 full buffer가 없어 blocked가 되어 있던 consumer를 wakeup합니다. full buffer가 생겼다는 신호를 받았으니 이제 일어나서 일을 해야겠죠. Consumer도 Producer와 같은 방식으로 진행됩니다

 

 

1-2 Readers-Writers Problem

 

 DB가 있다고 생각을 해봅시다. 한 프로세스가 DB에 write를 하고 있는데 다른 프로세스가 그 DB를 읽으면 동기화에서 문제가 생기겠죠?

 물론 read는 동시에 여러 프로세스가 진행해도 동기화에 문제가 생기진 않을 것 입니다.

 

Readers-Writers Problem

 

솔루션이 친절히 다 적혀있네요 한 번 읽어보시고 Semaphores 코드를 살펴봅니다

 

 

 Writer쪽은 write 할 때 db에 lock을 걸고 write가 끝날 때 db에 걸린 lock을 풀어주는 일만 하면 됩니다.

 

 Reader쪽이 조금 복잡한데요

 일단 readcount라는 shared data를 조작해야 하니까

 readcount를 lock 하기 위한 P(mutex)를 하고

 readcount를 1 늘립니다

 readcount가 1인 경우 P(db)로 writer가 공유데이터에 접근하는 것을 lock을 걸어버립니다

 readcount가 1보다 큰 경우는 이미 다른 누군가가 P(db)로 lock을 걸어 버렸겠죠?

 다시 V(mutex)로 readcount에 대한 lock을 풀고

 DB를 읽고

 

 다 읽었으니 readcount를 줄이기 위한 P(mutex)를 걸고 readcount를 줄이고

 readcount가 0이되면 writer가 db에 write 할 수 있게 V(db)로 lock을 풀어줍니다

 readcount가 0이 아니라는 뜻은 다른 Reader가 현재 db를 읽고 있다는 뜻이겠죠?

 다시 V(mutex)로 readcount에 걸린 lock을 풀어줍니다.

 

 이론상 완벽한데 딱 한가지 문제가 더 생길 수 있습니다.

 reader가 끊임없이 들어와서 계속해서 db가 lock에 걸린 경우 writer는 write를 하지 못하고 굶어 죽게 됩니다.(Starvation 발생)

 이를 방지하기 위해 도로의 신호등 같이 일정 시간마다 writer가 무조건 db에 write를 할 수 있게 어떻게 조작을 한다고 하는데 여기까지는 살펴보지는 않겠습니다. 이런 문제가 있을 수 있다 정도만 생각하시면 됩니다.

 

 

1-3 Dining-Philosophers Problem

 

 다섯명의 철학자들이 식사를 하고 있습니다

 이 철학자들은 밥먹다가 사색하다가를 반복하는데요

 각 철학자 사이에 젓가락을 한 개씩 두고

 식사를 할 때 양옆의 젓가락을 가지고 식사를 하고 식사를 마치면 다시 젓가락을 양 옆에 놓습니다

 

 대체 왜들 이러시는지는 모르겠지만

 밑에 코드를 보고 문제점을 한 번 찾아 볼까요?

 

 

 위의 코드에서 대표적으로 두 가지 문제점을 찾아 볼 수 있습니다

 1. 양옆의 철학자들이 식사를 계속하면 중간의 철학자는 젓가락을 집을 수 없어 굶어 죽습니다.(Starvation 발생)

 2. 모든 철학자가 동시에 식사를 하기 위해 왼쪽 젓가락을 집어버리는 순간 모든 철학자는 오른쪽 젓가락을 찾지 못해 식사를 시작하지 못하고 누군가 젓가락을 다시 놓기전까지 모두 왼쪽 젓가락을 들고 가만히 있게 됩니다.(Deadlock 발생)

 

 위 해결 방안을 Semaphores 코드로 살펴 볼 것인데요

 이해하기가 정말 어려울 것입니다. 아래 배울 Monitor를 이용하여 코드를 짠 것을 억지로 Semaphores로 바꾼 것인데 코드에 대한 설명은 Monitor를 보고 하겠습니다.

 

2. Monitor

 위에서 Semaphor로 작성한 코드들을 보며 어떠셨나요?

 

 

 이런 불편함들이 느껴졌다면 정상입니다.

 이를 해결 해주는 것이 바로 Monitor인데요

 

Monitor란

모니터 내에서는 한 번에 하나의 프로세스만이 활동 가능하고

condition variable과 wait() signal() 만 아시면 밑에 코드들은 다 이해하실 수 있습니다

 

 

요것은 이해할 필요가 없어요

Monitor 도식화

 

Monitor로 Bounded-Buffer Problem을 해결하는 코드입니다

 

 

 producer의 경우만 생각해보면

 produce를 할 때 empty buffer가 없다면 empty라는 condition variable의 큐에서 wait 상태가 됩니다

 empty buffer가 있다면 full에 signal을 보내 full의 큐에서 wait 상태로 기다리고 있는 프로세스를 깨웁니다.

 

 우리가 보던 일반적인 코드 같고 더 직관적인 것을 알 수 있습니다.

 

  이제 다시 철학자 분들이 굶어 죽지 않게 monitor로 문제를 해결해 봅시다

 

 그래도 복잡하긴 하지만 쭉 읽어보면서 그림을 그려보면 해결이 되는 것을 알 수 있습니다.

 코드 해석하는 것은 각자 해보시는 걸로..

 

---

예상 면접 질문
이 부분에서는 용어를 물어보는 경우는 없을 것 같습니다
대신 위와 같은 간단한 문제 상황을 주고 세마포어를 이용해서 문제를 해결해 보라던가
모니터로 문제를 해결해 보라는 경우가 있을 수가 있긴 하겠네요

ex)
같은 db를 공유하며 그 db에 write하는 프로세스와 그 db를 read하는 프로세스가 있다고 가정 해 봅시다.
이 때 어떤식으로 프로세스 동기화 문제가 생길 수 있을까요?
세마포어로 그 동기화 문제를 해결해보세요

 read 프로세스가 일어나고 있는데 write 프로세스가 db에 접근해서 write 해버리면 프로세스 동기화 문제가 생길 것입니다.

 write 프로세스 입장에서는 write 할 때 공유 데이터인 db에 lock을 걸어버려 write 도중 read 프로세스의 접근을 막아버리고

 read 프로세스 입장에서는 read를 할 때 공유 데이터인 db에 writer프로세스만 lock을 걸어버려 read 도중 write 프로세스의 접근을 막아 버리는 간단한 해결법이 있습니다. read 프로세스들은 동시에 read 해도 동기화 문제가 일어나지 않기에 lock을 걸지 않습니다.

 이를 조금 더 개선하려면 readcount와 같은 동기화 변수를 두고 최초의 reader가 생길 때만 db에 lock을 걸어버리고 마지막 reader가 read를 마치면 db에 걸린 lock을 풀어 버릴 수 있겠습니다.

물론 이 방법도 완벽하지는 않습니다. read 프로세스가 끊임없이 db를 read하면 writer가 write를 하지 못하는 starvation이 발생 할 수 있기 때문입니다. 이는 write 프로세스에게 write 할 시간을 보장해주는 방법으로 해결 할 수 있을 거라 생각합니다.