운영체제를 왜 배워야 할까?
운영체제는 프로그램들이 메모리 또는 cpu에 접근을 할 때 운영체제를 통해서만 접근을 하게 해서 자원(메모리, cpu, ram 등)을 보호한다.
자 생각해 보자. 우리가 힘들게 만든 파일이 약간의 실수로 날아가면 아깝지 않은가... 이를 방지하기 위해서 운영체가 필요한 것이다. 즉 응용프로그램이 자원에 직접 접근해서 자원이 무질서하게 관리되는 것을 방지하기 위해서 운영체제를 사용한다.
운영체제의 구성
운영체제는 2개의 구역으로 구분할 수 있다. 커널 영역과 사용자 영역이다. 커널 영역에는 window와 같은 운영체제의 핵심 내용이 들어가 있다. 사용자 영역에는 응용 프로그램이 작동할 수 있는 공간이 들어가 있다.
그러면 작동하는 프로그램을 뭐라고 할까? 바로 프로세스라고 한다. 즉 크롬과 같은 프로그램이 컴퓨터 내 자원에서 작동하는 것을 프로세스라고 한다. 정확하게 이야기하면 실행 파일이 메모리에 적재될 때, 해당 프로그램이 프로세스로 바뀐다.
이 프로세스는 여러 개의 스레드로 구성되어 있다. 스레드는 작업의 흐름이다. 크롬이 작동할 때 그 안에서 세부적으로 동작하는 여러 가지의 기능들이 스레드이다.
참고로 크롬은 멀티 프로세스 형식으로 구성되어 있기 때문에 하나의 창에서 오류가 발생을 하더라도, 다른 창에서 계속 검색을 할 수 있는 것이다. 하지만 IE를 생각해보면 하나의 창에서 오류가 발생하면, 나머지 창도 멈추게 되어 사용하지 못한다. 왜냐하면 멀티 스레드의 방식으로 동작했기 때문이다. 이것이 멀티 스레드의 단점이다. 하나의 스레드가 고장 나면, 나머지 스레드도 오류가 발생한다.
여기서 잠깐 생각해 보자.크롬은 하나의 페이지에서 오류가 발생했는데도 다른 창에서 쓸 수 있으며, IE는 왜 그렇지 못했을까? 동작 원리를 생각해 보면 된다. 크롬은 멀티 프로세스 방식으로 작동한다고 했다. 멀티 프로세스는 서로 간의 연결이 약하기 때문에 영향력이 크지 않다. 하지만 IE의 작동 방식인 멀티 스레드는 스레드 간의 연결이 강하기 때문에 하나가 작동하지 않으면 다른 쪽도 멈추는 것이다.
근데 우리는 컴퓨터를 사용할 때 하나의 프로그램만 사용하지 않는다. 막 카카오톡도 했다가, 크롬으로 인터넷 검색도 했다가, 문서 작업도 한다. 이 모든 것을 동시에 사용하려고 한다. 그러면 어떤 원리로 이렇게 사용할 수 있을까 궁금하지 않은가...
우리는 시분할 시스템이라는 것을 활용한다. CPU는 동작하는 프로그램을 잘게 나누어서, 이쪽에 왔다가 저쪽에 왔다가 하면서 프로그램을 동작한다. 그러면 짧은 시간에 빠르게 왔다 갔다 함으로써 동시에 작동하는 것처럼 보인다. 이것이 멀티 프로세싱의 기본 동작 원리이다. 이해하기 어려우면 영사기나 만화책을 빨리 넘길 때를 생각해 보면 된다. 만화책을 빠르게 넘기기 때문에 애니메이션처럼 보이지 않은가...
그러면 멀티 프로세싱은 무엇인가? 간단하게 프로세스가 여러 개 있다는 것이다. 여러 개의 프로세스 즉 여러 개여 프로그램이 서로 협력적으로 일을 하는데 그렇기 때문에 자원의 공간을 많이 사용한다. 운영체제에서 자원의 공간을 많이 차지한다는 것은 효율적이지 않다는 것이다.
그래서 이것을 효율적으로 사용하기 위해서 멀티 스레드라는 개념을 알아 두자.
멀티 스레드는 공유되는 자원을 제외하고 나머지 부분만 교환하는 것이다. 다르게 말하면 하나의 프로그램을 여러 부분으로 나누어서 동작시키는 것이다. 그러면 공통된 부분은 공유하고 그렇지 않은 부분만 바꾸면 되기 때문에 자원의 효율성이 높아진다. 스레드가 공유하는 메모리 영역은 stack만 있으며 나머지 영역인 heap, data, code영역은 스레드가 바뀔 때 마다 변경된다. 스레드가 변경되는 것을 문맥교환의 기본 원리라고 생각하면 된다.
하나의 프로세스 안에 여러 개의 스레드가 작동하고 있다고 생각하면 된다.
즉 기업에서 사업을 진행하려고 한다. 예를 들어서 드론 사업이다. 그러면 드론 사업이라고 하는 것이 하나의 프로세스이다. 또한 이것을 하기 위해서 부동산팀, 개발팀, 법무팀 등 다양한 팀이 협력을 해야 하는데 이 각 팀이 하나의 프로세스이다. 이들 위에 상위 조직인 TF팀이 있다고 하면 모두 같은 자원을 공유하기 때문에 소통이 쉽다고 생각하면 멀티 스레드와 멀티 프로세스의 개념을 이해하기 쉬울 것이다.
힙 영역과 스택 영역을 잠깐 정리하고 넘어가면, 힙 영역은 사용자가 직접 관리할 수 있는 영역이며, 메모리공간이 동적으로 할당되고 해제된다. 반면 스택 영역은 함수의 호출과 관련된 지역변수와 매개변수가 저장되는 영역이다. 함수 호출과 함께 할당되고, 함수의 호출이 종료되면 해체된다.
참고로 멀티 스레드의 자원 효율성이 좋기 때문에 우리는 이 형식을 지향한다. 그러면 왜 효율성이 좋을까 생각해보자.
프로세스 간의 문맥교환을 하는데, 이 때 프로세스 간의 문맥교환을 하면 자원들 사이의 오버헤드가 커지는 반면, 스레드는 공유되는 영역이 있기 때문에 스레드 간 데이터를 주고받는 것이 간단해서 자원의 소모가 낮다. 그렇기 때문에 응답 시간도 단축이 된다. 왜냐하면 같은 메모리의 공간을 공유하기 때문이다.
우리가 이사를 가고 오는 것을 생각하면 된다. 이사를 갈 때 짐을 전부 다 빼고, 새로 넣으면 시간소모가 오래 걸리는 반면, 풀옵션으로 모든 것이 제공되는 집에 필요한 짐만 가지고 가면 비용과 시간 모두 절약되는 것을 생각하면 된다.
메모리 효율성을 높이는 이유
아까 맨 처음에 효율성이 좋아야 된다고 했는데, 그러면 어떻게 효율성을 높일 수 있을까 생각을 해보자.
데이터를 미리 가지고 왔다가 프로그램이 필요하다고 할 때 전달해 주면 대기 시간이 줄어들지 않을까 하는 생각을 해보자. 이것이 캐시의 기본 이론이다. 캐시는 CPU 간의 속도 차이를 완화하기 위해서 데이터를 미리 가지고 와서 저장해 두는 장소이다.
데이터를 무작정 가지고 오는데 대충 때려 맞출 수도 없는 것이고, 어떻게 캐시의 적중률을 높일 수 있을까? 우리는 캐시의 적중률을 캐시 히트라고 한다.
캐시의 적중률을 높이는 방법은 간단하다. 일단 많은 데이터를 가지고 오면 그중 하나는 맞지 않을까 해서, 가져오는 데이터의 양을 늘리는 방법이 있다. 그리고 다른 하나는 가까운 곳에 있는 데이터를 쓰지 않을까 해서 사용하는 지역성 이론이 있다.
스케줄링이란.
다시 본론으로 돌아와서 컴퓨터에서 여러 가지의 프로세스를 작동하는데 이것이 동시에 작동하게 보이는 것이 하나의 착시 효과라고 했다. 그러면 어떤 것을 먼저 돌릴지, 늦게 돌릴지 컴퓨터가 결정해야 하지 않을까? 즉 프로그램의 우선순위가 필요하지 않을까 하는 고민을 해보자. 우리는 이것을 CPU 스케줄링이라고 한다.
모든 프로그램이 자신이 먼저 사용되어야 한다고 주장하면 결국에는 싸움만 나게 된다. 이것을 조절해 주는 것이 PCB 프로세스 제어 블록이라고 한다.
스케줄링을 할 때 고려해야 할 점이 많다. 회사에서 사람을 뽑을 때, 필요한 인물 순서대로 뽑는 것을 생각하면 된다. 컴퓨터 역시 많이 사용되면 중요도가 높다고 판단하여 그것을 우선적으로 스케줄링한다고 보면 된다.
우리가 고속도로에서 차가 막혀서 기다리는데 갑자기 끼어드는 차량이 있을 수도 있다. 물론 급똥과 같은 이유라고 생각을 하자. 이렇게 중간에 새치기를 해서 자신이 먼저 동작하는 것을 사이클 훔치기라고 한다. 보다 정확한 개념은 입출력 집중 프로세스가 CPU 집중 프로세스보다 실행상태에 먼저 들어가는 것이라고 보면 된다.
스케줄링에 대해서 좀더 자세히 파고 들어가 보자. 그러면 중요도를 파악하는 알고리즘이 있지 않을까? 단순히 많이 사용된다고 해서 먼저 실행되면 그 뒤에 있는 다른 것들은 실행이 안되어서 종료가 되지 않을까 하는 궁금증을 불러와야 한다.
일단 스케줄링에는 선점형 스케줄링과 비선점형 스케줄링이라는 것이 존재한다. 선점형은 북한처럼 프로세스가 cpu를 할당 받아도 강제로 빼앗을 수 있는 것을 이야기한다. 하지만 비선점형은 민주국가처럼 한번 할당받으면 해당 프로세스가 마무리될 때까지 빼앗을 수 없다. 이것이 스케줄링이 동작하는 2가지의 방법이다.
좀더 깊게 들어가 보자. 스케줄링에는 FCFS, SJF, HRN, RR, SRF 등의등의 방법이 있다. 아마 요즘은 RR의 형식이 효율성이 제일 좋기 때문에 이것을 사용할 것이다.
FCFS방법은 선입 선출의 형태이다. 먼저 들어온 프로세스가 먼저 영역을 할당받는 것이다. 그러면 맨 마지막에 있는 것은 어떻게 될까? 무한정 기다리게 된다. 만약 맨 처음 들어온 프로세스가 엄청 길게 동작하면 맨 마지막에 있는 프로세스는 계속 엄청난 시간 동안 기다려야 한다. 이것을 콘보이 현상이라고 한다.
SJF는 가장 실행시간이 짧은 프로세스부터 동작하는 것이다. 하지만 정확하게 종료 시간을 예측하기 어렵고, 아사현상 즉 작업시간이 길다는 이유로 작업이 계속 연기되는 현상이 발생할 뿐만 아니라 공평성에 어긋난다. 따라서 요즘은 잘 쓰지 않는다.
아 물론 공평성에 어긋나는 문제는 에이징이라는 방법을 통해서 해결할 수 있다. 에이징은 프로세스가 양보할 수 있는 상한선을 정하는 것을 말한다. 프로세스가 자신의 순서를 양보할 때마다 나이를 한살씩 먹어 최대 몇 살까지만 양보할 수 있도록 하는 것을 이야기한다.
HRN방식은 기다린 시간과 CPU 사용 시간을 고려해서 스케줄링을 하는 방식이다. 실행시간이 짧은 프로세스의 우선순위를 높게 설정하면서도 대기시간을 높게 평가하기 때문에 아사현상은 없지만 공평성 문제가 있다.
RR은 라운드 로빈이라고 하며 프로세스가 할당 받은 시간 즉 타임슬라이스 동안 작업을 하다가 완료하지 못하면 준비 큐의 맨 뒤로 가서 자기 차례를 기다리는 방식이다. 프로세스들이 작업을 완료할 때까지 순환하면서 실행된다. 아마 요즘은 RR형식으로 많이 동작하는 것으로 알고 있다.
SRT SJF와 RR을 혼합한 방식으로 최소 잔류 시간 우선 스케줄링이다. cpu 할당 받을 프로세스를 선택할 때 남은 작업 시간이 가장 적은 프로세스를 선택한다. 하지만 이 또한 SJF와 같은 단점을 가지기 때문에 잘 사용하지 않는다.
또한 한번 우선순위를 부여받으면 끝까지 우선순위가 고정되는 고정 우선순위 알고리즘과 물론 효율성이 떨어진다. 일정 시간마다 변하는 우선순위를 새로 계산하고 이를 반영하는 변동 우선순위로 나뉜다. 하지만 변동 우선순위는 복잡성이 높다.
이 모든 것을 커버하는 것이 다단계 큐 스케줄링이다. 우선순위에 따라 준비 큐를 여러 개 상용하며 우선순위에 따라 타임 슬라이스를 조절하여 작업 효율을 높일 수 있다. 하지만 우선순위가 낮은 프로세스는 불리하다.
이를 보완한 것이 다단계 피드백 큐 스케줄링이다. CPU를 사용한 후의 프로세스는 원래의 큐로 돌아가지 않고 우선순위가 하나 낮은 큐 끝으로 들어가 순위가 낮은 프로세스의 실행이 연기되는 문제를 해결한다. 또한 우선순위가 낮아질수록 해당 큐의 타임 슬라이스가 커진다.
스케줄링을 통해서 작동 순서가 정해진 프로세스들이 동시다발적으로 협력을 하면서 작동을 하는데, 이들의 순서를 올바르게 맞추기 위해서 동기화라는 기능이 필요하다. 즉 프로세스들 사이의 순서를 맞추는 것이다.
생산자가 물건을 팔고 판매 수량을 계산해야 하는데, 물건 값은 받지 않고 물건을 주어서 판매 수량을 계산하면 결국 순서가 어긋나서 별로 좋지 않게 된다. 따라서 동기화를 사용해서 올바른 결과를 내야 한다.
따라서 우리는 순서를 위한 동기화와 상호 배제 즉 공유가 불가능한 자원을 동시에 사용하는 것을 막기 위한 동기화 방식이 있다.
여기서 더 들어가 보자. 공유 자원이라고 해서 공유가 가능한 자원이 있는데, 이 들 중에서 동시에 접근하면 오류가 발생하는 임계 구역이라는 것이 존재한다. 임계구역은 하나의 프로세스가 작동 중이면 다른 하나는 대기 줄을 서야 한다.
임계구역은 오직 하나의 프로세스만 진입해야 한다. 그렇다면 우리는 어떻게 올바른 순서를 지켜서 프로그램을 작동시킬 수 있을까? 몇몇의 방식이 있는데 일단 뮤텍스 락부터 알아부자. 인터넷에 뮤텍스, 락 다양한 언어로 조사를 할 수 있는데 결국 다 같은 것을 말하고 있다.
락은 하나의 프로세스가 임계 구역에 들어가면 해당 구역을 잠가서 다른 프로세스가 들어가지 못하게 하는 것이다. 화장실을 생각하면 된다. 한 명이 들어가면 잠겨서 다른 사람이 못 들어 가는 것에 비유하면 된다. 물론 프로세스가 임계구역에 대한 사용이 끝나면 다른 프로세스는 기다렸다가 들어가면 된다.
또 다른 방식은 세마포어 라는 것이 있다. 락은 하나의 공유 자원에 접근하는 방식이지만 세마포어는 여러 개의 공유자원에 접근하는 방식이다. 락은 화장실 칸 하나를 사용했지만, 세마포어는 화장실이 세 칸 있어서 여러 명이 한 번에 처리 가능하다고 생각하면 된다.
다음으로는 모니터 라는 것이 있다. 공유 자원에 접근하고자 하는 프로세스를 큐에 집어넣고 삽입된 순서대로 공유자원을 이용하게 하는 것이다. 이 과정에서 프로세스는 모니터를 통해서 공유자원에 접근하고자 한다. 따라서 모니터는 공유자원을 다루는 인터페이스에 접근하기 위한 큐를 만들고 모니터 안 항상 하나의 프로세스만 들어오도록 한다. 사실 모니터는 잘 이해하지 못했다.
교착상태
위에서 프로세스가 서로 같은 메모리 공간을 차지하려고 하면 문제가 발생한다고 했다. 즉 수요는 많은데 공급이 없으면 문제가 발생한다. 이것을 교착상태라고 한다. 두 개 이상의 프로세스가 각자 가지고 있는 자원을 무작정 기다리면 그 어떤 프로세스도 진행을 할 수 없다. 이것이 교착상태의 정의이다.
중국집 책상을 생각해보자. 원으로 구성되어 있는데, 여기서 각자 앉아있고 그들 앞에 포크 1개씩 있다고 가정해 보자.총 5명의 사람이 있고 포크도 5개이다. 하지만 음식이 나오면 꼭 2개의 포크로 먹어야 한다. 랍스터 같은 건가 보다. 부럽다. 암튼 그렇게 되면 서로 양쪽에 있는 포크를 사용하려 하기 때문에 그 누구도 먹을 수가 없다. 이런상황을 교착상태라고 한다. 이도저도 못하는 상황이다.
이 같은 상황을 쉽게 파악할 수 있게 그림으로 표현한 것이 자원할당 그래프이다. 음 어떤 프로세스가 어떤 자원을 사용 중이고 어떤 자원을 기다리고 있는지를 방향성이 있는 그래프로 표현한 것이다.
방금과 같이 교착상태는 4가지의 조건이 모두 만족하는 상황에만 발생을 한다. 그 조건은 바로 상호배제, 점유 와 대기, 비선점, 원형 대기라는 상황이다.
일단 언어가 어려울 텐데 먼저 설명하겠다. 상호배제는 사용하고 있는 자원을 다른 프로세스가 공유하지 못하는 것이다. 참 이기적이다. 같이 하면 좋은데 말이야.
다음으로 비선점이라는 것이 있다. 이것은 프로세스가 사용하고 있는 자원을 다른 프로세스가 빼앗지 못하는 것이다. 이거 어디서 본 것 같다는 생각이 들 것이다. 바로 비선형 스케줄링의 이론과 비슷하다. 임계 구역을 보호하기 위해 잠금장치를 사용하면 상보 배제와 비선점 조건이 보장도기 때문에 교착 상태가 발생할 수 있다.
점유와 대기라는 것도 있다. 말 그대로 어떤 자원을 할당받은 상태에서 다른 자원을 기다리는 상태여야 한다. 만약에 프로세스가 자원을 점유한 상태에서 다른 프로세스의 자원을 기다리면 서로 진행을 방해하기 때문에 교착상태가 발생한다. 말 그대로 점유 즉 가지고 있으면 기다려라 이 말이다.
마지막으로 원형대기는 대기하는 프로세스 간의 관계가 원을 이루어야 한다는 것이다. 왜냐하면 서로 방해하는 방향이 원을 이루면 프로세스들이 서로 양보를 하지 않아서 교착상태에 빠지기 때문이다.
요약을 해보면 그냥 프로세스들이 지들만 자원을 먹고 내가 먼저야 하면서 빨리 가려고 하기 때문에 교착상태가 발생한다. 고속도로를 생각하면 된다. 지들이 먼저 가려고 끼어들기하고 차선 바꾸고 하는 모습을 생각하면 된다.
물론 교착상태는 컴퓨터를 작동시키는데 효율성이 매우 좋지 않다. 따라서 이를 예방하는 방법도 있다.
예방하고 회피하며 검출/회복하는 것이 있다.
예방한다는 것에는 3가지가 있다. 위에서 말한 4가지의 조건을 예방하는 것이다.
일단 상호 배제를 예방한다. 만약 모든 자원을 공유할 수 있다면 교착상태가 발생하지 않을 것이라는 생각이다. 하지만 절대로 그런 상황은 발생하지 않는다.
다음으로는 비선점 예방이다. 비선점의 반대로 모든 자원을 빼앗을 수 있게 만드는 것이다. 임계구역을 보호하기 위해서 락을 사용하면 되지만 그렇게 되면 상호 배제 예방도 보장할 수 없기 때문에 현실적으로 힘들다.
마지막으로 점유와 대기 예방이라는 것이 있다. 전부 할당하거나 아예 할당하지 않는 방법을 사용한다. 뭐 다 먹거나 아무도 못 먹거나 이런 거다.프로세스가 자원을 점유한 상태에서 다른 자원을 기다리지 못하게 하는 방식이다. 프로세스는 작업 초기에 자신이 사용하는 모든 자원을 한 번에 점유하거나 그렇지 못하면 전부 반환하는 형식이다. 마치 도박 같다.다 따거나 다 잃거나. 이 방식은 자원사용방식을 바꾸어서 교착상태를 처리한다는 점에서 의미가 있다.
하지만 의미가 있는 대신 단점도 있다. 무려 4가지나 있다.
일단 프로세스가 자신이 사용하는 모든 자원을 알기 힘들다는 것이다. 맞다 우리도 우리가 밥을 얼마나 먹을 수 있는지 모르지 않는가
다음으로 자원의 활용성이 떨어진다. 미래에 사용할 자원까지 선정해 버리기 때문에 당장 사용하지 않을 것도 차지하기 때문에 효율성이 떨어진다. 말 그대로 생각해 보면 된다.우리가 입지도 않을 옷을 사서 옷장에 넣어 놓는 것과 같다. 멍청한 것
또 많은 자원을 사용하는 프로세스는 적은 자원을 사용하는 프로세스보다 불리하다. 왜냐 자원을 많이 사용하면 동시에 자원을 확보하기 어렵기 때문이다.
마지막으로 결국 일괄 처리 작업으로 동작한다는 것이다. 모든 작업이 한 번에 처리된다고 생각해 보자.힘들지 않을까? 우리고 공부를 하다가 과제를 하다가 마감일에 몰아서 하면 피곤한 거랑 같다고 보면 된다.
점유와 대기에서 연결 지어서 생각해 볼 수 있는 것이 있다. 바로 원형 대기 예방이라는 것이다. 점유와 대기를 하는 프로세스들이 원형을 이루지 못하게 막는 방법이다. 자원을 한 방향으로만 사용 가능하게 해서 원형 대기를 예방하는 것이다. 모든 자원에 숫자를 부여하고 숫자가 큰 방향으로 자원을 할당하는 방식이다.
물론 단점도 많이 존재한다. 그걸 지금부터 차츰 알아가 보도록 하겠다.
먼저 프로세스 작업 진행에 유연성이 떨어진다. 또한 자원에 번호를 어떠한 형식으로 부여할 지도 문제가 된다.
왜냐하면 제약이 따르기 때문이다. 큰 힘에는 큰 책임이 따른 다는 것을 생각하자. 순서 번호를 매기는 것은 자원 입장에서 큰 힘이다.
상호 배제 예방과 비선점 예방은 사용하기 어렵고, 점유와 대기 예방, 원형 대기 예방은 프로세스 작업방식을 제한하고 자원을 낭비하기 때문에 사용하기 쉽지 않다. 그냥 사용하지 말자.
그렇게 해서 등장한 개념이 회피이다. 물론 도망 다니는 것 좋다. 똥이 더러우면 피하지 않는가?
회피는 자원할당량을 조절해서 교착 상태를 해결하는 방식이다. 그냥 보다가 교착상태 가능성이 있으면 자원 할당을 중단한다고 보면 된다. 댐을 생각하자. 물을 모으다가 넘치면 배출하는 것을 생각하면 된다.
좀 더 자세하게 알아보면 교착상태가 발생하지 않는 범위 내에서만 자원을 할당하고, 교착 상태가 발생하는 범위에 있으면 프로세스를 대기시키는 것이다. 물론 자원의 수를 기준으로 시스템을 안정상태, 불안정 상태로 나누고 자원을 할당한다.
자원이 적으면 안정상태이고, 할당된 자원이 크면 불안정 상태이다.
우리가 은행에서 대출한 것을 생각하면 된다. 대출 금액이 크면 불안하고, 대출 금액이 적으면 심리적으로 편한 것에 비유하자.
하지만 여기에도 문제점이 존재한다. 바로 사용할 모든 자원을 미리 선언해야 한다는 점이다.
미리 선언해도 문제가 발생할 수 있다. 그 선언한 자원의 수가 정확하지 않으면 교착 상태가 나올 수 있다. 우리가 음식점 사장이라고 가정해 보자.예약을 100명 받았는데 150명이 오거나 40명이 오면 당황스러운 것과 마찬가지다.
또 회피에서 시스템 전체 자원의 수가 고정적이어야 한다. 하지만 자원의 수는 늘 유동적이기 때문에 힘들다.
자원이 낭비되는 경우도 있다. 위에서 음식점 사장 예제를 다시 생각하자. 100명을 예약받고 상차림을 해놨는데 40명이 오면 나머지 60인분은 낭비되면서 다른 손님을 받지 못하는 것과 같다.
그럼 회피 말고 어떤 방법이 있을까? 바로 검출과 회복을 사용하는 방법이 있다.
이것은 한참 앞에서 말한 지원할당 그래프를 모니터링하면서 교착상태가 발생하는지 알아보는 것이다. 여기서 교착 상태가 발생하면 위에서 언급한 회피를 사용한다.
여기서 사용하는 방식은 타임 아웃을 이용한 방식이다. 음 타임아웃을 이용한 방식을 이용한 교착상태 검출은 일정 시간 동안 작업이 진행되지 않은 프로세스를 교착상태가 발생한 것으로 판단하고 처리하는 방법이다.
쉽게 생각하면 그냥 일정 시간 일을 하지 않으면 해고됐나?라고 생각하는 것과 같다.
참고로 타임아웃을 기용한 방법을 가벼운 교착상태 검출, 자원그래프를 이용한 방식을 무거운 교착상태 검출이라고 한다.
이 방법에도 문제점은 있다. 왜 이렇게 모든 방법마다 문제점이 있는지 모르겠다.
일단 엉뚱한 프로세스가 종료될 수 있다. 왜냐고? 대기 시간이 긴 것을 생각해 보면 간단하다.
다음으로 모든 시스템에 적용할 수 없다는 것이다. 시스템의 응답이 없는 것을 교착상태 때문인지, 네트워크 문제인지, 단순 처리가 늦어서 인지 알 수 없다. 따라서 교착상태를 파악하기 어렵다.
가장 큰 문제점은 따로 있다. 바로 시스템에 따라 교착 상태가 발생하는 빈도나 시스템에 미치는 영향이 다르다는 것이다.
마지막 방법은 자원할당 그래프를 이용한 교착상태 검출이다. 뭔가 앞에서부터 내용이 계속 연결돼서 오는 것 같다.
자 그럼 자원 할당 그래프는 그래프를 그렸을 때 한 붓 그리기가 성공한다면 교착상태가 없는 것이다. 하지만 만약 단일 자원을 사용하는 경우 그래프에 사이클이 있다면 교착상태가 된다.
자원 할당 그래프의 장점은 프로세스의 작업 방식을 제한하지 않으면서 교착상태를 파악할 수 있다는 것이다. 하지만 그래프를 유지하고 갱신하고 사이클을 검사하는 추가 작업으로 오버헤드가 발생한다.
만약에 교착상태 검출을 마무리하면 그다음에는 무엇을 해야 할까?바로 교착상태를 회복하는 후속 작업을 해야 한다.
교착 상태 회복에서는 관련된 프로세스를 강제로 종료시키며 강제로 종료된 프로세스가 실행되기 전에 시스템을 복구하는 일을 해야 한다.
물론 아무 때로나 돌아가면 안 되므로 명령어가 실행될 때마다 체크포인트를 만들어서 가장 최근의 시점으로 돌아간다. 회귀한다. 요즘 회귀물 많이 나오지 않는가? 이거 생각하면 된다.
하지만 작업량이 상당해서 시스템에 부화를 주니까 선택적으로 사용해야 된다.
물론 강제 종료할 때도 종료되는 순서가 있다.
뭐부터 될까? 일단 우선순위가 낮은 프로세스 그리고 작동 시간이 짧은 프로세스, 마지막으로 자원을 가장 많이 사용하는 프로세스 순서대로 강제 종료된다.
이것으로 마무리하고 나도 강제종료 해야겠다.