실제로는 피터슨이나 하드웨어단의 동기화 관리를 직접할 수 없다.
Higher-level software tools to solve the CSP
1.Mutex Locks(2개의 프로세스간 동기화 가능)
mutex = mutual exclustion
protect critical section & prevent race condition
( 1개의 열쇠를 주고 받음 )
아래와 같은 과정을 거친다.
-
acquire lock
-
release lock
여기서는 available을 이용하는데 true이 lock을 쓸 수 있고, false면 대기
aquire나 release도 atomically하게 진행이 되어야 한다.
(non-actomic하면 context switch가 발생한다.)
Busy waiting
어떤 프로세스가 critical point에 들어가기 위해서 무한 loop를 실행
무한 loop를 돈다고 cpu cycle이 낭비된다.
Spinlock
busy waiting을 하면서 mutex lock을 무한히 기다리는 것을 의미
CPU 코어가 여러개인 경우에는 바로 진입이 가능해서 마냥 나쁜 것은 아니다.
(context switch 비용을 줄일 수 있다.)
if) spinlock을 안한다면,
wait queue -> ready queue -> run
피터슨은 mutex, avoid deadlock, avoid bounded waiting인데, 여기서는 mutex만 해결
2.Semaphore(N개의 프로세스간 동기화 가능)
교차로 신호등과 같은 역할
S는 상수
semaphore는 P() = test, V() = increment가 있음.
S를 가지고 wait(), signal()을 구현할 수 있다.
(lock 반납 없다.)
Ex)
S가 3이라고 가정을 한다.
프린트가 가동중이면 1씩 감소가 하고 0이하면 대기를 한다. 그리고 종료되면 +1을 한다.
동시에 3개가 접근한 경우 1씩 감소해서 0이 되고, 그 이후 접근한 것들은 대기를 한다.
Binary and Counting Semaphore
-
Binary Semaphore
S가 1인 경우 mutext lock과 동일하게 작동한다. -
Counting Semaphore( N이 1이상 )
synchronization problem
S1이 반드시 먼저 실행이 되어야만 S2를 처리할 수 있다.
S1은 signal, S2는 wait
그런데 busy waiting 발생. 그래서 아래와 같이 해결.
만약 process가 wait()를 실행중이면 무한대기 하지말고, waiting queue로 들어가라.
그러다가 signal()이 발생하면 waiting 스레드를 ready 큐로 보냄(wake up)
커널레벨에서 구현됨.
그런데 여러개의 스레드가 CSP에 동시에 접근하려고 해서, mutex를 해결하지 못함.
(race condition 발생)
그래서 binary 세마포어면 해결 가능하다.
그렇게 되면 waiting queue에 대기를 한다.
3.Monitor(mutex와 semaphore 극복) -> java에서 주로 사용
- Liveness
