실시간 운영 체제

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

(RTOS에서 넘어옴)

이 문서는 편집 지침에 맞춰 다듬어야 합니다. 이 문서를 정리해 주세요.

실시간 운영 체제(Real Time Operating System 또는 RTOS)는 실시간 응용 프로그램을 위해 개발되어 온 운영 체제이다. 전형적으로 이러한 운영체제는 임베디드 응용 프로그램에서 쓰인다.

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

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

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

[편집] 설계 철학

두 가지 기본적인 설계 철학

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

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

[편집] 스케줄링

전통적인 설계 방식에서, 태스크는 수행, 준비, 블록의 세 가지 상태(state)를 갖는다. 대부분의 작업들이 거의 항상 블록된 상태로 있고, 특정 시간에 한 CPU마다 하나의 태스크만이 수행되고 있다. 준비 목록은 대개 짧으며, 많으면 2~3개의 태스크만이 등록된다.

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

플라이백 타임(flyback time)이라고도 불리는 긴급 응답 시간은 새로운 준비(ready) 상태의 작업을 대기열(queue)에 집어 넣고 가장 높은 우선 순위(priority)를 가진 작업의 상태를 복구하는 데까지 걸리는 시간이다. 잘 설계된 RTOS는 새로운 작업을 준비 상태로 만드는데 준비 대기열 항목마다 3-20개의 명령어를 사용하며, 가장 높은 우선순위를 가진 태스크의 상태를 복구하는데 5-30개의 명령어를 사용한다. 20MHz로 동작하는 68000 프로세서의 경우 태스크 전환 시간은 2개의 준비 상태의 작업에서 20ms 정도 걸린다. 100 MIPS의 ARM CPU는 전환 시간이 수 ms 정도이다. 새로운 구조가 현재 꾸준히 개발되고 있다.

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

다중 작업 시스템들이 해결해야 하는 단 한 개의 멀티태스크 문제는, (다수의 태스크들이) 동시에 같은 데이터 또는 하드웨어를 사용할 수 없다는 것이다. 이러한 문제에 매우 훌륭히 대처 디자인은 다음과 같다:

세마포어 (semaphore)
뮤텍스 (mutex)
메시지 전달 (message passing)

세마포어는 잠기거나 풀려있다. 잠겨 있을 때 작업들의 대기는 세마포어(가 풀리기)를 기다린다. 세마포어 디자인들이 가지는 문제점들은 잘 알려져 있다: 우선 순위 역전과 교착 상태이다. 우선 순위 역전은, 높은 순위의 작업이 낮은 순위의 세마포어를 가지는 작업을 기다리는 상황이다. 대표적인 해결법은 세마포어를 가지는 작업이 최우선 순위가 되도록 하는 것이다. 교착에서는, 두 개의 작업이 두 개의 세마포어를 역순으로 잠근다. 이것은 대개 대기열을 구현할 때 면밀하게 설계하거나 또는 floored semaphores(정해진 상황에서 세마포어의 제어권을 높은 순위의 작업에 넘기는)를 추가함으로써 해결된다.

다른 해결책은 작업들이 서로 메시지를 주고 받게 하는 것이다. 이것 또한 똑같은 문제점들을 안고 있다: 작업이 낮은 우선순위의 메시지를 수행하느라 in-box에 있는 더 높은 순위의 메시지를 무시할 때 우선순위 역전이 일어난다. 두 개의 작업이 서로 상대방의 응답을 기다릴 때 교착이 일어난다.

실시간 동작은 세마포어 시스템의 경우보다는 덜 분명하지만, 메시지 기반 시스템들은 자체적으로는 고정적이지 않아 일반적으로 세마포어 시스템들 보다는 더 잘 동작한다.

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

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에서 가장 중요한 문제이다.

첫째로, 할당 속도가 중요하다. 표준 메모리 할당 계획은 확실하지 않은 길이의 링크 목록을 검사하여 남아 있는 올바른 메모리 블록을 찾는다. 그러나 메모리 할당이 RTOS 안에서 정해진 시간 안에 일어나야 한다면 받아들여지지 않는다.

둘째로, 메모리는 사용할 수 있는 영역이 사용 중인 영역에 의해 분리됨에 따라 조각이 날 수 있다. 이론적으로 충분히 사용할 수 있는 메모리가 있다 해도 프로그램을 멈추게 하여 메모리를 가져 올 수 없게 한다. 조각을 천천히 내는 메모리 할당 알고리즘들은 달마다 다시 시동이 되면 데스크톱 컴퓨터에서는 제대로 동작한다. 그러나 다시 시동을 하지 않고 여러 해 동안 임베디드 시스템을 구동한다면 받아들여지지 않는다.

단순한 "고정 크기 블록들" 알고리즘은 놀랍게도 단순한 임베디드 시스템에서 잘 동작한다.

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

[편집] 임베디드 시스템의 메모리 사용

몇몇의 RTOS(임베디드 운영체제)는 XIP (즉석에서 실행)를 지원한다. 커널과 응용 프로그램들이 코드를 RAM으로 먼저 전송하지 않고 ROM에서 직접 실행된다. 운영 체제의 필요한 RAM 크기와 ROM 크기 사이의 교환을 제공한다. [1]

[편집] 다양한 RTOS들

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

[편집] 관련 인용구

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

— 익명의 질문

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

— 칼 자마