인터럽트란?
- 프로그램 실행 도중, 예상치 못한 외부에서 발생한 이벤트로, OS / 하드웨어 장치(입출력장치) / 소프트웨어(예외, 시스템 호출등 )가 CPU의 정상적인 프로그램 실행을 방해했다는 의미
- CPU가 프로그램을 실행 중일 때 더 중요한 작업(입출력, 시스템 요청, 예외 등)이 발생하면, CPU에게 알려 현재 실행 중인 작업을 중단하고 발생된 상황에 대한 해당 요청을 우선 처리하는 매커니즘이다.
- CPU가 실행 중 인터럽트가 발생하면, 현재 작업을 저장하고(컨텍스트 스위칭) 인터럽트 핸들러(ISR, Interrupt Service Routine) 를 실행한 후 원래 작업을 재개한다.
인터럽트(Interrupt) vs 예외(Exception)
인터럽트 : 주로 외부 장치(키보드 입력, 타이머, 네트워크 등)에서 발생하며 CPU의 개입을 요구한다.
예외 : 프로그램 실행 중 오류(0으로 나누기, 메모리 접근 오류 등)로 인해 발생하며, CPU가 즉시 처리해야 한다.
인터럽트 종류
기준 : CPU
- 외부 인터럽트 (일반적인 인터럽트, Hardware Interrupt))
- CPU 외부적인 요인(입출력 장치, 타이머, 전원 장애 등)으로부터의 인터럽트 요구 신호에 의해 발생되는 인터럽트
- 하드웨어 컨트롤러(장치)가 CPU의 서비스를 요청하기 위해 발생시키는 인터럽트, 비동기적으로 발생
- I/O Interrupt (입출력)
- 입출력 장치가 데이터 전송을 요구하거나 전송이 끝나 다음 동작이 수행되어야 하는 경우
- 입출력 데이터에 이상이 있는 경우
- 타이머 인터럽트
- CPU의 일정한 시간 간격을 유지하기 위해 발생 (OS의 시분할 처리)
- Machine check interrupt (기계 착오)
- CPU의 기능적 오류
- CPU 내부 하드웨어 오류 (예: 메모리 오류, 캐시 오류 등)
- gpt : 외부 인터럽트라기보다는 CPU 내부 하드웨어 오류 감지에 해당하므로 별도로 분류하는 것이 더 정확
- 전원 이상
- 내부 인터럽트 (Internal Interrupt, Trap)
- CPU 내부에서 명령어 실행 중 발생하는 인터럽트
- 프로세서가 실행 중 감지한 오류나 특정 이벤트로 인해 발생
- 컴퓨터의 내부 시스템에서 생성되는 인터럽트로, CPU 내부에서 자신이 실행한 명령이나 CPU의 명령 실행에 관련된 모듈이 변화하는 경우 발생
- 프로그램 실행 중 프로그램 상의 처리 불가능한 오류나 이벤트를 알리기 위한 경우 발생하는데, 이를 Trap 또는 예외라고 한다.
- 프로그래머가 의도하지 않은 오류(예: 0으로 나누기, 오버플로우 등)와 의도적인 Trap(SVC, 시스템 콜 등) 이 포함
- 예외(Exception) 인터럽트 (오류 발생 시)
- Program Check Interrupt
- Division by zero (0으로 나누기)
- Overflow / Underflow (오버플로우 / 언더플로우)
- 기타 Exception : 잘못된 명령어 사용
- Program Check Interrupt
- 시스템 콜 인터럽트 (Trap, SVC)
- 프로그램이 운영체제의 서비스를 요청할 때 발생
- OS 커널 모드로 전환하는 역할
- ex) 파일 읽기/쓰기, 프로세스 생성 등
- 예외(Exception) 인터럽트 (오류 발생 시)
- 소프트웨어 인터럽트
- 소프트웨어 명령에 의해 의도적으로 발생하는 인터럽트
- 내부 인터럽트(Trap)와 일부 겹침
- 운영체제 서비스 요청 (SVC, 시스템 콜)
- 프로그램 처리 중 명령의 요청에 의해 발생한 것 (SVC interrupt)
- 운영체제에게 제어권을 넘겨 해결하는 Supervisor Call
- 시스템 콜과 같은 맥락으로, 운영체제에 서비스를 요청하기 위해 인터럽트를 걸고 커널 모드로 전환하는 인터럽트
사용자가 프로그램을 실행시킬 때 발생- 사용자가 실행 중인 프로그램이 OS 서비스(시스템 콜)를 요청할 때 발생
- 소프트웨어 이용 중에 다른 프로세스를 실행시키면 시분할 처리 및 멀티태스킹을 위해 자원 할당 동작이 수행된다.
- 실행 중인 프로세스가 CPU를 점유하는 시간 초과 시 발생
인터럽트의 종류를 구분하는 관점
내부 인터럽트에 소프트웨어 인터럽트를 포함하여 말하는 경우도 있다.
또한 외부 인터럽트를 HW 인터럽트, 내부 인터럽트를 SW 인터럽트라 구분하기도 한다.
통산적으로 HW 인터럽트를 인터럽트, SW 인터럽트는 트랩이라는 용어를 사용한다.
인터럽트의 필요성
- 운영체제는 동시에 여러 작업을 처리할 수 없고, 사용자는 한 번에 여러 작업을 처리하기를 원한다.
- 대부분의 컴퓨터는 한 개의 CPU만 사용하기 때문에, 어떤 일을 처리하는 도중 우선순위가 급한 일을 처리할 필요가 있을 때 대처할 수 있는 방안이 필요하다.
- 멀티태스킹이 가능하려면 먼저 시작한 작업이라도, 우선순위가 더 높은 작업을 먼저 처리하도록 지시할 수 있어야 하는데 해당 기능이 인터럽트이다.
인터럽트 처리 과정
- 주 프로그램이 실행되다가 인터럽트 발생
- 프로세스(현재 실행 중인 프로그램) 중단 (커널 개입)
- 프로세스의 정보를 PCB에 저장(Context Saving)
- 상태 레지스터와 PC 등을 잠시 스택에 저장한 뒤, 인터럽트 서비스 루틴으로 간다.
- 잠시 저장하는 이유 : 인터럽트 서비스 루틴이 끝난 뒤 다시 원래 작업으로 돌아와야 하기 때문
- 만약 인터럽트 기능이 없었다면, 컨트롤러는 특정한 어떤 일을 할 시기를 알기 위해 계속 체크해야 한다. (이를 폴링(Poling)이라고 한다.)
- 폴링을 하는 시간에는 원래 하던 일에 집중할 수가 없게 되어 많은 기능을 제대로 수행하지 못한다는 단점이 있었다.
- 프로세스의 정보를 PCB에 저장(Context Saving)
- 인터럽트 처리 (interrupt handling)
- 인터럽트 발생 장소, 원인 파악
- 인터럽트 서비스 할 것인지 결정
- 인터럽트 서비스 루틴 호출(interrupt service)
- 인터럽트를 서비스하기로 결정했을 경우 진행
우선순위 판별 방법
컨트롤러가 입력을 받아들이는 방법
- 폴링 방식
- 사용자가 명령어를 사용해 입력 핀의 값을 계속 읽어 변화를 알아내는 방식
- 인터럽트 요청 플래그를 차례로 비교하여 우선순위가 가장 높은 인터럽트 자원을 찾아 이에 맞는 인터럽트 서비스 루틴을 수행 (하드웨어에 비해 속도 느림)
- 인터럽트 방식
- MCU 자체가 하드웨어적으로 변화를 체크하여 변화 시에만 일정한 동작을 하는 방식
- Daisy Chain
- 병렬 우선순위 부여
- MCU 자체가 하드웨어적으로 변화를 체크하여 변화 시에만 일정한 동작을 하는 방식
인터럽트 방식은 하드웨어로 지원을 받아야 하는 제약이 있지만, 폴링에 비해 신속하게 대응하는 것이 가능하다. 따라서 실시간 대응이 필요할 때는 필수적인 기능이다.
즉, 인터럽트는 발생시기를 예측하기 힘든 경우에 컨트롤러가 가장 빠르게 대응할 수 있는 방법이다.
인터럽트 플래그 (interrupt flag)
하드웨어 인터럽트를 받아드릴지, 무시할 지 결정하는 플래그
0 설정 시 인터럽트 요청을 무시한다.
모든 하드웨어 인터럽트를 인터럽트 플래그로 막을 수는 없다. 이때 막을 수 있는 것을 'markabel Interrupt', 막을 수 없는 것을 'non markabel Interrupt'로 구분한다.
인터럽트 핸들러 (인터럽트 서비스 루틴, Interrupt Service Routine, ISR)
ISR은 인터럽트 서비스 루틴의 약자로 인터럽트가 발생했을 때 CPU가 실행하는 루틴을 말하며 해당 인터럽트를 처리하는 코드를 말합니다. 인터럽트 핸들러라고도 불린다.
- CPU가 실행하는 실제 인터럽트를 처리하는 루틴
- 인터럽트 발생 시, 인터럽트 별로 필요한 작업을 수행할 수 있도록 정해져있는 OS 안의 코드로 어떻게 처리하고 작동할 것인지에 대한 정보로 이루어져 있다.
- 인터럽트 핸들러는 인터럽트 원인에 따라 각각 존재
- OS 코드 부분에는 각종 인터럽트별로 처리해야할 내용이 이미 프로그래밍 되어 있다.
- 호출된 인터럽트 서비스 또한 하나의 프로세스이다. 따라서 서비스가 끝나면 ready 상태의 프로세스들이 올라온다.
ISR은 인터럽트가 발생했을 때 실행되는 코드 블록으로, 특정 인터럽트를 처리하는 역할을 한다.
ISR의 동작 과정
- 인터럽트 발생
- 하드웨어 또는 소프트웨어에서 인터럽트가 발생하면 CPU는 현재 실행 중인 작업을 중단
- 현재 작업 상태 저장
- CPU는 현재 실행 중인 프로세스의 레지스터 값, 프로그램 카운터(PC) 값 등을 저장하여 나중에 복원할 수 있도록 한다.
- ISR 실행
- 인터럽트 벡터 테이블(IVT)에서 해당 인터럽트에 맞는 ISR의 주소를 찾아 실행한다.
- 인터럽트 처리 완료
- ISR이 인터럽트 요청을 처리한 후, 인터럽트 완료 신호를 보내 인터럽트 처리가 끝났음을 알린다.
- 이전 작업 복원 및 실행 재개
- 저장해 둔 레지스터 값과 프로그램 카운터 값을 복원하고, 중단되었던 작업을 다시 실행한다.
ISR의 특징
- 짧고 빠르게 실행되어야 함 (긴 작업을 하면 시스템 성능 저하 가능)
- 운영체제에 따라 우선순위가 높은 ISR이 먼저 실행될 수 있음
- 실행 중에는 일반적으로 다른 인터럽트를 차단(disable)하여 중첩 실행을 방지
ISR 예시 (C 코드)
마이크로컨트롤러(MCU)에서 타이머 인터럽트가 발생했을 때 실행되는 ISR의 예시
#include <avr/interrupt.h>
ISR(TIMER1_OVF_vect) {
// 타이머 오버플로우 발생 시 실행될 코드
PORTB ^= (1 << PB0); // LED 토글
}
int main() {
DDRB |= (1 << PB0); // PB0를 출력 모드로 설정
TIMSK1 |= (1 << TOIE1); // 타이머1 오버플로우 인터럽트 활성화
sei(); // 전역 인터럽트 활성화
while(1) {
// 메인 루프 (ISR이 실행될 동안 대기)
}
}
위 코드에서 ISR(TIMER1_OVF_vect) 함수는 타이머1의 오버플로우 인터럽트 발생 시 실행
ISR이 중요한 이유
- 멀티태스킹 및 실시간 처리
- 키보드 입력, 마우스 클릭, 네트워크 패킷 수신 등 다양한 작업을 빠르게 처리
- CPU 자원 절약
- 폴링 방식보다 효율적 (CPU가 불필요한 대기 작업을 하지 않음)
- 우선순위 기반 인터럽트 처리
- 긴급한 작업(예: 하드웨어 오류 감지, 네트워크 데이터 수신 등)을 빠르게 대응
인터럽트 백터 테이블 (Interrupt Vector Table, IVT)
- CPU에 존재
- 여러가지 인터럽트에 대해 해당 인터럽트 발생 시 처리해야할 루틴의 주소를 보관하고 있는 테이블
- 인터럽트 벡터 테이블에서 발생한 인터럽트를 검사한 후, 해당하는 인터럽트 서비스를 실행
인터럽트 백터
CPU가 수 많은 서비스 루틴을 구분하기 위해 사용하는 벡터이다. 인터럽트 백터를 알면 인터럽트 서비스 루틴의 시작 주소를 알 수 있다.
컴퓨터 구조와 하드웨어 구성
- CPU와 Main Memory 연결
- Memory Bus에 의한 연결
- 고성능 장치들을 CPU에 가깝게 배치
- 느린 장치들은 주변 장치 I/O 버스에 연결하도록 배치
하드웨어 장치
- 하드웨어 인터페이스 (Interface)
- 인터페이스를 통해 시스템 소프트웨어가 동작을 제어할 수 있도록 한다.
- 하드웨어 장치들은 특정한 상호 동작을 위한 방식과 명시적인 인터페이스를 가진다.
- 레지스터 구성
- 상태(state) : 하드웨어 장치의 현재 상태를 읽을 수 있는 레지스터
- 명령(command) : 하드웨어 장치가 특정 동작을 하도록 요청할 때 사용
- 데이터(data) : 하드웨어 장치에 데이터를 주고 받을 때 사용
- 내부 구조 (Internals)
- 시스템에게 제공하는 장치에 대한 추상화 정의
Poling
- 하드웨어의 변화를 지속적으로 읽어드리며 이벤트의 수행 여부를 주기적으로 검사하여 해당 신호를 받았을 때 이벤트를 실행한다.
- 하드웨어 장치의 상태를 수시로 체크하여 명령을 받을 수 있는지 확인하는 것
동작 방식
- 운영체제와 하드웨어 간의 상호작용 : 운영체제가 하드웨어 장치 상태 확인
- 하드웨어 장치의 상태 레지스터(Status Register) 를 주기적으로 읽어서 입출력 장치가 준비되었는지(ready 상태인지) 확인
- 데이터 전달 및 명령 기록
- 하드웨어가 준비되었다면, 운영체제는 데이터 레지스터(Data Register) 에 데이터를 (하드웨어에) 전달
- 이후 명령 레지스터(Command Register) 에 명령을 기록(저장x)하여 하드웨어에 작업 수행을 요청 (os → hw)
- 폴링 반복문 실행
- 운영체제는 폴링 루프(Polling Loop) 를 실행하며 하드웨어 장치의 상태 레지스터를 계속 확인
- 작업 완료 여부 확인
- 하드웨어 장치가 요청된 동작을 처리했는지 계속 확인
- 작업이 끝나면 하드웨어 장치는 성공/실패 코드(Status Code) 를 상태 레지스터에 기록
- 결과 처리
- 운영체제가 상태 레지스터를 읽어 작업이 성공했는지 확인
- 실패했다면 다시 명령을 보내거나 오류를 처리
특징
- 폴링 동안 다른 프로세스에게 CPU를 양도하지 않고 하드웨어 장치가 동작을 완료하는 동안 계속 루프를 돌며 하드웨어 상태를 체크한다.
- 시스템 리소스를 많이 소모하기 때문에 다중 작업 환경에서는 비효율적이다.
- CPU의 많은 낭비 발생
- 특정 주기마다 계속 확인
- 시스템 리소스를 많이 소모
- 정확한 타이밍에 시그널이 들어왔는지 확인 불가
- 주기에 따른 오차 존재
- CPU가 깨어있을 때만 사용 가능
- 구현이 쉬움
- 우선순위를 동적으로 조절하기 쉬움
- CPU가 직접 일을 하기에 입출력 시간이 오래 걸림
vs. 하드웨어 측면에서의 인터럽트
1️⃣ 인터럽트 기반 처리
- CPU가 프로그램을 실행하는 도중 특정 하드웨어 장치에서 처리 요청이 발생하면, 인터럽트를 통해 CPU에 이를 알린다.
- 운영체제는 해당 I/O 요청을 한 프로세스를 Block(대기 상태)로 전환하여 불필요한 CPU 점유를 방지
- CPU는 대기 중인 다른 프로세스를 실행하여 CPU 자원을 효율적으로 사용
- 인터럽트가 발생하면, CPU는 실행 중인 작업을 멈추고 인터럽트 서비스 루틴(ISR)을 실행하여 요청을 처리
2️⃣ 폴링 기반 처리
- 운영체제가 주기적으로 하드웨어 장치의 상태를 확인하여 I/O 요청이 있는지 검사
- CPU가 직접 장치의 상태를 반복적으로 확인하므로 CPU 리소스 낭비 발생
- 특정 장치에서 요청이 발생하지 않더라도 CPU가 지속적으로 폴링을 수행해야 하므로 비효율적
- 하지만 고속 I/O 장치에서는 폴링이 인터럽트보다 빠를 수 있음 (Context Switching 오버헤드 없음)
3️⃣ 비교 및 결론
- 인터럽트 방식: CPU 연산과 I/O 처리를 동시에 수행 가능 → 효율적인 멀티태스킹
- 폴링 방식: 빠른 응답이 필요한 고속 하드웨어 장치에는 더 효과적일 수 있다. (예: 짧은 대기 시간이 중요한 경우)
- 폴링은 CPU가 지속적으로 확인해야 하므로 리소스 낭비가 심함, 반면 인터럽트는 필요할 때만 CPU 개입
📌 요약
✅ CPU와 I/O 장치 작업을 효율적으로 분배하려면 인터럽트 방식이 일반적으로 유리
✅ 다만, 고속 장치에서는 폴링 방식이 더 적합할 수도 있다. (Context Switching 오버헤드 제거)
- CPU가 프로그램을 실행하는 중 특별한 처리가 필요한 경우 CPU에 알려 이를 처리
- CPU를 다른 프로세스에게 양도
- 하드웨어 인터럽트 발생
- 폴링보다 높은 CPU 사용률 → CPU 연산과 I/O 장치 작업을 중첩시켜 수행 가능
- Context Switching 발생 → 빠른 하드웨어 장치일 경우 폴링이 더욱 효과적
reference
https://github.com/jmxx219/CS-Study/blob/main/operating-system/Interrupt.md
CS-Study/operating-system/Interrupt.md at main · jmxx219/CS-Study
Computer Science && Tech Interview . Contribute to jmxx219/CS-Study development by creating an account on GitHub.
github.com
'운영체제' 카테고리의 다른 글
[OS] 메모리 관리 기법 ( Paging & Segmentation ) (0) | 2025.03.12 |
---|---|
[운영체제] Context Switching (문맥 교환) (0) | 2025.02.24 |
[운영체제] PCB (Process Control Block) (1) | 2025.02.24 |
[운영체제] 현재 컴퓨터의 발전 변천사 (프로세스와 스레드) (0) | 2025.02.12 |
[운영체제] Swapping : Mechanisms (0) | 2025.02.10 |