Polling으로 인터럽트 우선순위를 판별하는 방식

CPU가 장치를 직접 확인하는 인터럽트 식별 방식

여러 장치가 인터럽트를 요청할 수 있는 환경에서는 어떤 요청을 먼저 처리할지 정해야 한다. Polling은 CPU가 각 장치의 상태를 순서대로 읽어 인터럽트 발생 여부를 찾는 소프트웨어 기반 방식이다.

이 순서는 단순한 탐색 절차가 아니라 우선순위 정책이기도 하다. 먼저 검사하는 장치가 먼저 서비스되므로, 별도의 복잡한 인터럽트 컨트롤러 없이도 우선순위를 구현할 수 있다. 대신 인터럽트가 없거나 낮은 우선순위 장치에 요청이 있을 때도 CPU가 검사 비용을 부담한다.

Polling은 다음 역할을 맡는다.

• 여러 장치 가운데 인터럽트를 요청한 장치를 식별한다.
• 장치 검사 순서로 처리 우선순위를 정한다.
• 우선순위 정책을 소프트웨어에서 변경할 수 있다.
• 복잡한 인터럽트 컨트롤러 없이 단순한 회로와 저비용 시스템을 구성할 수 있다.

⤢✕

인터럽트 요청을 찾은 뒤 ISR로 넘기는 흐름

CPU가 인터럽트 신호를 받으면 현재 작업을 일시 중지하고 폴링 루틴을 실행한다. 이 루틴은 높은 우선순위 장치부터 상태 레지스터와 인터럽트 플래그를 확인한다.

플래그가 설정된 장치를 찾으면 해당 장치의 ISR을 호출하고, 플래그를 클리어한 뒤 원래 작업으로 돌아간다. 요청이 발견되는 순간 검사를 멈추므로, 뒤쪽 장치는 앞선 장치에 요청이 있을 때 검사하지 않는다.

interrupt_handler() {
    // 우선순위 순서대로 장치 검사
    if (device_1.interrupt_flag == 1) {
        device_1_ISR();
        device_1.interrupt_flag = 0;
        return;
    }
    if (device_2.interrupt_flag == 1) {
        device_2_ISR();
        device_2.interrupt_flag = 0;
        return;
    }
    if (device_3.interrupt_flag == 1) {
        device_3_ISR();
        device_3.interrupt_flag = 0;
        return;
    }
    // ... 모든 장치 검사
}

예를 들어 타이머, 네트워크 카드, 디스크 컨트롤러, 키보드, 마우스 순으로 검사한다면 타이머가 최고 우선순위이고 마우스가 최저 우선순위가 된다. 코드의 검사 순서를 바꾸는 것만으로 우선순위 정책을 조정할 수 있다.

⤢✕

단순한 하드웨어와 순차 검사의 비용

Polling의 장점은 하드웨어와 구현의 단순성이다. 복잡한 인터럽트 컨트롤러 없이 구현할 수 있고, 회로 설계와 시스템 비용을 낮출 수 있다. 우선순위를 소프트웨어로 처리하므로 동적 조정이나 조건부 우선순위 같은 정책도 적용할 수 있으며 디버깅도 비교적 간단하다.

반면 CPU는 장치들을 순차적으로 검사해야 한다. 인터럽트가 없어도 검사 시간이 들고, 인터럽트 수가 늘어날수록 검사 시간은 급증할 수 있다. 마지막 장치까지 확인해야 하는 경우 응답 시간을 예측하기 어렵고, 낮은 우선순위 장치는 기아 상태에 놓일 수 있다.

주기적인 검사는 전력 측면에서도 부담이다. CPU가 장치 상태 확인을 위해 깨어나므로 저전력 모드 진입이 어려워지고 배터리 수명이 감소할 수 있다. 이런 특성 때문에 실시간 시스템에는 적합하지 않을 수 있다.

Interrupt-Driven I/O와 선택 기준

Polling에서는 CPU가 능동적으로 장치 상태를 확인한다. 장치 수가 적고 인터럽트 빈도가 낮으며 비용 제약이 있는 환경에 적합하다.

Interrupt-Driven I/O에서는 장치가 인터럽트 신호를 발생시키고 CPU가 이에 응답한다. 하드웨어가 장치를 식별하므로 인터럽트 컨트롤러가 필요하지만, 장치 수가 많고 인터럽트가 빈번한 고성능 환경에서는 CPU 효율을 높일 수 있다.

항목	Polling	Interrupt-Driven
장치 식별	CPU가 순차 검사	하드웨어가 자동 식별
CPU 부하	높음 (주기적 검사)	낮음 (이벤트 발생 시만)
하드웨어	단순	복잡 (인터럽트 컨트롤러)
응답 시간	예측 어려움	빠르고 예측 가능
비용	낮음	높음
확장성	낮음 (장치 증가 시 비효율)	높음

단순한 장치 환경과 하이브리드 구조에서의 활용

장치 수와 하드웨어 리소스가 제한된 마이크로컨트롤러에서는 Polling을 사용할 수 있다. 센서 데이터를 읽거나 버튼 입력을 확인하고 LED를 제어하는 경우가 여기에 해당한다.

인터럽트 컨트롤러가 없는 오래된 하드웨어에서도 기존 소프트웨어와의 호환성, 업그레이드 비용 때문에 Polling이 유지될 수 있다.

인터럽트와 Polling을 함께 쓰는 하이브리드 방식도 있다. 인터럽트로 이벤트를 감지한 다음 Polling으로 세부 장치를 식별하는 구조다. USB 컨트롤러에서 인터럽트 발생 후 장치를 확인하거나, 네트워크 카드에서 패킷 도착 인터럽트 후 Polling으로 패킷을 읽는 방식이 예시다.

저전력 환경에서는 긴 주기로 장치를 검사하고 대부분의 시간은 슬립 모드에 머무는 간헐적 Polling을 적용할 수 있다.

검사 비용을 줄이는 방법

인터럽트가 자주 발생하는 장치를 앞쪽에 두면 평균 검사 시간을 줄일 수 있다. 런타임에서 인터럽트 빈도를 측정해 검사 순서를 바꾸는 적응형 Polling도 가능하다.

장치별 상태를 1비트 플래그로 표현한 비트맵은 인터럽트가 없는 장치를 건너뛰는 데 쓸 수 있다.

bitmap = 0b00101000  // 장치 3, 5만 인터럽트
if (bitmap & 0b10000000) check_device_7();
if (bitmap & 0b01000000) check_device_6();
// ...

유사한 장치를 그룹으로 묶고 그룹별 대표 플래그를 두면, 먼저 그룹 플래그를 확인한 뒤 인터럽트가 있는 그룹만 세부 검사하는 2단계 Polling을 구성할 수 있다. 검사 횟수를 줄이는 방식이다.

검사 시간이 일정 시간을 넘으면 중단하는 타임아웃도 필요하다. 인터럽트 소스를 찾지 못하는 상태에서 무한 루프에 빠지는 일을 막고, 다른 작업이 실행될 수 있게 한다.