인터럽트 지연과 전체 내용 요약 (핵심)

 

[인터럽트 지연]

 

인터럽트는 시스템으로부터 좀 더 나은 응답을 얻어내려는 수단이고, 임베디드 시스템에서 응답 속도는 언제나 중요한 문제이기 때문에, 내 시스템은 각각의 인터럽트에 대해 얼마나 빠르게 응답할지 고민하는 것은 굉징히 중요합니다. 이 고민에 대한 답은 몇 가지 요인에 의해서 결정되죠.

 

하나. 해당하는 인터럽트가 금지되는 가장 긴 시간

둘. 해당하는 인터럽트보다 높은 우선 순위를 가진 인터럽트를 위한 인터럽트 루틴 수행 시간

셋. 마이크로프로세서가 수행하던 일을 멈추고, 인터럽트 루틴으로 점프하기 위해 필요한 준비 작업을 하고, 인터럽트 루틴의 명령어를 실행시키기 시작할 때까지의 시간

넷. 인터럽트 루틴이 컨택스트를 저장하고 나서 응답이라고 여겨지는 일들을 수행하는데 걸리는 시간

 

인터럽트 지연이라는 용어는 어떤 인터럽트에 대해서 시스템이 응답하는데 걸리는 시간의 양을 나타낼 때 사용합니다. 하지만, 많은 사람들이 이 시간을 계산할 때 위의 요인들을 서로 다른 방법으로 조합합니다. 여기서는 모든 요인을 포함시키려고 하지만, 인터럽트 지연이라는 용어는 매우 다양한 것들을 의미한다는 것을 알게 될 겁니다.

 

다음으로 중요한 부분은 어떻게 위에 나열된 네 가지에 관한 시간을 알 수 있느냐는 겁니다. 보통 세 번째에 대한 시간은 제조 회사가 제공한 마이크로프로세서 데이터 시트에서 얻을 수 있습니다. 다른 3가지는 두 가지 방법 중의 하나를 통해서 알 수 있습니다. 첫 번째는 코드를 작성하고 실행시간을 직접 측정하는 겁니다. 두 번째는 다양한 종류의 명령어의 개수를 세고, 각 종류 별로 수행 시간을 마이크로프로세서 데이터 시트에서 찾는 방법이 있습니다. 각 명령어의 수행 시간이 정해져 있고, 제조회사가 그에 대한 데이터를 제공할 수 있기 때문에, 두 번째 방법은 작은 마이크로프로세서에 더 적합합니다. 수행 시간을 빠르게 하기 위해서는 캐시를 사용하는 마이크로프로세서에게는 그다지 좋은 방법은 아니겠지요. 이러한 마이크로프로세서들에 있어서, 명령어의 수행 시간은 이 명령어가 캐시에 올라와 있는지 여부와 다른 알기 어려운 것들에 의해서 결정됩니다.

 

[인터럽트 루틴이 짧으면 좋은 이유]

 

그래서 위에 언급된 네 가지는 인터럽트 지연과 응답 시간을 결정합니다. 네 번째는 효율적인 코드를 작성해서 해결이 가능하지요. 하지만 이러한 테크닉은 임베디드 시스템이나 데스크톱이나 모두 똑같아서 여기서는 다루지 않겠습니다. 세 번째는 소프트웨어로는 어떻게 해 볼 도리가 없습니다. 짧은 인터럽트 루틴을 작성하는 것이 좋다는 것은 두 번째를 보면 이해가 되는 부분이죠. 인터럽트 루틴을 수행하는데 걸리는 시간은 동등하거나 더 낮은 우선순위를 갖는 다른 모든 인터럽트들의 응답을 느리게 합니다. 낮은 우선 순위의 인터럽트는 응답 시간이 상대적으로 덜 중요하기 때문에 낮은 우선 순위를 부여 받았겠지만, 그래도 높은 우선 순위 인터럽트를 위해서 낮은 순위의 인터럽트 루틴이 한없이 시간을 낭비되도록 허용하는 것은 아닙니다.

 

