@ Dispatcher는 Context Switching을 담당하는 가장 중요한 부분입니다.
@ Dispatcher는 Process 와 Process 사이에서
// CPU를 옮기는 일을 합니다.
> 이 때 작업을 진행하기 위해서는 Dispatcher가 CPU를 가지고 있어야 합니다.
@ Dispatcher가 수행된다는 것은
// 커널로 Execution Control이 진입한다는 의미와 같습니다.
> 이 때 Interrupt라고 하는 매커니즘을 이용했습니다.
@ Control이 어떤 코드에서 다른 코드로 넘어가는 것을 생각해봅시다.
// 커널 모드 함수가 수행이 되기 위해서는 mode change가 필요합니다.
> mode change가 일어나기 위해서는 Interrupt가 필요합니다.
.. H/W는 그렇게 설계되어 있습니다.
@ 우리가 mode change를 조금 더 이해해볼까요?
// 먼저 OS에서 잘못 이해하는 것을 말해볼까요?
> 일반적으로 독자적인 Thread of Control을 가진 것이라고 생각합니다.
.. 실제로는 Passive합니다.
.. OS는 커널 모드에서 수행되는 라이브러리(collection of Function) 입니다.
.. 이를 우리는 system call 함수라고 부릅니다.
.. Interrupt Service 루틴으로 이루어져있습니다.
@ 모드를 조금 더 공부해보도록 하겠습니다.
// 커널 모드
> Privilged Instruction을 수행할 수 있습니다
// 유저 모드
> 굉장히 제한된 상황에서 수행합니다.
@ 이 모든 모드는 Process Status Mode register의 mode bit로 표현합니다.
// Interrupt로 이를 H/W적으로 바꿉니다.
@ Dispatcher가 불려지기 위해서는
// Interrupt가 필요합니다.
@ 이를 호출하기 위해서는 두가지 방법이 있습니다.
// 첫 번째는 Process가 스스로 CPU를 다른 Process에게 넘겨주는 것입니다.
> I/O를 요청했는데 아직 준비 되지 않았을 때, 넘겨줍니다.
.. Non-Preemptive Scheduling이라고 부릅니다.
.. S/W Interrupt(trap)을 이용하면 구현이 가능합니다.
.. 스스로 CPU를 irred 하면, trap을 야기 시키면 됩니다.
.. 이는 다른 Interrupt와 구별합니다.
// 반대는 강제로 빼앗기는 것입니다.
> Time sharing에서 Time이 지났을 때, 강제로 빼았습니다.
.. Preemptive Scheduling 이라고 부릅니다.
.. 이를 구현하기 위해서는 Timmer가 필요합니다. (H/W interrupt)
.. 이렇게 Dispatcher가 수행되게 됩니다.
@ 각각 상황에서 어떤 Interrupt가 발생하는지 아는 것이 중요합니다.
// malloc과 같은 함수(커널 함수)들인 System call을 부를 때 또한 Interrupt가 필요합니다.
// Trap을 발생시킵니다.
.. Trap 중의 일부분은 System call이라고 부르고 Instruction을 제공하기도 합니다.
@ 이 때 Interrupt가 발생할 때 어떤 일이 일어나는지 Time Line을 확인해보겠습니다.
// User Process는 Read System call을 호출합니다.
// Interrupt가 발생하고
// mode change가 일어납니다.
// return하게 될 때는, 어떠한 매커니즘이 필요하지 않습니다.
> 이미 커널에서 돌아가고 있는 상황이기 때문입니다.
@ 자 생각해보았을 때, Read System call이 일어날 때,
// 수행중인 Process Context는 누구일까요?
> 수행의 주체는 System call을 호출한 사용자 프로세스입니다.
.. 커널의 프로세스가 수행의 주체가 되지 않습니다.
@ 프로그램의 현재 상태를 무엇으로 Trace하느냐 하면,
// 수행중인 Process의 stack을 보고 Trace를 하게 됩니다.
@ 프로세스는 두가지 요소를 가집니다.
// State(Context)
// Execution Stream(Thread of Control)
> 디버그를 할 때, breack point를 보고 stack을 보게 됩니다.
.. 플로세스의 수행된 이력을 볼 수 있게됩니다.
> 프로세스가 처음으로 시작된 순간부터 수행된 instruction의 squence
.. 이가 조금 더 abstract한 것이 함수입니다.
> 그래서 Stack만은 Thread of Control에 포함됩니다.
.. 프로세스의 Execution상황은 Stack을 확인하여 알 수 있습니다.
@ 프로세스의 Stack은 그 프로세스의 run-time context입니다.
// 모드에 따라 Stack은 변할 수 있지만 (user mode - user mode stack)
> 그 수행의 주체인 프로세스 ID는 유지 된다는 것을 기억해야 합니다.
> run-time context는 변화합니다.
@ 여러 측면에서 유저 Execution과 커널 Execution을 구별할 수 있어야 합니다.
@ System Call과 Function Call의 비교를 해볼까요
// 공통점은 한 루틴에서 다른 루틴으로 컨트롤이 넘어갑니다.
// 다른 점은 system call은 모드 체인지가 있고, 다른 편은 그렇지 않다는 것입니다.
