[UCB CS162 OS] Lec07 Synchronization(2)

Producer-Consumer with bounded buffer

• producer는 shared buffer로 여러가지를 넣고, consumer는 여기서 꺼내어 쓰는 구조로, 이를 적절히 동기화시켜야 한다.

Semaphores

• non-negative integer value로 down() or P()(positive가 되기를 기다리다가, 1을 감소시킨다. wait() operation과 유사)과 up() or V()(1을 증가시키고, 기다리는 P를 깨운다. signal() operation과 유사)
  • (개인적인 평가: 입장권의 개수가 제한되었다고 생각할 수 있을 것 같다.)
• semaphores에서는 negative value가 없고, 초기 설정을 제외하고는 어떤 value를 쓸 수는 없다(P, V만 해야한다). 또한 operation이 atomic해야 한다.

Two uses of semaphores

• Mutual Exclusion(initial value = 1) 내지 Binary Semaphore
• Scheduling Constraints(initial value = 0): 특정 스레드가 다른 스레드의 signal을 기다리게 한다. 즉 다른 스레드가 특정 스레드를 스케줄하는 효과다.

Revisited Bounded Buffer

• 우리는 consumer, producer에 대해 각각 scheduling constraint가 필요하고, buffer queue 접근에 대한 mutual exclusion이 필요하다. 따라서 이에 대해 각각 별도의 semaphore를 사용한다.

• 위에서 semaP의 순서는 중요하다. mutex가 먼저 오면 deadlock에 걸릴 수 있다. 하지만 semaV의 순서는 바뀔 수도 있다. 다만 스케줄링 차원에서 효율성에 영향을 줄 수는 있다.

Interrupt Enable/Disable

• uniprocessor라면 interrupt를 불가능하게 함으로써 context-switching을 막을 수 있을 것이다. 하지만 이러한 권한을 user에게 주어서는 안 될 것이며, real-time system에서는 중간의 critical section이 너무 길어지면 문제가 될 수 있다.
• 그래서 lock variable을 만들고 이 변수에 대한 연산을 하는 동안에만 mutual exclusion을 적용할 수 있다. 이러면 disable~enable 사이에서 비교적 짧은 critical section을 갖는 장점이 있다.

• 그런데 Acquire()에서 sleep하기 전 언제 interrupts를 다시 가능하게 할 지에 대한 문제가 있다. 만약 wait queue에 넣기 전에 enable시킨다면, 아직 queue에 들어가지 않았는데 다른 데서 Release()가 먼저 일어나버릴 수 있다. 만약 wait queue에 넣은 직후에 한다면, 다른 데서 깨워주었지만 go to sleep()으로 인해 wakeup을 놓칠 수 있다.
• 결국은 그 이후에 interrupts를 가능하게 해야 한다는 의미다.
  • 원래 스레드가 잠들게 됨에 따라, 스케줄러가 다른 스레드를 다시 실행시키고 interrupts를 enable시키고 할 일을 하다가, 다시 원래의 스레드가 깨어나서 interrupts를 re-enable시키고 critical section으로 들어가게 된다.