[Real Time] Aperiodic Task에서의 Server의 역할

지난 포스트까지 해서 Periodic Task가 들어왔을 때 대처할 수 있는 Scheduling 기법을 다뤘다. 

하지만 Task가 항상 Periodic하게만 오지는 않는다. 당연히 예기치 못한 동작에 대해서도 올경우도 있을 것이고, 또는 사용자의 입출력에 따라서 나타나는 Task가 있을 것이다. 보통 그런 것들을 통틀어서 비주기적 Task, Aperiodic Task라고 한다. 이 Aperiodic Task에도 발생되는 주기에 따라서 크게 두가지로 나눠볼 수 있는데 첫번째는 Soft Aperiodic Task이다. Task의 발생빈도나 execution time이 주기적이지는 않으나 그 발생하는 정도가 어떤 distribution을 나타내는 경우가 여기에 포함된다. 그래서 사용자의 요청을 받는 경우가 Soft한 케이스라고 볼 수 있다. 이거보다 조금더 Aperiodic 특성이 강한 것을 firm Aperiodic Task, 또는 Sporadic Task라고 한다. 단어 그대로 특성없이 산발적으로 발생하는 것인데 보통 이런 일을 처리하기 위한 요소 중 하나로 이전에도 계속 나왔던 Worst Case Execution Time 가 필요하다. 그래서 한계를 정한 후 이 한계를 벗어나지 않는 것에 대해서만 처리하는 방식이고, 한계라는 말에 있다시피 뭔가 조금더 응급한 Task를 처리하는데 이용되는 작업들이다. 

 그러면 이런 Aperiodic Task를 처리하는 방법은 어떤게 있을까? 

운영체제에서 나오는 일반적인 방법이 Interrupt Handling 방식이다. 말그대로 Task가 들어온 시점에서만 Schedule에 관여하게끔 하는 것이다. 

이건 Aperiodic Task의 Priority를 최고로 두고 들어왔을 때만 처리하는 형식이다. 이를 priority 관점으로 봤을 때 Interrupt와는 다르게 후순위로 둬서 처리하는 Background 방식도 있다.

이같은 경우는 T(1)과 T(2)가 수행된 이후의 idle time 에서만 Aperiodic task가 수행되는 방식이다. 

그럼 위와 같이 Task가 개입되었을 때 바로 반응이 나타나는 것과 안나타나는 것의 차이는 뭐가 있을까? 일단 두 방식이 일장 일단이 있다. interrupt Handling 방식은 말 그대로  Aperiodic Task를 처리하는 handler의 우선순위가 가장높기 때문에 response time이 가장 빠르다. 그런데 문제는 중요하지 않는 Task에 대해서 Non-Preemption을 가지기 때문에 정작 중요한 Task를 가지는 Hard RealTime Periodic Task를 처리하는데 문제가 발생한다. 반면 Backgound 방식은 반대의 특징을 가졌다고 보면 된다. 말그대로 후순위이기에 response time이 느리긴 하지만 Hard RealTime Task  Scheduling 시에 별 영향없이 사용할 수 있다. 

이것 말고도 Aperiodic Task가 들어오는 것을 주기적으로 감시하는 방법이 있는데 이걸 Polling 방식이라고 한다.

Interrupt 방식처럼 Aperiodic Task를 처리하는 Handler가 우선순위로 존재하되 주기적으로 idle time을 측정한 후 그 내에서 task가 수행되는 구조를 띈다. 

지금까지 다룬 Aperiodic Task handling의 공통점은 무엇일까? 바로 주어진 Task 이외에도 Aperiodic Task를 처리하기 위한 Handler가 존재한다는 것이다. 보통 이런 것들을 Server라고 한다. 다만 Interrupt의 경우에는 들어오는 순간에만 동작하므로 Server라고 보기 보다는 Handler라는 개념이 더 적절한 듯 하다. 아무튼 Server는 항상 상주해 있으면서 Aperiodic Task를 처리하는 일종의 Module이다. 하지만 Aperiodic Task를 처리하기 위해서 Server를 항상 on 시키는 것은 무척 비효율적이다. 그래서 보통 budget이라는 개념을 두고 정해진 period안에 일정 budget만 사용할 수 있는 구조를 갖추고 있다. 당연한 이야기이겠지만 budget을 다 소비한 순간 이후에 들어온 Aperiodic Task는 다음 주기가 올때까지 처리할 수 없으며, 이를 보관하기 위한 Queue가 필요하게 될 것이다. 

 물론 이 Server가 Periodic Task를 수행할수도 있으며, 이에 따른 Schedulability를 측정할 수 있다. 여기까지 오면 Aperiodic Task에 대한 Schedulability도 측정할 수 있는 방법이 있지 않을까라는 궁금증이 생길 수 있는데 이때는 첫번째 server영역에 대한 M/M/1 Queue를 뽑아내는 방법이 있다고 한다. 여기는 조금더 깊게 들어가야 확인해 볼 수 있는 내용이다.

 그런데 재미있는 것은 Aperiodic Task가 들어온 순간이 아니라 그 다음 period에서부터 Task가 수행되는 것이다. 이렇게 되면 이전 interrupt 장점에서 가져올 수 있었던 response time의 이점을 얻을 수 없게 된다. 그러면 어차피 Server가 Periodic이나 Aperiodic Task 를 처리하는데 Interrupt 방식과 Polling 방식을 혼합해서 쓸 수 있지 않을까 해서 개선하였는데 이에 대한 결과물이 Deferrable Server이다. 보통 이 Deferrable Server는 budget과 request의 workload를 비교해서 그 결과에 따라 동작방식을 변화시킨다. 가령 budget이 workload보다 크다면 request는 마치 interrupt가 수행되는 것처럼 Server가 High priority에 놓이게 된다. 반면 budget이 workload보다 작게 되면 그 때는 polling 처럼 동작하게 된다. 이밖의 경우에 대해서는 실험적인 결과를 토대로 server의 동작을 조절해야 한다. 

여기서 맨 밑에 있는 C(s)가 바로 execution budget의 변화량이다. 그래서 정해진 budget이 소비된 이후에는 두번째 task가 수행되고 이 budget이 충전된 이후에 Deferrable server에 들어있는 Aperiodic Task들이 수행되는 것을 확인할 수 있다. 그런데 budget이 충당된 이후에는 server가 high priority를 갖기 때문에 이로 인한 time overflow 현상이 생길 수 도 있다.