[CS DAY6] - Interrupt : CPU 가 프로그램 실행도중, 인터럽트를 받으면 무슨 일이 일어나는걸까?

Об этом предложении

이전, DAY5 에서는 다음과 같은 내용까지 봤었다. CPU가 직접 계속 확인 Polling vs 장치에 일이 생기면 CPU에게 알림 Interrupt 오늘은, CPU 가 작업도중 인터럽트를 받았을때 무슨일이 일어나는지 알아보자. CPU 가 JAVA 프로그램을 실행하고 있던도중, 키보드 인터럽트가 발생했다. CPU 가 해당 이벤트를 처리하고나서, CPU 는 어떻게 원래 프로그램으로 정확하게 돌아오는걸까 ? CPU 가 다음 프로그램을 실행하고 있다고 하자. int a = 10; int b = 20; int c = a + b; System.out.println(c); 물론, CPU 가 JAVA 소스를 그대로 실행하는거는 아니고, 이전에 배웠었던 여러가지 과정들을 거쳐서, CPU 가 명령어를 실행한다. ( Bus, Fetch , Decode, Execute ... ) 단순화해서 생각해보면, CPU 는 아래와 같은 방식으로 실행하고있다고하자. 명령어 100 ↓ 명령어 104 ↓ 명령어 108 ↓ 명령어 112 ↓ ... 이에 따라, Program Counter(다음 실행할 명령어 주소) 도 계속해서 바뀔것이다. PC = 100 ↓ PC = 104 ↓ PC = 108 ↓ PC = 112 그런데, 108 근처를 실행하던 도중에 사용자가 키보드 입력을 했다고해보자. CPU 명령어 실행 ↓ 명령어 실행 ↓ 키보드 입력 발생 -> ─────── INTERRUPT! ─────── CPU 가, 이를 인지하고 해당 이벤트를 처리해야한다. 그런데, CPU 입장에서는 실행하고있던 즉, 원래 하던 작업은 어떻게 해놓고 가야할까? 만약, CPU 가 인터럽트를 처리하면서 기존 상태를 잊어버린다고 하자. 예를들어, CPU Register 가 아래와 같다고 하자. R1 = 10 R2 = 20 PC = 108 인터럽트를 처리하면서 Register를 사용해서, 해당 인터럽트를 처리했다. ( 이벤트 처리 ) 이후, CPU 는 무엇을 해야하느니 모르는 상태인것이다. 즉, CPU -> "어디까지 실행했었지?" 이렇게된다면, 프로그램은 정상적으로 이어갈 수 없다. 그렇기에, Interrupt 에는 매우 중요한 원칙이 있다. 원래 실행하던 프로그램의 상태를 보존했다가, 인터럽트 처리가 끝나면 복원해야만 한다. CPU 가 프로그램을 실행중이라고 하자. R1 = 10 R2 = 20 PC = 108 이러한 정보들은 프로그램을 계속해서 실행하는데에 매우 중요하다. 특히, PC ( Program Counter 는 다음에 어떤 명령어를 실행할 것인가와 매우 관련이있다. 다음과같은 CPU 의 실행 상태를 큰 의미에서 Context 라고 생각할수있다. Context R1 = 10 R2 = 20 PC = 108 즉, Context -> CPU 가 현재 작업을 계속하기 위해, 기억해야 하는 실행 상태. 다시, Interrupt 에 대해서 살펴보자. 프로그램 실행 ↓ Interrupt 발생 ↓ 현재 실행 상태 보존 ↓ Interrupt Handler 실행 ↓ Interrupt 처리 완료 ↓ 기존 상태 복원 ↓ 원래 프로그램 실행 계속 전체적인 흐름은 다음과 같다. CPU 가 평소처럼 Fetch -> Decode -> Execute 를 반복하면서, 명령어들을 처리하고있다. 예를들어, PC = 100 ↓ Fetch ↓ Execute PC = 104 ↓ Fetch ↓ Execute PC = 108 ↓ Fetch ↓ Execute 이러한 상황에서 키보드 입력이 발생했다고 하자. 키보드 장치가 Interrupt 를 요청한다. 사용자 ↓ Keyboard ↓ Controller ↓ Interrupt 요청 ↓ CPU CPU 에게, 처리해야 하는 이벤트가 발생했다고 알려주는것이다. CPU 가 이 요청을 받아들이면 원래 실행하고 있던 흐름에서, 이벤트 처리를 하기 위해 잠시동안 벗어나야 한다. 현재 CPU 의 상태가 다음과 같다고 하자. PC = 108 R1 = 10 R2 = 20 R3 = 30 Interrupt 처리가 끝난뒤에는, 원래 작업으로 돌아가려면 해당 상태를 기억하고 있어야만한다. 즉, CPU는 Interrupt 처리를 하기전에 해당 상태 ( Context) 를 기억하고있는다. CPU는, Interrupt 를 처리하기위해 Interrupt Handler 로 이동한다. Interrupt 가 발생했다고해서, CPU 가 알아서 키보드 입력 처리를 하는게아니라 Interrupt 종류에 따라 실행해야할 코드가 존재한다. ( 키보드 / 마우스 / ... ) 이를 일반적으로 Interrupt Handler 라고 한다. (인터럽트 처리 루틴 ) Interrupt 발생 ↓ 어떤 Interrupt인가? ↓ 해당 Handler 찾음 ↓ Handler 실행 이렇게해서, Interrupt 를 처리한다. 만약 키보드 입력이라면 ... Keyboard Interrupt ↓ Keyboard 관련 Handler 위와 같을것이다. Handler 를 실행한다. CPU 입장에서는, Handler 또한 결국 명령어의 집합인것이다. 그래서 뭔가 마법처럼 Interrupt 를 처리하는것이 아니라, 이전에 봤었던 흐름들이 계속해서 이어진다. CPU -> Handler Fetch ↓ Decode ↓ Execute 즉, Handler 의 명령어들을 가지고와서 실행한다. 필요한 작업들을 실행했고, Handler 를 통해서 명령어들을 가지고와서 해당하는 Interrupt 를 처리했다. 이제, CPU는 원래 진행하고있던 프로그램으로 돌아가야만 한다. 이때, 위에서 말했던 Context 를 활용한다. 저장된 상태 PC Register CPU 상태 Interrupt 를 처리하기전에, 상태 ( Context ) 를 저장한다고 했었다. 이제, Interrupt 를 다 처리했으니 해당 Context 를 가지고와서, CPU 에 다시 복원한다. 이후, CPU 는 복원된 Context 를 통해서 실행중이던 프로그램을 실행한다. 즉, 전체적인 흐름은 다음과 같다. Java 프로그램 실행 ↓ CPU 명령어 실행 PC = 100 PC = 104 PC = 108 ↓ !!! Interrupt !!! ↓ 현재 상태 저장 ( Context ) PC / Register / ... ↓ Interrupt Handler ↓ 처리 완료 ↓ 기존 상태 복원 ↓ 원래 프로그램 계속 실행 프로그램 입장에서는 잠시 멈췄다가 다시 실행되는것과 같다. Interrupt 가 발생했다고해서, CPU 가 즉시 멈추는걸까? CPU는 보통 현재 명령어 실행과 인터럽트 인식 시점 등의 규칙에 따라 안전한 경계에서 인터럽트를 처리한다. 즉, 즉시 멈추는것이아니라 판단하기에 적당한 시점에 Interrupt 를 처리한다. 명령어 실행 중 ↓ Interrupt 요청 인식 ↓ 현재 실행 흐름을 안전하게 중단할 수 있는 시점 ↓ Handler 이동 DAY5 에서 봤었던 Polling 방식과 Interrupt 방식을 다시한번 살펴보자. Polling 이라면 아래와 같이 실행된다. CPU ↓ Keyboard 확인 ↓ 없음 ↓ 프로그램 조금 실행 ↓ Keyboard 확인 ↓ 없음 ↓ 프로그램 조금 실행 ↓ Keyboard 확인 반면, Interrupt 라면 다음과 같이 실행된다. CPU 프로그램 실행 ↓ 프로그램 실행 ↓ 프로그램 실행 ↓ Keyboard │ │ Interrupt ↓ CPU 현재 상태 저장 ↓ Handler ↓ 상태 복원 ↓ 프로그램 계속 즉, CPU 가 장치를 계속 확인할 필요가 줄어든다. 예를들어, 다음과 같은 상황을 상상해보자. 나는 택배를 시켰고 택배는 언젠가는 온다는것을 알고있다. Polling 방식과 같다면, 내가 무언가를 하다가 ( 밥을 먹던가 / 샤워를 하던가 / 컴퓨터를 하던가 ... ) 택배가 왔는지 계속해서 문앞으로 나가서 확인해본다. 이는, 당연히 비효율적이다. 내가 하고있던 것들을 끊고 나가야하기도 하므로. 반면에, Interrupt 와 같은 방식을 생각해보자. 나는 그냥 내가 해야할것을 하고있는다. 그러다가, 벨이 울렸고 나는 문을 열어볼것이다. ( 벨이울린다면, 택배가 왔다는 상황이라고 가정. ) 이와 같은 방식은 계속해서 확인하는 Polling 방식에 비해 효율적이다. Timer Interrupt Interrupt 는 키보드나 SSD 와 같은 것들에서만 오는것이 아니다. 앞으로 운영체제를 배우기 위해서는 중요한 Interrupt 가 존재하는데, 이것이 Timer Interrupt 이다. 컴퓨터에는 일정 시간마다 CPU 에게 인터럽트를 발생시킬 수 있는 타이머가 존재한다. 예를들어, 아래와 같은 자바코드를 실행했다고 하자. while (true) { } 무한 루프에 빠진 상황이다. 이와같다면, 다른 명령어들은 실행되지 못할것이다. 위 코드에 있는 Context 가 다음과 같다고 하자. CPU PC = 100 R1 = 10 R2 = 20 해당하는 프로그램(Program A 라고하자.) 만 계속해서 실행중인 상황이다. Timer Interrupt 가 발생하고, 운영체제가 판단한다. Program A 그만하고, Program B 실행하자. 그러면, Program A 의 상태를 저장해야 한다. CPU PC = 100 R1 = 10 R2 = 20 이후, Program B 의 상태를 가지고온다 Program B Context PC Register ... 이제, CPU 는 위에있는 정보를 바탕으로 Program B 를 실행한다. CPU Program A ↓ 상태 저장 Program B ↓ 상태 복원 CPU ↓ Program B 실행 이것이, 다음에 운영체제쪽에서 배울 Context Switching 의 핵심이다. 오늘은, Interrupt 발생했을때, 처리하는 전체적인 과정을 봤다. CPU 가 다른 작업으로 갔다가 돌아오기위해서는, 진행중이던 상태를 저장해야 한다. 라는것이 중요하다. Interrupt 가 발생하면, CPU 는 원래 실행중이던 곳으로 돌아오기 위해 현재 실행중이던 상태를 저장해두고, Interrupt Handler 를 통해 해당 Interrupt 를 처리한다. 이후, 저장해뒀던 상태 ( Context) 를 통해 원래 실행중이던 프로그램으로 돌아올수있다. 이렇게, 기존 실행을 이어갈수있는것이다.