this->OS.code(7)

<Deadlock>

이때, Get B의 경우 process Q에 들어 있어 사용할 수 없다.

B 자원이 사용가능해질 때까지 process P를 block (=sleep, wait)상태로 만든다.

이는 Get A에서도 마찬가지다.

 

=> 따라서 P,Q의 block상태의 지속으로 resource를 계속 갖는 상태로 실행이 안되어 중단되는, deadlock 상태가 발생한다.

 

 

<Deadlock의 발생예시> - 3,4의 경우 deadlock이 발생하게 된다.

 

 

 

<computing 자원의 분류>

재사용 가능 자원: hardware들이 해당된다.(cpu, semaphores, memory...)

소비성 자원: 한 process가 사용하면 사라지는 자원들이다.

 

 

 

<Reusable Resources의 Deadlock 예시>

200Kbyte memory에 할당되어있을 때, 다음 상황을 보면

=> 150Kbyte memory가 다른 process에서 사용될 수 없는, deadlock 상태가 되어버린 것이다

 

 

<Consumable Resources 예시>

=> 대기상태의 지속으로 인해 resouce를 서로 사용하지 못하는

deadlock 상태가 되어버린 것이다

 

 

<Resource Allocation Graph>

 

 

 

 

<Deadlock발생 4조건> - 동시에 모두 만족해야함

Mutual exclusion: 한 자원에 대한 독점적 사용

Hold and wait: 어떤 자원을 가진 상태에서 다른 자원을 요청하는 것

No preemption: 이미 차지하고 있는 자원을 타 process가 강제로 빼앗아 오는 것

Circular wait: Hold-and-wait이 모든 process에 적용되는 것.

 

 

 

 

 

<Deadlock Handling>

Deadlock이 발생하기 전 OS가 사전에 예방

Deadlock이 발생해도 OS가 recover 시켜주는 방법

OS가 아무것도 하지 않음(관리자가 해결)

 

 

<Deadlock Prevention_4조건 break>

Mutual exclusion을 break: 자원을 다른 process가 동시에 써야함 (불가능)

Hold and wait을 break: 자원을 기다리지 않고 처음부터 모든 자원을 받아 처리 (가능, but 현실적으로는 안좋음)

Preemption 수행: 상대 process의 자원을 강탈하면 혼란스러움. (가능, but 효율성↓)

Circular wait break: 가능! 위 3경우보다 좋음. 하지만 불편하다는 단점

 

 

<Deadlock이 발생한 후의 전략>

모든 deadlock process들을 종료(abort)

deadlock process들 중 하나만 골라서 종료(abort)

 

 

<Dining Philosophers Problem>