Mutex와 semaphores가 현실적으로 적용하기 힘들다.
-
실행 sequence가 꼬이면, error가 발생한다.
-
반드시 wait(acquire) -> signal(release)을 지켜야한다.
반드시 wait -> signal의 순서를 지켜야 한다.
low level아니면 semaphore를 거의 쓸 일이 없다.
그래서 high level에선 monitor를 사용한다.
monitor type
mutual exclusion을 모니터에서 제공한다.(일종의 java class)
variable을 선언하고 그 vaiable의 instance를 호출한다.
이 모니터 자료구조를 사용하는 스레드들은 대기큐로 늘어져있다.
Conditional Variables
x,y가 공유자원
x와 y 각각에 대한 wait queue가 그림처럼 늘어져 있다.
참고 자료
( https://syeon2.medium.com/java-synchronized-deep-dive-9a764568d27c )
Java Monitors
intrinsic-lock( monitor-lock )
자바는 스레드 단위로 작업하므로, 스레드 락
- synchronized
monitor lock을 획득하고 반납을 해야한다.
이걸로 동기화는 못한다.(순서 배정은 못함.)
필요한 부분만 synchronized하는 편이 성능상 뛰어나다.
static이 아니면, this로 대체가능
count는 공유자원이므로 static으로 처리
Counter 인스턴스를 주입한다.
그런데 인스턴스가 개별적이라서 모니터 락이 공유되지 않는다.(모니터가 따로 있다.)
스레드와 스레드간 동기화가 되지 않는다.
문제의 코드는 아래와 같다.
그래서 아래와 같이 수정을 한다.
이렇게 하면 모니터 락 1개를 공유한다.
conditional variable을 선언해준다.(인스턴스)
Liveness
여태껏 Mutex만 해결해줌.
즉, semaphores나 monitor는 deadlock이나 bounded waitng을 해결하지 못함.
DeadLock
두 개 이상의 프로세스가 교착상태에 빠져서 무제한 대기
Priority Inversion
높은 우선순위 프로세스가 낮은 우선순위 프로세스를 기다림.
자바의 Synchronized vs Volatile 차이.
- Synchronized : 가시성 확보 + 원자적 접근
- Volatile : 가시성 확보만. 따라서, 원자적으로(Atomic) 관리할 필요가 있다.
