Table of Contents

실시간 시스템, 실시간 운영체제, RTOS 등등 무수히 많이 들어본 말이다. 어느날 갑자기 'OS 와 RTOS 의 차이가 뭡니까?' 라고 누군가 묻는다면 뭐라고 대답해야 할까? 여기서는 기존의 사전적으로만 알고있고, 어찌보면 기본중에 기본일 것 같지만 어찌보면 가장 중요한 것들에 대해서 언급한다.
또한 Embedded 의 대명사격인 Linux 상에서 어떤 식으로 실시간을 보장하는지에 대해서 알아본다. 한빛미디어에서 나온 '임베디드 리눅스' 를 참고했다.

용어 정리

다음의 질문에 대해 답변을 생각해보자!!

  1. 빠른 CPU 는 실시간을 보증한다.
  2. 윈도우 CE, 임베디드 XP, 임베디드 리눅스는 실시간 운영체제이다.
  3. CPU 가 많을수록 실시간 처리에 유리하다.
  4. 실시간을 지원하는 운영체제에서 동작하는 응용 프로그램은 모두 실시간으로 동작한다.
  5. 스타크래프트와 디아블로와 같은 게임에는 실시간 소프트웨어 특성이 있다.
  6. 고가용성과 실시간은 유사한 개념이다.

꼭 반드시 정답이라고는 할 수 없지만, 책에 나온 정답은 아래와 같다.

  1. 어느 정도 도움은 되겠지만 CPU 만 빠르다고 실시간을 보증하기는 어렵다. 주변 장치와 운영체제, 운영체제에서 동작하는 응용 프로그램까지 조화롭게 움직여야 실시간을 보장할 수 있다.
  2. 윈도우 CE, 임베디드 XP 와 (실시간 확장이 없는) 임베디드 리눅스는 실시간 운영체제로 분류하기 어렵다.
  3. CPU 가 많으면 자원 공유에 따른 동기화와 관련있는 문제점이 발생하므로, 소프트웨어 실시간을 처리하도록 작성하기 어려운 부분도 생길 수 있다.
  4. 운영체제가 실시간으로 동작하더라도 잘못 작성한 응용 프로그램이 공든 탑을 망가뜨릴 수도 있다. 나사(NASA)에서 만든 화성 탐사선인 패스파인더에 실시간 운영체제인 VxWorks 를 탑재했지만, 소프트웨어 버그로 데드락이 걸리면서 잠시 작동을 멈춘 경우가 대표적인 예이다.
  5. 실시간 전략 게임이나 실시간 시뮬레이션 게임에서 말하는 실시간은 상호 대화성을 높인다는 개념이다. 따라서, 컴퓨터 공학에서 이야기하는 개념과는 다소 차이가 있다.
  6. 고가용성은 시스템이 어느 주기로 실패하는지, 실패할 경우 서비스 중단없이 얼마나 빨리 시스템을 복구할 수 있는지에 주안점을 두지만, 실시간은 주어진 시간 제한을 얼마나 충족시키는지에 주안점을 둔다.

역시 책에서 정의하고 있는 실시간 시스템은 다음과 같다.

'특정 반응에 대해 정해진 시간 내에 행동할 수 없을 때 문제가 발생하는 시스템을 실시간 시스템이라고 부른다. 즉, 실시간 시스템은 외부 자극에 대해 시간에 맞추어 예측 가능한 방식으로 반응해야 한다. 실시간 시스템은 계산이 정확해야 한다는 조건 이외에 결과를 산출하는 시간에 제한을 둔다는 점에서 일반 컴퓨터 시스템과 다르다. 여기서 시간은 고정된 값이 아니라 구축하는 시스템마다 큰 차이를 보일 수도 있다.'

이번에는 실시간 운영체제의 정의이다.

'주어진 특정 시간 내 인터럽트를 처리하도록 보장하는 운영체제로, 임베디드 시스템과 다른 시간에 영향을 받는 응용 프로그램이 하드웨어를 제어하기에 적합하다. 실시간 운영체제는 특정 제품이나 제품명이 아니라 운영체제 종류 중 하나이다.'

