Process Synchronization 4: Monitor

Monitor

• Semaphore의 문제점

  • 코딩하기 힘들다, 정확하게 코드 구현을 해야 함

  • 한번의 실수가 모든 시스템에 치명적 영향, P, V 연산 순서를 바꾼다든지 하는 실수 발생할 수 있음

    

• Monitor

  • 프로그래밍 언어 차원에서 Synchronization을 보장하는 추상자료형
  • 내부의 프로시저를 통해서만 공유데이터에 접근 가능 함
  • 모니터 안에 active하게 들어가서 수행할 수 있는 프로세스를 하나만 허용하는 작업을 모니터 자체가 제어

• 프로그래머는 모니터가 알아서 공유데이터에 대한 접근을 제어하기 때문에 lock, unlock 등에 대한 설계가 필요 없음

• 모니터 내의 active한 프로세스가 없을 때 진입 대기 중인 프로세스가 모니터에 진입하여 shared data에 접근하는 코드를 수행할 수 있음

• 모니터 내부 프로시저는 동시에 여러 개가 실행되지 않도록 통제: 하나의 프로세스만이 활동 가능함, 따라서 프로그래머 입장에서는 semaphore와 다르게 lock을 거는 코딩을 할 필요가 없어 편리함(동시 접근이 허용되지 않는 자료로 구현되어 있으므로), 버퍼에 대한 접근 제한 및 허용 처리가 따로 필요 없음

• 특정 조건에 따라 sleep하게 되는 프로세스들은 condition variable queue에서 대기, 이 condition을 semaphore처럼 어떤 값이 아니라 대기 queue임

• wait과 signal이라는 연산을 통해서 조건을 만족하지 않는 프로세스들을 잠들고 깨울 수 있음, x.wait() 하면 x라는 조건을 만족하지 않을 때 해당 queue에 대기하도록 보내는 연산.
  

Q. 모니터 안에서 사용 가능한 버퍼가 없을 때 대기하는 condition variable의 queue와 entry queue는 어떻게 동작하는거지? 우선 모니터 안에 프로세스가 실행중이면 entry queue에 대기하고, 만약 들어간 프로세스가 가용 자원이 없으면 condition queue로 들어가는 건가?

• 만약 모니터 안에 있던 프로세스가 CPU를 빼앗기면, 이때 모니터 안의 프로시저는 active한 상태이므로 다른 프로세스가 모니터로 들어오지 못 하고 entry queue에서 대기하게 됨.

• 모니터에 들어갔다가 가용 자원 문제로 suspend 당하면 condition queue에서 대기하다가, 다른 프로세스가 수행을 마치고 signal을 보내줄 때 순서대로 condition queue에서 빠져나와서 작업을 수행하게 됨.

• Producer-Consumer Problem with Monitor

  • semaphore를 사용할 때와 달리 P(mutex), V(mutex) 연산이 없음, 다른 프로세스의 접근을 따로 막아주지 않아도 모니터가 접근을 막아주기 때문에
  • empty or full buffer가 있는 지는 flag 등 다른 변수를 통해 확인
    

• Dining-Philosopher Problem with Monitor

---

• 실무에서 race condition이 발생할 수 있어서 thread에 대한 동시성 제어를 해야할 경우가 있을까? 그럴 경우에는 semaphore를 이해하고 P연산 V연산을 이용한 코딩을 하는 거보다 이렇게 모니터를 이용하는 게 훨씬 편할 거 같긴하다. 라이브러리 만들어 놓고 알아서 해주겠지~ 하고 그냥 불러서 사용하는 느낌?

• 실무에서 race condition이 발생하는 경우는 뭐가 있을까?

• 실제로 좌석 예매 시스템은 어떻게 구현하는지 궁금해졌다. DB의 트랜잭션 처리를 할까? 동기화 코드를 이용할까? 프론트엔드 화면에서는 어떤 처리가 필요할까? 어떤 사용자가 특정 좌석을 클릭해서 예약을 진행중이라면 플래그를 true로 만들고 false인 경우에만 해당 좌석을 예약할 수 있도록 할까? 그럼 맨 처음에 화면을 켤 때는 false여서 해당 좌석 예매를 진행할 수 있는 줄 알고 클릭해서 예약을 진행하는데 알고보니 좌석화면을 켜고난 후에 다른 사람이 해당 좌석 예약을 진행중이면 어떻게 되나? 예약 실패 처리를 해버리면 유저는 아무것도 모르고 예약을 진행하는 수고를 해야해서 UX적인 측면에서 매우 안 좋을 거 같은데