하드웨어 및 소프트웨어 인터럽트 흐름에서 대기열은 어떻게 처리됩니까? 보다 정확하게는 다음과 같은 질문이 있습니다.
시나리오를 가정해 보겠습니다. CPU가 2개인 컴퓨터가 있습니다. CPU1은 프로세스 P1을 처리하고 CPU2는 프로세스 P2를 처리합니다. 프로세스 P3이 실행을 기다리고 있습니다. 이제 CPU1은 하드웨어 인터럽트(I1)를 얻습니다. 따라서 CPU1 컨텍스트는 I1의 ISR(인터럽트 서비스 루틴)로 전환됩니다.
참고: 인터럽트의 하위 절반을 무시하고 모든 인터럽트를 상위 절반만 간주할 수 있습니다.
- I1의 인터럽트 처리가 완료된 후. P1을 다시 배치하는 것이 보장됩니까, 아니면 P3를 배치할 기회가 있습니까?
- CPU2가 유휴 상태인 경우 프로세스 P1(하드웨어 인터럽트로 인해 CPU1에서 제거됨)이 CPU2를 차지합니까?
- I1의 인터럽트 핸들러가 인터럽트를 마스크하지 않으면 두 번째 인터럽트 I2는 어떻게 되나요? 대기열에 들어가면 누가 그 대기열을 기억할까요?
- I1의 인터럽트 핸들러가 모든 인터럽트를 마스크하면 두 번째 인터럽트 I2는 어떻게 되나요?
답변1
일반적으로 인터럽트 핸들러는 최대한 짧게 설계되며 실제 처리 코드는 프로세스와 유사한 컨텍스트에서 호출됩니다. 핸들러는 단순히 소스를 결정하고, 소프트웨어에 대기열 항목을 추가하고, 인터럽트 소스를 비활성화합니다. CPU가 인터럽트 처리에서 돌아오면 인터럽트 핸들러 큐가 먼저 처리된 다음 "현재" 프로세스가 재개됩니다.
대기열 평가 중에 호출된 핸들러는 어떤 프로세스가 "현재"인지 변경할 수 있습니다. 가장 확실한 예는 타임슬라이스가 만료되었음을 나타내는 타이머 인터럽트이지만 들어오는 이벤트는 우선 순위가 더 높은 프로세스를 실행 가능하게 만들어 예약할 수도 있습니다.
다중 프로세서 시스템에는 일반적으로 관련 CPU에만 라우팅되는 전용 타이머 IRQ가 있는 명시적인 인터럽트 라우팅이 있으며, 하드웨어 인터럽트에는 "선호" CPU(캐시 지역성 향상을 위해) 또는 로드 밸런싱 방법이 적용됩니다. 여기서 인터럽트 컨트롤러는 다음을 보장합니다. 할당됩니다.
하드웨어 관점에서 보면 인터럽트는 대기열에 추가되지 않고 항상 표시되므로 처리될 때까지 인터럽트를 다시 보낼 수 없습니다(따라서 속도가 너무 높으면 인터럽트 누락에 대한 하드웨어 제한이 없습니다). 그러나 운영 체제는 일반적으로 대기열을 유지합니다. 소프트웨어에 있으므로 "실제" IRQ 처리기에서 가능한 한 적은 시간을 소비합니다(그리고 소스당 하나의 인스턴스만 대기열에 넣을 수 있으므로 대기열의 길이는 제한됩니다).
따라서 하나의 특정 하드웨어 부분과 인터페이스하는 "하위" 핸들러는 다른 수신 인터럽트에 의해 중단될 수 있지만, 수행되는 작업은 두 번째 인터럽트를 대기열에 추가하는 것뿐입니다. 그런 다음 첫 번째 인터럽트의 하위 절반 핸들러가 재개되고 반환되면 두 번째 인터럽트의 하위 절반 핸들러가 호출되고 하위 절반 핸들러 큐가 비면 현재 사용자 공간 프로세스가 호출됩니다. 처형되다.
답변2
가지다아니요후속 프로세스가 실행되는지 확인하십시오. 인터럽트가 처리될 때마다 커널은 다음에 무엇을 예약할지 결정합니다(우선 순위가 높은 프로세스가 실행 가능해지고, 현재 프로세스의 우선 순위는 낮아지고, 다른 프로세스의 우선 순위는 올라갑니다...). 캐시된 콘텐츠는 어쨌든 삭제되므로 항상 실행 중인 프로세스를 다시 시작하는 것은 별 의미가 없습니다. 현재 일어나고 있는 일은 엄밀히 말하면 내부 커널 문제이며 사용된 정책은 경고 없이 변경될 수 있습니다.