@ Dispatcher라는 것은 현재 Process와 다른 새로운 Process가 선택(Policy)된 후의 과정에 영향을 미칩니다.
// 이는 꽤 단순한 일을 합니다.
> OS의 가장 깊숙한 곳에서
.. loop forever(무한루프){
.. run the process for a while (주어진 Process를 어느정도 돌립니다)
.. stop it and save its state (프로세스를 중단시키고, 상태들을 대피시킵니다)
.. load state of another process (새로운 Process의 이전 상태들을 다시 로드합니다.)
.. }
> 이런 작업들을 계속해서 하는 것이 Dispatcher입니다.
// 이런 일련의 작업들은 Policy와는 관계없이 기계적으로 반복하게 됩니다.
@ 위의 작업들이 바로 Process Scheduler, CPU를 관리하는 Operation의 가장 핵심적인 기능입니다.
@ 위의 부분은 개념적인 부분입니다.
// 실제로 저렇게 돌아가기 위해서는 모순이 되는 것이 있습니다.
// OS를 공부할 때, OS에 대해 가지게 되는 miss conception이 있습니다.
@ 이전에 배운 것을 다시 복습해보겠습니다.
// Program은 수동적인 존재입니다.
// Process는 능동적인 존재입니다.
// 그렇다면 OS는 수동적일까요, 능동적일까요?
> 우리가 대부분 알고 있는 상식으로 능동적이게 보입니다.
.. Process를 관리하고
.. 상황에 따라 kill or abort시키기도 합니다.
@ 하지만 실제로는 OS는 굉장히 Passive한 entity입니다.
// 하지만 위의 Dispatcher를 보면 매우 능동적이게 보입니다.
> 하지만 이런식이 되기 위해서는
.. Dispatcher를 위한 CPU와
.. user process를 위한 CPU
.. 총 두개가 필요하게 됩니다.
@ 하지만 OS는 Single CPU에서도 잘 돌아갑니다.
// 한 마디로 다른 방식이 존재한다는 것입니다.
> 이 방식은 바로 CPU Control을 User Process에서 OS(Dispatcher)로
> OS(Dispatcher)에서 User Process로 넘어가는 방식입니다.
.. 이를 interbeing이라고 합니다.
@ 그럼 어떻게 하면 CPU Control을 자연스럽게 넘어가게 할 수 있을까요?
// 이럴 때 저희는 H/W로 구현할 것인지, 혹은 S/W로 구현할 것인지를 생각해야 합니다.
// 이 경우에는 H/W로 구현을 해야하는 Mechanism이라는 것을 알 수 있습니다.
@ 이는 앞에서 배웠던 것처럼
// User mode에서 kernel mode로 넘어가는 형태로
> Interrupt 매커니즘을 사용하게 됩니다.
.. 그렇게 Kernel mode에서 Dispatcher(context switching)가 돌게 됩니다.
@ 그래서 지난시간 리뷰한 하드웨어 매커니즘 이해가 필요합니다.
@ 어떻게 Control이 user process에서 Dispatcher로 가는 것인지,
> 정확히는 user mode에서 kernel로 들어가고 나오는가는
.. Interrupt와 mode change를 잘 이해하고 있어야 합니다.
