Windows Mutex

Two Threads, Mutual Exclusion X

• Mutual exclusion하지 않았기 때문에 출력이

  1 1
   2 2

  가 아니라

  1 2
  2 1
  ...

  이렇게 나올 수도 있다.

Two Threads, Mutual Exclusion O

• Mutual Exclusion을 해줬기 때문에 출력이 정상적으로 나온다.

  1 1
   2 2
   1 1
   2 2

Two Threads, Mutual Exclusion X, Sleep(1)

• OS에서 Sleep()을 만나면,
  해당 process(thread)를 대기 queue로 보내서 Context Switching이 발생한다.
  그래서 hThread[0]에서 Sleep()을 만났으면,
  hThread[1]로 Context Switching이 발생하여 MyThread_1이 수행된다.
  따라서 출력이

Thread 0 : 1
Thread 1 : 0
Thread 0 : 1

위와 같이 될 것이다.

Two Threads, Mutual Exclusion O, Sleep(1)

• Sleep()을 만나도 mutex lock을 hThread[0]이 갖고 있기 때문에
  queue로 내려가더라도 ReleaseMutex(hMutex); 를
  만나지 않는 한
  Pthread[1]은 lock을 획득하지 못하기 때문에
  pThread[1]이 실행되지 않는다.
  따라서 출력은 정상적으로 된다.

Thread 0 : g_var = 0
Thread 1 : g_var = 1
Thread 0 : g_var = 0
...

---

Classical Problems of Sysnchronization

Bounded-Buffer Problem

Readers and Writers Problem

• 어딘가에 한 computer에 있는 메모장을 여러 사람이 동시에 편집한다고 가정.
• 뭐가 문제가 될까? read 함수가 문제? write 함수가 문제?
  ➡️ read하는 것이 문제이다.
  • write하는 것은 simple하게 write하면 된다.
    단, write할 수 있는 조건을 복잡하게 만들어주고 그것을 read하는 쪽에 집어넣는다.

Writer Process

• rw_mutex : Writers를 위한 semaphore.
  쓸 수 있는 상태까지 wait()했다가
  쓸 수 있게 되면 writing...
  writing이 완료되면 signal()로 lock 풀어줌
  ➡️ Simple하다
  

Reader Process

• read_count : 현재 몇 개의 process들이 reading하고 있는지 알려준다
• mutex : read_count를 update할 때 mutual exclusion을 위해 사용되는 semaphore
  
  • 처음에 read_count++
  • 만약 read_count가 1이면? == 첫 번째 reader process인가? check
    ➡️ reading하려는 process가 존재하는 것이기 때문에
    현재 writing process가 있는지 확인 : wait(rw_mutex)
  • read_count가 2 이상인 process들은 첫번째 process가 wait중이면 mutex가 0이기 때문에 read_count++를 못하게 된다.
    첫번째 process의 write가 풀려서(=signal(rw_mutex)) reading 중이라면
    read_count가 2 이상인 process들은 기다리지 않고 그냥 지나감.
  • 모든 reader process들이 reading을 마치고 read_count--을 하고 나서
    read_count=0이 되어 signal(rw_mutex)를 통해 writer에게 lock을 풀어줬다면?
    그때부터는 writer process의 차례.

Dining-Philosophers Problem

• 원탁에 5개의 자리가 있다.
• 밥은 젓가락만 사용하여 먹는다. (단, 젓가락은 하나씩만 있다)
• 밥을 먹기 위해 젓가락 두 개(한 쌍)를 사용해야 한다.
• 배가 고파서 밥을 먹기 위해 왼쪽 젓가락을 들고 있어야 한다.
• 밥을 먹을 때까지 왼쪽 젓가락을 내려놓지 못한다.
  • 옆사람이 다 먹기를 기다렸다가 젓가락(나에게는 오른쪽, 옆사람에게는 왼쪽)을 내려놓으면,
    그것을 사용하여 내가 먹을 수 있다.
    ➡️ delay가 생기지만 먹을 수는 있다.
    
  • 하지만 결정적인 문제가 딱 한 순간에 생긴다
    ➡️ 동시에 배고플 때.
    ➡️ 동시에 배가 고프면, 5명이 동시에 자신의 왼쪽 젓가락을 들고 오른쪽 젓가락이 내려지기를 기다린다.
    ➡️ 하지만 아무도 밥을 먹지 않고 기다리기 때문에 젓가락이 내려지기만 하염없이 기다린다.
    ➡️ 아무도 밥을 못 먹는다.
    ➡️ Deadlock 상황이 된다.

program을 만들 때 내 program 자체는 아무 문제가 없는데
이 program들을 여러 개 묶어놨을 때,
어떠한 process에서 문제가 생기는 것이 아니라
여러 개를 운용하는 데에 문제가 생길 수도 있다.

ex) team project을 할 때, 서로가 문제 없이 자신의 task를 하고
나중에 합칠 때 문제가 발생하면 서로의 핑계...
➡️ 이유는 개인에 있는게 아니라 전체를 운용하는 데에 있을 수 있다.