공장을 조정하는 시스템을 제작하고 있다고 생각해봅시다. 순조롭게 돌아가기 위해 시스템은 즉시 응답을 해줘야 하는 24개의 인터럽트를 매 초마다 받고 있습니다. 시스템은 가스 유출 감지기를 감시하고 가스가 유출됨이 감지되면 소방서에 전화로 알리고 공장은 감염 지역을 폐쇄해야 한다고 해보죠. 전기 스위치를 켜고 끄는 루틴이 가스 유출 감지기보다 먼저 작동된다면 심지어 폭발을 일으킬 수도 있기 때문에 다른 인터럽트 루틴이 먼저 주의를 끌게 하는 것은 좋은 생각이 아닙니다. 따라서 가스 유출을 다루는 인터럽트 루틴은 상대적으로 높은 우선순위를 가져야겠죠. 그러면서도 공장의 오염되지 않은 다른 지역은 계속 가동해야 하기 때문에 가스 유출을 처리하는 인터럽트 루틴은 너무 오래 시간을 끌면 안 됩니다. 슬슬 복잡하죠. 수행하는데 적어도 몇 초 이상 걸리는 소방서에 전화를 거는 코드가 가스 유출 인터럽트 루틴에 포함되면, 이 코드가 수행되는 동안 수십 개의 인터럽트가 쌓이면서 다른 부분들은 제대로 동작하지 못하게 될 겁니다. 그러므로 전화를 거는 코드는 인터럽트 루틴에 첨가되면 안 된다는 결론에 도달합니다.

 

 

[인터럽트 금지하기]

 

인터럽트 지연에서 다루지 않은 것은 인터럽트 금지의 실행뿐입니다. 인터럽트를 금지시키는 것은 공유 데이터 문제를 해결하기 위해서 필요합니다. 하지만 금지되는 시간을 줄일수록 시스템의 응답은 좋아지게 된다는 긍정적인 부작용이 있죠.

 

인터럽트 금지는 인터럽트 지연을 증가시킨다는 점 때문에 공유 데이터 문제를 해결할 수 있는 다른 몇 가지 대안을 알고 있을 필요가 있다는 것을 알고 있어야 합니다.

 

 

 

[인터럽트 핵심 총정리]

 

• 어셈블리 언어의 특징은 아래와 같음
• C와는 다르게, 각각의 명령어는 하나의 마이크로프로세서 명령어로 번역됨
• 어떤 명령어들이 메모리로부터 마이크로프로세서 안의 레지스터로 데이터를 이동시키면 다른 명령어들은 레지스터의 데이터에 어떤 연산을 수행하고, 또 다른 명령어들은 데이터를 레지스터로부터 메모리로 이동시킴
• 일반적인 어셈블리 언어는 분기 명령어와 조건 분기 명령어, 호출과 리턴 명령어, 그리고 데이터를 메모리에 있는 스택에 넣거나 빼는 명령어를 가지고 있음
• 마이크로프로세서의 인터럽트 요구 핀 중의 하나를 활성화시켜서 서비스를 받으려는 I/O 장치가 마이크로프로세서에게 신호를 보낼 때, 마이크로프로세서는 하던 일을 중단하고, 관련된 인터럽트 루틴을 수행한 후에 다시 작업 코드로 복귀해서 하던 일을 계속 수행함
• 인터럽트 루틴은 반드시 콘텍스트를 저장하고 복원해야만 함
• 마이크로프로세서는 소프트웨어가 중대한 작업을 하고 있을 때, 소프트웨어가 인터럽트(논 마스 커블 제외)를 금지시킬 수 있도록 허용함
• 인터럽트 루틴과 작업 코드가 데이터를 공유할 때, 이 두 코드가 서로를 간섭하지 않도록 해야만 함, 이를 해결하는 첫 번째는 작업 코드가 공유 데이터를 사용할 때 인터럽트를 금지시키는 것임
• 시스템이 정확히 동작하기 위해서 인터럽트가 걸리지 말아야 하는 명령어들의 묶음을 크리티컬 섹션이라고 부름. 인터럽트가 걸리지 않을 명령어의 묶음을 아토믹 되었다고 함
• C에서는 어떤 구문도 아토믹이라고 임의로 가정하는 일은 없어야 함
• volatile 키워드는 컴파일러에게 인터럽트 루틴이 그 변수의 값을 바꿀 수 있기 때문에 컴파일러가 최적화를 하게 되면 문제가 될 수도 있다는 것을 경고함
• 인터럽트 지연은 시스템이 어떤 인터럽트 대해서 응답하는데 걸리는 시간. 몇몇 요인들이 이러한 시간에 영향을 미침. 인터럽트 지연을 최소화하고 시스템의 응답성을 개선하려면 두 가지를 해야 함

1. 인터럽트 루틴을 짧게 만들어라
2. 짧은 순간 동안만 인터럽트를 금지시켜라

• 인터럽트를 금지시키는 대신 사용할 수 있는 테크닉도 있지만, 그러한 테크닉 들은 매우 섬세하기 때문에 꼭 필요한 순간에만 사용해야 함