[OS] Mint64OS 19절 Multilevel Queue Scheduler

지난 포스트에서 이야기 했던 것처럼 Round-Robin 방식을 쓰면 그냥 단순한 방식보다는 효율적으로 Task를 처리할 수 있다. 하지만 어떤 경우에는 기존 방식과 차이가 없는 경우도 발생하는데 이 때문에 조금더 발전한 방식이 바로 지난 포스트에서 잠깐 언급했던 우선순위를 도입한 방식이다. 이를 단계를 여러개로 구분했다 하여서 multilevel Queue Scheduler 이다.

 당연한 이야기이겠지만 분명 queue가 필요하다는 말은 처리해야 될 task가 여러개 있다는 것이고 이걸 나눠서 처리하기 위해서는 따로 상태를 저장해둘 공간이 필요하다. 그리고 어떤 우선순위의 기준으로 볼것인가를 정해야 한다. 생각해볼 것은 큐에서도 여러 큐중 우선 순위가 높은 큐를 찾는 것이 우선이 되어야 할 것이고 그 안에 들은 task 중에서도 우선순위가 높은 task를 선별하는 것이 이뤄져야 한다.

 그런데 너무 우선 순위가 고려하다 보면 분명 후순위에 있는 task는 뒷전으로 밀리게 된다. 나중에 처리되어야 하는게 정상이지만 task의 동작 특성상 우선 순위가 낮은 task가 실행되고 있는 도중이더라도 높은 task가 개입하면 수행하지 못하고 밀리게 된다. 이 같은 과정이 지속되면 결국은 처리되지 못하는 문제가 발생하는데 이걸 Starvation이라고 한다. 공룡책에서는 이 현상을 원형 테이블상에서 식사하는 예제로 소개하고 있다. 이 starvation 현상을 방지하기 위한 방법이 여러가지가 있겠지만 이책에서 소개한 방법은 우선순위를 고려해서 task가 수행되게 하되, 우선순위가 낮더라고 한번은 실행되게 하는 구조를 취하고 있다. 이를 위해서는 각각의 task 의 실행횟수(ExecuteCount)를 계속 파악하고 있어야 한다.

 

지금은 아무것도 실행되지 않은 상태에서의 cpuload와 task를 100개 만들었을 때의 cpuload를 비교한 것이다.

실질적으로 100개의 task를 생성했지만 list상에 떠있는 task는 102개다 이유는 지금 키보드 입력을 받는 task와 임의의 task가 실행되고 있어서 이다. 당연히 입력을 받는 task는 우선순위가 가장 높을 것이고 후에 만들어준 100개의 task보다 먼저 수행된다. 앞에서 말한 것처럼 이게 우선 순위가 높다고 그것만 수행되는 것이 아니라 전체적으로 100개의 task가 동식에 돌아가는 것(처럼 보인다. MultiTasking)을 확인할 수 있다. 책속에 포함되어 있는 예제에는 우선 순위를 바꾸는 간단한 command가 소개되어 있는데 당연히 ID=[0x1000000000] 의 우선 순위를 3으로 줄이면 화면에 출력되고 있는 task에 먼저 수행되는 이유가 전혀 없기 때문에 골고루 수행된다. 따라서 이전보다 입력이 조금 느려지는 것을 확인할 수 있다.

지난 포스트에서 잠깐 소개했던 task 1 인데 이번에는 100개를 생성한 후에 task가 모두 실행을 한번씩 하면 자동으로 종료되게끔 했다.