[운영체제] Ch6(2)
HW적 솔루션은 이용이 어렵고 실수했을 시 문제가 일어나기 때문에 접근하기 쉬운 API를 사용해보자.
- API는 OS마다 함수 이름은 틀림
Mutex Locks
- 들어갈때는 acquire(), 나올때는 release()
- acquire()를 할려고 하는데 CS를 누가 사용하고 있으면 busy waiting을 한다.
--busy waiting: acquire()를 해도 되는지 계속 확인한다.(ready 상태 반복)[spinlock]
HW에서 제공사는 test-and-set과 compare-and-swap을 이용해서 acquire()와 release()를 구현하면 된다.
Semaphores
Mutex보다 상위개념
한 프로세스가 다른 프로세스에게 이벤트가 일어났다는 것을 알릴 때 사용할 수도 있다.
Semaphore S: integer variable
변수 S를 10으로 설정해 높으면 CS자원 10개가 있다는 뜻
wait( ): 자원 하나를 사용하겠다., signal( ):자원 사용을 끝마쳤다(반납).
- Counting semaphore: Semaphore variable을 가지고 자원의 갯수를 표현할 수 있다.
- Binary semaphore: Mutex와 비슷한 기능
Semaphore의 기능:
1. CS를 보호할 수 있다.
2. 동기화 메커니즘에서 어떠한 신호를 줄 때 사용할 수 있다.
Semaphore implementation:
wait()할 때 busy waiting으로 할 수도 있고 sleep-and-wait를 할 수 있다.(sleep-and-wait:그냥 시그널 줄 때까지 기다리는 것.)
조금만 기다려도 될 때: busy waiting
많이 기다려야 할 때: no Busy waiting
Semaphore implementation with no Busy waiting:
data items
- semaphore variable
- queue list(자원에 접근하지 못할 때 기다리는 큐)
operations
- Block: CS가 없어서 들어가서 기다리는 곳
- Wakeup: CS에 접근 가능해서 Block상태에 들어간 걸 깨워준다.
Semaphores의 문제점
- wait()후에 signal() 을 써야하는데 순서를 바꾸었을 때
- wait()후에 다시 wait()를 써야 한다.
-->여전히 프로그래머가 사용하기 어렵기 때문에 더 쉬운 걸 개발함 : Moniter
Monitors
CS이 필요한 function들을 모두 monitor안에 넣으면 컴파일러가 알아서 CS를 보호하면서 실행시킨다.
Monitor 사용은 한번에 한 프로세스만!!
모니터에 있는 함수를 사용할 때, wait나 signal을 통해 구현하면 CS를 보호하는데 쉽다.
condition x, y:
:producer는 생산을 해야하는데 consumer가 하나도 안 가지고 가서 저장장소가 꽉 차있으면 생산을 할 수가 없다.
:consumer는 가져갈려하는데 producer가 생산해놓은 게 없다.
--> 이렇게 버퍼가 빈 공간이 생기기를 기다려야 하는 조건
x.wait(): x라는 condition을 기다린다.
x.signal(): x라는 condition의 조건이 왔음을 알려준다.
semaphore의 wait()시그널과 condition의 wait()시그널은 다르다.
1. operations: CS, 보호해야하는 코드들
2. initailization code: 초기화 코드
3. entry queue: 모니터에는 한 프로세스 밖에 못 들어오니까 이 모니터를 기다리는 프로세스들의 모임
4. x->: x라는 컨디션이 발생하기를 기다리는 프로세스들의 리스트
[P가 x.signal()로 x.wait()하던 Q를 깨울 때, P와 Q 중 누가 수행이 되어야 하나?]
signal and wait:Q가 수행
signal and continue: P가 수행
Monitor Implementation Using Semaphores p 44
Resuming Processes within a Monitor p47
Single Resource allocation
R.acquire(t): t만큼의 시간만 리소스에 접근하겠다.
R.release: 리소스 접근 종료
Liveness
: 계속해서 프로그램이 수행이 되어야 한다는 것.
--> 계속해서 무한정 기다려야한다는 상황이 된다면 liveness failure이다.
Deadlock: 서로가 서로를 기다리는 것 --> liveness failure
starvation: 우선순위 높은게 계속 도착해서 우선순위 낮은 것이 계속 기다려야 하는 것--> livenes failure
Priority Inversion: --> liveness failure