- 프로세스 서로가 자원을 가지고 있는 상태에서 release 하지 않아 어떠한 프로세스도 끝나지 않는 상태
- Deadlock 이 발생할 가능성이 있는 코드라고 해서 언제나 Deadlock 이 발생하는 것은 아님.
-> Deadlock 이 발생할 가능성이 있는 코드의 부작용으로 Deadlock 이 발생될 수 있음.
-> 하지만 code 를 잘 구현했다라고 말 할 수 없음.
-> program 각각이 잘못된 프로그램이라는 것은 아님.
- resource 의 type
- Reusable resource : 사용 후 반환하면 다시 사용 가능
- Consumable resource : 사용 후 없어짐.
-> 이러한 type 의 자원에서도 Deadlock 발생 가능
- Mutual exclusion
- Hold - and - wait
-> 일부 자원을 가진 상태에서 다른 자원을 요청- No preemption
-> 다른 프로세스가 사용하고 있는 자원을 뺏어오지 못함.- Circular wait
-> hold - and - wait 성질이 모든 프로세스에 대해 성립 시 circular wait 도 성립.=> 이 4가지 조건이 모두 만족된다 -> Deadlock 이 발생함.
- 아예 처음부터 deadlock 이 발생되지 않도록 OS 가 사전에 예방
- Deadlock 발생 시 Deadlock 을 풀어줌.
- Deadlock 이 발생하든 안하든 OS 는 신경 안씀. 사람이 알아서 처리
-> 이러한 방법이 제일 많이 쓰임.
- deadlock 사전에 예방하는 방법 => OS 가 예방하고 싶지만 마땅한 방법 없음.
- Deadlock 발생 조건 중 1가지를 만족시키지 않도록 하는 방법
- Mutual Exclusive 를 깨기
-> 이 방법은 불가능.
-> 하나의 자원을 같이 쓸 수 없음- 처음 실행할 때부터 필요한 모든 자원 할당.
-> 하지만 이러한 방법은 아주 잠깐 사용하는 자원도 할당받게 되어 낭비가 심함.- 다른 프로세스가 사용하고있는 자원을 뺏어 사용하도록 함.
-> 너무 혼란스러움. ( 약육강식 )- circular wait 를 깨기 ( 이게 그나마 좋은 방식 )
-> 하지만 편리하지 않음.- 사전예방하는 algorithm 이 존재 ( 참고로 알아두면 좋음. )
- deadlock 발생 시 풀어주는 방법
- deadlock 발생한 그 시점에 실행되고 있는 모든 프로세스 종료
- 어떠한 기준에 따라 프로세스를 하나씩 종료해가며 deadlock 해결
[ 프로세스를 종료하기 위한 기준]
- 시작한지 얼마 안된 프로세스
- 생성된 출력 라인이 얼마 없는 프로세스
- 시간이 많이 남은 프로세스
- 할당받은 자원이 얼마 없는 프로세스
- 제일 낮은 우선순위 프로세스
=> 이렇게 5가지 기준 중에서 "뭐가 더 좋은 기준이다." 라는건 없음.
-> 관리자 ( 사람 ) 가 알아서 판단 후 처리