Multitasking의 약점


Concurrency를 구현하기 위해서는 multi-tasking이 필수적이고 multi-tasking을 지원하는 OS가 필수적이다. multi-task를 수행하는 이유는 구현 대상이 여러종류의 복잡한 기능을 수행해야 하기 때문이다.

사실, multi tasking은 고급 기능이긴 하지만, resource의 낭비를 초래한다. 그러므로 너무 많은 task를 scheduling하면 별로 효율이 좋지 않다.

인간의 경우 2개 이상의 task를 scheduling하면 효율이 급격하게 떨어진다고 한다.

그렇다… 난 임베디드 소프트웨어의 scheduling을 이야기하고자 하는 것이 아니라, 사람의 task에 대한 multi-tasking을 이야기 하고 싶은 것이다. 현실적이지 않다고 생각하는지 모르겠지만, 실제로 그렇다고 한다.

너무 많은 인터럽트와 너무 많은 context-switching은 작업의 효율성을 매우 떨어트린다. 사람이나 기계나 다를바 없다.

context switching을 할 때에는 어떤 비용이 들어갈까?

  1. 진행중인 작업을 중단한다. 다른 작업을 하기 위해서 현재 상태를 저장해놔야 한다. 뇌에서 백업을 할 수도 있고, 어떤 경우는 현재 상태를 문서로 기록해야 할 수도 있다.
  2. 새로운 작업을 가져온다. 새로운 작업을 수행하기 위해 과거에 진행되었던 상태에 대해서 뇌에 상태 정보를 로드해야 한다. 로딩 작업은 나이를 먹을 수록 오래걸린다.

Context switching이 잦을 경우 위의 오버헤드가 많이 발생하게 되므로 효율은 극히 낮을 수 밖에 없다.

그뿐만이 아니다, multi-tasking에는 다음과 같은 risk도 있다. 특히 체계적인 시스템을 갖추지 않은 몇몇 인간의 경우는 특히 더 빈번하게 발생한다.

  1. 진행중인 작업을 중단할 때, 상태 기록을 게을리해서 작업의 정보가 유실되어 다시 그 작업에 복귀할 때 해야하는 작업을 놓칠 수 있다. 보통 이런 상황을 깜빡했다라고 표현한다.
  2. 복귀 지점을 아예 놓쳐버릴 수도 있다. 보통 Interrupt service routine이 정상적으로 수행되고 원래 위치로 올바르게 돌아갈 것을 기대할 것이다. 하지만 인간은 그 관점에서는 취약하다. 원래 해야 할 일을 아예 까먹을 수 있다.

멀티태스킹을 피할수는 없을 것이다. 왜냐면 기업 입장에서는 개별 human인력의 효율성을 최대화한다는 명목으로 잠시라도 idle상태가 되는 것을 원하지 않을 것이기 때문이다. 그렇다고는 해도 너무 잦은 context switching이 발생하지 않도록 scheduling 정책을 잘 정해야 할 필요가 있다.

가급적 single task의 작업량을 길게 늘여야 한다. 시간을 짧게 해서 여러개의 task를 돌리면 response time은 좋을지 모르지만 일반적인 인간이 해야 하는 복잡하고 집중력을 요하는 업무라면 responsiveness가  그렇게 중요하지 않는 경우도 있다. trade off로 responsiveness를 희생하더라도 performance를 높여야 한다.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s