실시간 운영 체제

위키백과 ― 우리 모두의 백과사전.

실시간 운영 체제(Real Time Operating System 또는 RTOS)는 실시간 어플리케이션을 위해 개발돼온 운영 체제이다. 전형적으로 이러한 운영체제는 임베디드 어플리케이션에서 사용된다.

이러한 타입의 운영 체제가 반드시 높은 처리율(throughput)을 가지지는 않는다. 즉 특성화된 스케줄링 알고리즘과 높은 클록 대 인터럽트 비율(high clock-interrupt rate)은 둘 다 처리율에 방해가 된다. (역자 주, RTOS의 스케줄링 알고리즘이나 잦은 인터럽트가 처리율을 낮게 한다는 의미) 그러므로 실제 운영체제 없이 시스템을 운영하는 것이 처리율 면에서는 가장 유리할 수 있다.

큰 스케일을 가진 실시간 운영체제의 초기 예는 일명 "제어 프로그램"이었는데, 이는 아메리칸 에어라인(American Airlines)과 IBM이 사브레(Sabre) 항공 예약 시스템을 위해서 개발한 것이었다.

그러면 무엇이 실시간의 개념을 구성하고 있는지에 대해 논의해 보자.

목차

[편집] 설계 철학

두가지 기본적인 설계 철학

  • 이벤트 구동 방식(event-driven)의 운영체제에서는 특정 이벤트가 서비스를 요청할 때만 변화가 발생한다.
  • CPU 시간을 나누어 처리하는(time-sharing) 설계는 타이밍 인터럽트 또는 이벤트가 발생했을 때, 작업 중인 태스크에서 다른 태스크로 CPU를 스위치한다.

시간을 나누어 처리하는 방식의 설계일 경우, 불필요한 태스크 간 전환으로 CPU 시간을 더 많이 낭비한다. 그러나 그럼에도 불구하고 이러한 방식이 보다 나은 멀티태스킹 방식처럼 보일 수 있다.

[편집] 스케줄링

전통적인 설계방식에서, 태스크는 수행, 준비, 블록의 세 가지 상태(state)를 갖는다. 대부분의 태스크들이 거의 항상 블록된 상태로 있고, 특정 시간에 한 CPU 당 하나의 태스크만이 수행되고 있다. 준비 리스트는 대개 짧으며, 최대 두 개 내지 세개의 태스크만이 등록되어 있다.

진정한 기술은 스케줄러를 설계하는 것이다. 대개 스케줄러 상의 준비 리스트 자료 구조는 검색과 삽입, 삭제에 있어 단지 매우 짧은 시간 동안의 인터럽트 잠금을 요구하도록 설계되어 있다. 이는 리스트 내의 다른 태스크들은 리스크가 검색되는 동안 비동기적으로 수행될 수 있음을 의미한다. 전통적으로 성공적인 스케줄링 모델은 준비된 태스크들을 이중 연결 리스트 형식으로 우선순위에 따라 정렬하는 방식이다. 이 방식은 검색에는 다소 시간이 걸리지만, 걸리는 시간은 유동적이지 않고 결정적(deterministic)이다. 대부분의 준비 리스트는 대개 두 세개 정도의 항목만을 가지고 있어, 일반적으로 순차 검색이 가장 빠른 방식이다. 왜냐하면 순차 검색에는 거의 준비 시간이 걸리지 않기 때문이다.

flyback time이라고도 불리우는 크리티컬 응답 시간은 새로운 준비(ready) 상태의 태스크를 큐 (queue)에 집어 넣고 가장 높은 우선순위 (priority)를 가진 태스크의 상태를 복구하는데까지 걸리는 시간이다. 잘 디자인된 RTOS는 새로운 태스크를 준비 상태로 만드는데 준비 큐 엔트리 당 3-20개의 명령어를 사용하며, 가장 높은 우선순위를 가진 태스크의 상태를 복구하는데 5-30개의 명령어를 사용한다. 20MHz로 동작하는 68000 프로세서의 경우 태스크 전환 시간은 2개의 준비 상태의 태스크에서 20ms 정도 걸린다. 100 MIPS의 ARM CPU는 전환시간이 수 ms 정도이다. 새로운 구조가 현재 계속 개발되고 있다.

[편집] 태스크 상호간의 인터페이스

The only multitasking problem that multitasked systems have to solve is that they cannot use the same data or hardware at the same time. There are two notably successful designs for coping with this problem:

A semaphore is either locked, or unlocked. When locked a queue of tasks wait for the semaphore. Problems with semaphore designs are well known: priority inversion and deadlocks. In priority inversion, a high priority task waits because a low priority task has a semaphore. A typical solution is to have the task that has a semaphore run at the priority of the highest waiting task. In a deadlock, two tasks lock two semaphores, but in the opposite order. This is usually solved by careful design, implementing queues, or by having floored semaphores (which pass control of a semaphore to the higher priority task on defined conditions).

The other solution is to have tasks send messages to each other. These have exactly the same problems: Priority inversion occurs when a task is working on a low-priority message, and ignores a higher-priority message in its in-box. Deadlocks happen when two tasks wait for the other to respond.

Although their real-time behavior is less crisp than semaphore systems, message-based systems usually unstick themselves, and are generally better-behaved than semaphore systems.

[편집] 스케줄러로의 인터럽트 인터페이스

Typically, the interrupt does a few things that it must do to keep the electronics happy, then it unlocks a semaphore blocking a driver task, or sends a message to a waiting driver task.

[편집] 메모리 할당

메모리 할당의 문제는 다른 운영체계에 비해 RTOS에서 가장 중요한 문제이다.

Firstly, speed of allocation is important. A standard memory allocation scheme scans a linked list of indeterminate length to find a suitable free memory block; however, this is unacceptable as memory allocation has to occur in a fixed time in a RTOS.

Secondly, memory can become fragmented as free regions become separated by regions that are in use. This can cause a program to stall, unable to get memory, even though there is theoretically enough available. Memory allocation algorithms that slowly accumulate fragmentation may work fine for desktop machines—when rebooted every month or so—but are unacceptable for embedded systems that often run for years without rebooting.

The simple "fixed-size-blocks" algorithm works astonishingly well for simple embedded systems.

좀더 자세한 내용은 메모리 할당을 참조.

[편집] Use of memory in deeply embedded systems

Some RTOSes (or embedded OSes) support XIP (Execute In Place) where the kernel and applications are executed directly from ROM instead of transferring the code to RAM first. This offers a trade-off between the required RAM size and ROM size of the OS. [1]

[편집] 알려진 RTOS들의 예

많은 회사들이 리눅스에 실시간 기능을 가미한 버전을 판매하고 있다. 2004년 10월 8일 몬타비스타는 리눅스 커널 메일링 리스트를 통해 리눅스에 실시간 성능을 향상하기 위한 실시간 패치를 공개했다.

[편집] 관련 인용구

  • "실시간 작업에 대한 심각한 고민을 하고 있다면, 왜 운영체제를 고려해야 합니까?"

— 익명의 질문

  • 답변: 좀더 복잡한 시스템을 만들면서, 최악의 작업 결과에 대한 위험 보장을 하고자 한다면, 일종의 프레임워크를 갖추어야 하며, 그것이 운영체제이다!

— 칼 자마