실시간 운영체제는 일반 운영체제에 하드웨어 부문 관련 시간적 제약 조건을 덧붙였다고 보면 틀림없다.
실시간 운영체제는 다음과 같은 요구 사항을 만족시켜야 한다.

  1. 우선순위가 높은 태스크는 언제나 우선순위가 낮은 태스크에 앞서 수행된다.
  2. 우선순위 뒤바뀜 현상(priority inversion) 은 지정 시간 내 풀려야 한다.
  3. 윤활유 구실을 하는 커널이 태스크 동작을 방해해서는 안된다.

리눅스가 실시간을 지원하기 어려운 이유

리눅스는 캐시에 크게 의존한다는 사실을 추가할 수도 있다. 캐시가 전체적인 성능을 향상시키지만 특정 시점에서 시스템에 부하를 걸 수도 있기 때문이다.

스케줄러

리눅스 스케줄러는 초기부터 지금까지 대화식과 배치 작업에 적절한 설계 방침을 고수한다. CPU 사용 패턴에 따라 프로세스의 우선순위를 동적으로 바꾸며, 동일한 우선순위 프로세스에 대해서는 시분할 방식으로 선점이 가능하게 만들어져 있다. 하지만 대화식 응용 프로그램에 대해서는 반응 속력을 빠르게 하면서도 우선 순위가 낮고 배경 작업으로 동작하는 응용 프로그램이 기아 상태가 되지 않도록 하는 스케줄링 정책은 고정적인 우선순위와 시간 간격을 유지해야 하는 실시간 프로세스에 적합하지 않다.

비선점형 커널 구조

일반적인 유닉스는 비선점형 커널 구조를 채택하고 있다. 그러므로 특정 프로세스가 시스템 호출이나 인터럽트와 같은 이유로 커널 내부로 진입한 경우에 작업이 끝나기 전까지 CPU 를 우선순위가 더 높은 프로세스에 양보할 방법이 없다.

실시간 리눅스

원칙적으로 리눅스를 실시간 운영체제라고 부를 수 없다. 앞서 언급한 실시간 운영체제가 갖춰야 하는 여러 요소가 부족하기 때문이다.
하지만 일부 단체와 회사가 노력한 결과 리눅스도 실시간 특성을 대폭 보강하는 단계에 이르렀다.
크게 커널 패치 방식과 서브 커널 방식으로 나눌 수 있다.

커널 패치 방식

리눅스 커널에 패치를 가해서 실시간을 지원하는 방법으로, 다중 CPU 를 지원하는 커널을 변경해 실시간 요건을 충족시킨다. 몬타비스타가 대표적인 예이다.

서브 커널 방식

실시간 커널을 별도로 작성한 다음 여기에서 우선순위가 가장 낮은 스레드로 리눅스를 돌리는 방법으로, 소규모 실시간 커널이 하드웨어 인터럽트를 처리하는 가상머신으로 동작하고 리눅스는 이 가상머신 위에서 응용 프로그램으로 동작한다. 실시간을 처리하는 부문은 소규모 실시간 커널 위에서 바로 돌아가는 응용 프로그램이라고 생각하면 된다. RTLinux 가 대표적인 예이다.

특정 실시간 지원 방법 커널 패치 방식 서브 커널 방식
리눅스 고유 API 지원 실시간에서도 완벽하게 지원 실시간을 위해서는 별도 API 사용
포직스 API 지원 리눅스 커널 지원 의존 포직스 1003.13/PSE51 호환
보호 모드 지원 완벽하게 지원 커널과 동일한 메모리 주소를 사용하므로 미흡
응용프로그램과 연결 방법 리눅스 자체 IPC 제한적인 IPC
하드 실시간 지원 커널 부하가 커질 경우 미흡 적합(대신 응용 프로그램 부하가 커질 경우 리눅스 스레드쪽에 지장이 온다)
실시간 응용 프로그램 모델 일반 프로그램 장치 드라이버