Interrupt 와 Context Switching

CPU가 어떠한 프로세스에 대한 작업을 수행하는 중,

(1)예상치 못한, (2)외부에서 발생한 이벤트로 인해 프로세스를 잠시 중단하는 것을 인터럽트라고 한다.

 

CPU 는 한 번에 하나씩의 일을 처리한다. 여러가지 프로그램을 동시에 실행하는 것으로 보이지만,

실은 여러개의 프로세스를 짧은 시간씩 번갈아 실행하고 있는 것이다.

 

여러 프로세스를 한번에 처리하지 못하고 돌아가며 처리해야 하기 때문에,

다른 프로세스를 실행하기 위해 실행중인 프로세스를 중단해야 한다.

이외에도 입출력이라던가, 예외사항들에 대해 프로세스를 중단하고 핸들링하기 위해 인터럽트가 필요하다.

 

 

 

 

Context saving to PCB

 

인터럽트가 발생하여 프로세스를 중단할 때,

진행중이던 작업 정보를 잃으면 위에서의 멀티태스킹을 정상적으로 수행할 수 없을 것이다.

그 정보를 Context 라고 칭한다.

이러한 Context 를 저장함으로써 작업 상태를 유지하고, 되돌아 갈 수가 있다.

 

일단 작업중이던 프로세스의 (1) 코드, 데이터, 스택, PCB와 같은 정보가 있겠고,

(1) CPU 에서의 작업 내용에 관한 정보가 있을텐데,

 

(1) 과 같은 경우는 메모리 내에 존재함으로 별도로 저장을 할 필요가 없다.

메모리 용량이 모자라도 디스크를 이용한 swap으로 처리한다.

 

(2) 의 경우인 CPU register context, 즉 CPU가 레지스터에서 작업중이던 내용은

CPU 에 존재하는데, 이 CPU를 다른 프로세스에게 양보하거나 해야하므로 이를 PCB에 저장한다.

 

 

 

Interrupt Handling

 

이후, Interrupt handler 라는 처리기로 인터럽트가 발생한 원인 및 장소를 파악하고,

이를 처리하기 위해 어떤 Service Routine을 호출할 것인지를 결정한다.

Interrupt Service Routine (ISR)이라는 인터럽트 처리 동작을 수행하게 된다.

ISR 은 인터럽트 원인에 따라 다양하게 존재한다.

 

여러가지 인터럽트 원인과 상황에 대하여, 그 인터럽트를 처리할 수 있는 ISR 들의 주소를 가지고 있는 공간을 

Interrupt Descripter Table (IDT) 라고 한다! 

메모리 상의 IDT 에서 찾은 ISR 의 주소로 점프하여 해당 처리를 실행한다.

(메모리 상 IDT 의 첫 번째 번지는 IDTR 이라는 레지스터로 찾는다)

 

https://www.programmersought.com/article/90021369/

불러오는 중입니다...

https://www.amd.com/system/files/TechDocs/24593.pdf

불러오는 중입니다...

 

 

Context Restoring

 

ISR 도 결국 프로세서에 의해 수행되기 때문에, 이를 마치고 나서야

Ready queue 에 있는 프로세스를 꺼내서 다시 프로세서로 올릴 수 있다.

( Ready queue 의 순서를 따르기 때문에 꼭 중단된 직전의 프로세스 아닐 수도 있다. )

 

프로세스를 다시 올리기 위해, 위에서 저장했던 Context 를 불러와서 복구하는 작업이 Context Restoring이다.

 

 

 

 

Context switching 과 Thread 의 필요성

 

위에서 살펴본 과정과 같이,

프로세스 간 전환을 위해 현재 프로세스의 Context Saving, 다음에 올 프로세스 Context Restoring 이 이루어지고 
커널에 의해 수행되는 이 과정을 Context switching 이라 한다 !

 

Context Switching 에는 비용이 꽤 있고, 너무 잦은 발생은 Overhead 를 초래한다. 이는 곧 OS 성능에 영향을 주게 된다!

이러한 Context Switching Overhead 를 최대한 줄여야 하는데, 어떻게 해결해야 할까?

 

Thread 의 사용이 바로 그 해결책이 될 수 있는 것이다 !