Deadlock 처리
deadlock을 처리하는 방법으로는 3가지 정도 볼 수 있다.
1. Deadlcok Prevention
2. Deadlcok Avoidance
3. Detection and recovery
그중에 Detection and recovery에 대해 알아보자
Deadlock Detection
간단하다 Deadlock을 허용하고 그다음에 찾으라는 것이다. 찾는 방법은 Deadlock Avoidance을 이용하여 찾는데 이때 문제는 얼마나 자주 찾을 것인가?이다.
어떤 요청이 있을 때마다 찾자니 높은 overhead가 생길 것이고, 오랜 시간 응답이 오지 않거나 실행되지 않는 프로세스가 있을 때 찾는다면 찾기가 너무 어렵고 Deadlock은 점점 퍼져 나가기 때문에 쉽지 않다. 또한 일정 상태 (Ex, CPU 성능이 40% 이하로 떨어졌을 때)가 되면 찾거나 하는 방법이 있다.
다음으로 문제는 어떻게 처리할 것인가에 대한 문제이다. 이를 해결하기 위해서 여러 방법이 있을 것이다.
먼저 사람이 처리하는 방법인데 너무 비효율적이다.
그 다음으로는 Deadlock에 빠진 프로세스를 중단시키는 방법이다. 하지만 모든 프로세스를 중단시키기엔 너무 많은 cost가 들어간다. 새로 시작하기엔 부담이 있다는 것이다. 그렇다면 프로세스 하나하나씩 중단시켰을 때 Deadlock이 해결되는지 보자, 이때 중요한 건 어떤 프로세스를 선택적으로 죽일 것이냐이다. 가령 우선순위가 있을 수 있고, 최근에 실행되거나 오래전에 실행됐거나, 많은 자원을 가지고 있는 프로세스.. 등등 여러 조건을 가지고 중단시킬 것이다.
다음으로는 자원의 preemption을 허락하는 것이다.
다음은 하드웨어에서의 Deadlock도 생길 수 있다는 걸 공부해 보자.
그전에 Core에도 라우터라는 패킷(데이터)을 주고받고 경로를 지정하는 소자가 있다. 이렇게 core끼리 정보를 주고받을 때 물리적인 선으로 주고받는데 항상 같은 경로로 주고받을지에 대해서 생각해 볼 필요가 있다. 아래 그림을 보자
1번에서 6번으로 정보를 보낼 때 default경로인 1-7-6으로 보낼 땐 1400 정도로 정보를 보낼 수 있는데 다른 node를 쓰면 1966, 2105처럼 훨씬 더 나은 속도로 정보를 보낼 수 있다. 이유는 여러 가지가 있겠지만 이미 1에서 7로 다른 데이터를 보내고 있다면 서로 경쟁하느라 속도가 늦어질 수 있고 그런 와중에 다른 node는 쉬고 있다면 당연히 쉬는 노드에게 나눠주는 것이 더 효율적일 것이다. 이런 상황에서 라우터는 어떻게 배정해야 할지에 고민해야 한다.
그렇다면 Deadlock은 어떻게 생길까?? 라우터에는 데이터를 저장하는 buffer가 존재하는데 당연히 제한이 존재한다. 여기선 buffer를 자원으로 본다. 아래와 같은 상황에서 Deadlock이 발생한다.
A패킷은 3번으로 가는데 이미 B패킷이 차지하고 있고
B패킷은 2번으로 가야 되는데 이미 C패킷이 차지하고 있고
C패킷은 0번으로 가야 되는데 이미 D패킷이 차지하고 있고
D패킷은 1번으로 가야 되는데 이미 A패킷이 차지하고 있는 상황이 생길 수 있는데 이때 Deadlock이 발생한다.
또한 이렇게 생긴 deadlock은 디버깅에 굉장히 어렵다는 문제가 있다.
댓글