Process 동기화(semaphore vs mutex vs monitor)

* CPU 개수가 많아진다고 무조건 성능이 좋아지는 것은 아닌 이유 : process synchronization 때문

* 스마트폰 락업 문제(갑자기 화면 정지) : synchronization(동기화) 때문에 deadlock이 발생해서 아무 반응도 할 수 없는 상태에 도달하는 것 

---

 

Process Synchronization 문제의 해결책

1. Semaphore 

: synchronizataion을 제공해 주는 정수형 변수

- mutual exclusion mechanism의 예시. mutual exclusion보다 더 많은 일을 함.(mutual exclusion(lock, unlock 관점) + scheduling(wait, signal 관점) 기능.) Dijkstra가 고안

- binary semaphore : 있다/없다 vs counting semaphore : 여러개의 있다 표현 가능

- count 의미) 0 이상인 경우: 남아있는 열쇠(자원)의 개수, 0 이하인 경우 : 절댓값이 Queue에서 대기 중인 process의 개수 

- lock을 걸지 않은 thread도 signal을 사용해 lock 해제 가능

- 자원 소유 불가

 

ex)  수위 아저씨와 열쇠(semaphore)관련해서 소통하는 것. 

(1) 열쇠 줘 = lock(S : semaphore 변수) = wait(S) = P(S). 

- 안으로 들어가서 잠그니까 lock, 열쇠 없으면 기다리니까 wait

- an atomic operation that waits for semaphore to become positive and then decrements semaphore by one

(resource consume. 열쇠 없애버림.)

 

(2) 열쇠 받아(반납) = unlock(S) = signal(S) = V(S)

- 열쇠 돌려주고 waiting queue에 있는 애들 깨워야 하니까 signal.

- an atomic operation that increments semaphore by one

(resource 생성. 열쇠 다시 생성)

 

 

- 단점 : unstructured programming construct이기 때문에 컴파일러 등의 도구를 사용한 디버깅이 어려움.

- semaphore 구현 위해 hardware적인 primitive 필요)

single processor => interrupt enable/disable

multiprocessor => TAS같은 atomic operation(global variable을 읽고 modify 하고 다시 write back을 하는 것을 쪼갤 수 없는 기본 단위로 만드는 것.)로 구현 가능.

(TAS => busy waiting / spin lock(특정 조건의 만족 여부를 loop를 돌면서 반복해서 확인하는 방법. ) 이 문제. )

 

---

 

2. Mutex

- mutual exclusion을 구현하기 위해 사용하는 sleeping lock

- 동일한 mutex를 사용할 때 mutex_lock()을 호출한 process와 mutex_unlock()을 호출한 process가 일치하여야 함. 

(critical section을 구현하기 위해 사용된 거니까)

- 동기화 대상이 only 1개여서 0,1로 이루어진 이진 상태

- lock을 건 thread만이 critical section을 나갈 때 lock 해제 가능

- 자원 소유 가능 + 책임을 가짐

- process 간에 사용

 

---

 

3. Monitor

- concurrent programming에서 mutual exclusion을 보장 + 조건에 따라 대기(wait) 상태로 전환 기능

- single process 내에서 사용

 

monitor의 구성요소

1. mutex lock

: critical section에서 mutual exclusion을 보장하는 장치

- mutex lock을 취득해야 critical section에 진입.

- mutex lock을 취득하지 못한 thread는 queue에 들어간 후 대기 상태로 전환

 

2. condition variable (monitor에만 있는 특성.)

- waiting queue를 가짐.

- 조건이 충족되길 기다리는 thread들이 대기 상태로 머무르는 곳

 

3. condition variable의 주요 operation

- wait : thread가 자기 자신을 대기열에 넣고 대기 상태로 전환

- signal : 대기열에서 대기중인 thread를 하나 깨움

- broadcast : 대기열에서 대기중인 thread를 모두 깨움

 

---

 

 

Reentrant Code(재진입 가능 코드)

: 여러 process들에 의해 동시에 호출되거나, 이전 호출이 완료되기 전에 반복 호출 되어도 올바르게 수행되는 코드

 

=> reentrant code를 위해서 non-interruptible operation(atomic 한 operation을 위해서 hardware적인 support 필요.)

 

---

 

Critical Section(임계 구역)   (<= mutual exclusion)

- code segment that can be accessed by only one process at a time.

 

 

---

 

 

Further Topics

• bus slave, bus master
• critical section 문제 해결책 3가지(mutual exclusion, progress, bounded waiting)

 

 

References

• snuon OS 강의
• https://velog.io/@doxxx93/%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4-%EB%8F%99%EA%B8%B0%ED%99%94%EC%99%80-%EB%AA%A8%EB%8B%88%ED%84%B0