System call이나 Interrupt 발생 시 반드시 context switch가 일어나는 것은 아니다

[jinsusong]

Context Switching 이란 CPU가 한 개의 Task(Process / Thread) 를 실행하고 있는 상태에서 Interrupt 요청에 의해 다른 Task 로 실행이 전환되는 과정에서 기존의 Task 상태 및 Register 값들에 대한 정보 (Context)를 저장하고 새로운 Task 의 Context 정보로 교체하는 작업을 말한다. 그러나 Interrupt or System call 발생 후 다시 기존 프로세스로 복귀할 경우는 문맥교환이 발생하지 않는다.

[anuu0916]

문맥 교환이 아닌 경우 프로세스가 실행 상태일 때, 시스템 콜이나 인터럽트가 발생하면 CPU의 제어권이 운영체제에게로 넘어와 원래 실행중이던 프로세스의 업무를 잠시 멈추고 운영 체제 커널의 코드가 실행됩니다. 이 경우에 CPU의 실행 위치 등 프로세스의 문맥 중 일부를 PCB에 저장하게 되지만 이러한 과정을 문맥 교환이라고 하지는 않습니다.

이는 하나의 프로세스가 사용자 모드에서 실행되다가 커널 모드로 실행 모드만 바뀌는 것일 뿐, CPU를 점유하는 프로세스가 다른 사용자 프로세스로 변경괴는 과정이 아니기 때문입니다. 이와 같은 모드 변경에 비해 문맥 교환에는 훨씬 많은 오버헤드가 발생합니다. 타이머 인터럽트가 발생하거나 프로세스가 I/O 요청 시스템을 콜하여 봉쇄 상태에 들어가는 경우에는 문맥 교환이 일어나지만, 그밖의 인터럽트나 시스템 콜 발생 시에는 문맥 교환이 일어나지 않고 모드만 변경됩니다.

즉, 사용자 모드에서 커널 모드로 바뀌어 시스템 콜이나 인터럽트 처리를 하고 다시 동일한 프로세스의 사용자 모드로 되돌아와 이전에 수행하던 작업을 계속 수행합니다.

출처 : https://aktnfl.tistory.com/25

[SW-H]

컨텍스트 스위칭이 일어나는 경우

• 프로세스가 CPU 를 양보하는 경우
• 프로세스가 시스템 API 를 호출하는 경우
• 프로세스가 I/O 를 요청하는 경우
• timer interrupt

프로세스가 자발적으로 CPU 를 포기하는 경우 임베디드같이 프로세스를 적게 사용하는 경우 프로그래머가 조절해서 사용이 가능하다. 하지만 고의 혹은 실수로 하나의 프로세스가 CPU 를 계속해서 차지하는 경우가 발생할 수 있다.

시스템 API 호출을 이용하는 경우 시스템 API 호출 이후 다시 원래 프로세스로 돌아가는 것이 아니라 컨텍스트 스위칭을 시킨다. 사용자 상호작용이 많은 경우 사용이 가능하다. 문제점 : 시스템 API 를 호출하지 않는 프로그램의 경우 장기간 CPU 를 사용할 수 있다.

I/O 요청시 컨텍스트 스위칭하는 경우 I/O 를 기다릴 필요가 없으므로 I/O 요청이 발생하면 컨텍스트 스위칭한다. 2번과 유사하다. 문제점 : 2번과 마찬가지로 I/O 요청이 없는 프로세스의 경우 장기간 CPU 를 사용할 가능성이 있다.

timer interrupt 이용 (preemtive context switching) 컨텍스트 스위칭이 발생할 필요가 없음에도 불구하고 일정 시간 CPU 를 사용했다면 컨텍스트 스위칭이 일어난다. 이것을 preemtive context switcing 이라고 한다. 그 일정 시간에 해당하는 용어는 scheduling quantum 혹은 time slice 라고 부른다. 문제점 : 소프트웨어가 아니라 하드웨어에서 타이머를 지원해야 한다. 다행히 현대의 CPU 는 대부분 타이머를 지원하고 여러 개의 타이머를 지원하는 경우도 있다.