11분 36초 cycle 형성시 wait하면 cycle이 해제된다는 것이 이해가 안 갑니다.

Question

T1이 R2에 요청을 했을때 cycle이 형성되어 wait 시킨다고 하더라도 T2가 R2를 반환하기 위해서는 T2가 R1에 요청한 자원이 T2로 가야합니다. 하지만 R1은 현재 T1에 있는 상태이고 T1은 R2에 대한 요청이 거절되었으므로 waiting 상태이고, 결론적으로는 dead lock 상태에 빠집니다. T1이 R1을 T2에게 주기 위해서는 T1도 작업을 완료해야 하기 때문입니다. 그래서 공유 자원 타입마다 1개가 존재할 때, cycle이 생성되는 요청을 허가하지 않더라도, 시간이 지나더라도 dead lock 상태가 해결되지 않습니다. 해당 요청을 허가했을 때 unsafe 상태에 빠지는 것이 아니라,  cycle을 detect하는 순간 이미 deadlock 상태에 있는 것 같은데요. 제가 어디를 잘못 이해했는지 모르겠습니다.

fostudy0838 · Answer

감사합니다!

joonion · Answer

질문을 보고 영상을 다시 보니까, 오해할 수 있도록 설명을 애매하게 했네요. ㅠㅠ. 질문한 내용에서는 T1 ---> R2 를 승인한다고 했는데, 그러면 T1이 R1과 R2를 모두 가졌으므로, 해당하는 업무를 처리하고 R1, R2 를 반환할 것이므로 데드락이 발생하지 않을 것입니다. (사이클도 발생하지 않으므로) 하지만, Figure 8.10에서처럼 T2 ---> R2를 승인하면, 질문하신대로 데드락이 발생하게 되겠지요? 리소스 인스턴스가 하나일 경우의 RAG에서는 데드락 회피를 이 경우에 cycle detection을 통해 회피를 할 수 있다는 것입니다.

joonion · Answer

질문 자체를 이해할 수가 없네요. ㅠㅠ. 질문하신 예시에서 실선은 이미 할당된 리소스이고, 점선은 리소스를 요청하는 것이므로, 요청한 자원을 못 받으면 점유한 자원을 가진 상태로 계속 wait를 하므로, 데드락에 빠진다는 것입니다.

fostudy0838 · Answer

only one instance of each resource type 상황에서  그림 8.10은 T1 - - -> R2 claim edge을 RAG에 넣어본 상태입니다. T1 - - -> R2 요청을 승인할 시 cycle이 형성됩니다. 그래서 승인하지 않고 dead lock을 피한다는게 강의에서 나온 내용입니다. 저는 위 상황에서 dead lock을 어떻게 피할 수 있는 것인지 잘 모르겠습니다. 왜냐하면 T1--->R2 를 승인하지 않고 T1을 wait 상태로 만들어도 T1은 R1을 가지고 있는 상태입니다. 강의내용에서는 wait하면 T2가 작업을 끝내고 R2를 다시 내놓는 것으로 나오는데, T2가 작업을 끝내기 위해서는 R1이 필요합니다.  결론적으로는 Dead lock avoidance를 위해서 요청의 승인 여부를 묻는 시점에, 이미 그림 8.10은 dead lock 상태가 될 수 밖에 없는 unsafe 상태로 보인다는 것이죠. 질문을 요약하면 강의내용은 저렇게 wait하는 방식으로 dead lock을 피할 수 있다고 나오는데 제가 보기에는 wait를 하든 안 하든 dead lock인 상황처럼 보여서요. 제가 놓친 부분이 어디인지 알고 싶습니다.