실시간 운영체제 RTOS::기본적인 정의,표준화 작업,Interface, Porting 방법,장점
3.1 RTOS 의 정의
실시간 시스템은 원격통신, 멀티미디어, 미사일 추적, 자동화 시스템, 산업용 로봇, 항공 제어 등의 여러 분야로 확대 응용되고 있다. 이 시스템의 정확성이 논리적 정확성뿐만 아니라 결과를 마감시간(Dead Line)에 맞추는 시간적 정확성이 크게 작용하는 시스템이다. RTOS(실시간 운영체제)에서 사용하는 실시간 스케줄링은 실시간 태스크가 마감시간에 맞추어 실행될 수 있도록 태스크를 프로세서에 할당하는 역할을 하며, 이는 실시간 RTOS에 시간적 정확성 제공하는 중요한 부분이다. 실시간 스케줄링 알고리즘은 선점가능(Preemptive)하고 동적인 우선순위를 가져야 한다. 정적인 우선순위(Static priorities)방법은 프로세서의 이용률과 긴급한 비주기 태스크의 처리에 대한 보장이 안 된다는 단점이 있다. 이 두 가지를 가진 스케줄링 알고리즘으로 최소 여유시간 우선Least Laxity First 알고리즘과 Earliest Deadline First 알고리즘이 있으며, Least Laxity First 알고리즘은 멀티프로세서에서 최적화되어 최고의 프로세서 사용률을 보인다. 최소 여유시간 우선(Least Laxity First) 스케줄링 알고리즘은 여유시간이 적은 테스크가 높은 우선순위를 갖는 동적 우선순위 스케줄링 방법이다 여유시간이란 태스크가 시간 t부터 선점 당하지 않는다고 가정하고 수행을 마쳤을 때 마감시간까지의 여분시간을 말한다.
Least Laxity First 스케줄링 알고리즘은 여유시간에 의해 태스크의 수행이 결정되고, 각각의 경우는 다음과 같다. 최소 여유시간인 태스크가 수행되며, 여유시간이 0이라면 이 태스크는 선점 당하지 않고 종료될 때까지 수행되어야 마감시간을 놓치지 않는다. 음수의 여유시간을 갖는 태스크는 마감시간보다 잔여 수행시간이 더 크므로 이미 마감시간을 보장할 수 없는 태스크이므로 수행되지 않는다. Least Laxity First의 단점은 스케줄링 알고리즘은 시간이 변함에 따라 많은 Context Switch가 일어나게 된다. 어느 시점에 최소 여유시간을 갖는 태스크가 두 개 이상 존재하게 되어 여유시간 충돌이 발생하면, 이 충돌된 태스크들은 스케줄링 시점마다 번갈아 수행되게 되고 결국 하나의 태스크가 종료되기 전까지 수많은 Context Switch가 일어나게 되는 단점이 있다. 이를 보완하기 위해 일정시간에서 여유시간 역전을 허용하는 방법, Context Switch의 Overhead를 줄이기 위해 많은 Register set을 갖는 방법이 있다.
RTOS에서 지원되는 기능들은 다음과 같다.
• run time library
• multi tasking
• inter-task communication
• socket/ streams network library
• Telnet, SNMP와 같은 응용 API
3.2 표준화 작업
이전의 real-time OS는 대개 특정 target application과 architecture platform을 위한 OS kernel이었다. 그래서 매우 많은 real-time OS가 생겼고 각 OS마다 차이가 생겼다. 최근 들어서 이를 표준화 하려는 작업이 진행 중인데 미국의 POSIX와 일본의 TRON이 있다.
3.2.1 POSIX
현재 PC에서는 대부분 Microsoft사의 OS(DOS, Windows 95)를 쓰고 있지만 workstation급 이상의 중대형 컴퓨터에서는 OS로서 대부분 UNIX를 쓰고 있다. UNIX는 AT&T의 Bell 연구소에서 근무하던 Ken Thompson, Dennis Ritchie와 몇몇 사람들이 Multics Project를 이어받아 만든 OS(Multics를 비꼬는 말)로서 C로 작성되어 이식성이 매우 높기 때문에 많은 시스템에 적용 되어 왔고 따라서 여러 가지 변종이 나타나게 되었다. 가장 대표적인 시스템은 Berkeley 대학에서 만든 BSD계열과 AT&T의 System V계열이 있다. 이처럼 많은 변종이 나타나면서 UNIX라는 이름을 갖는 OS들 사이에서도 점점 차이점이 나타나게 되었고 따라서 표준화하기 위한 일환으로써 POSIX(Portable Operating System Interface (X로 끝나는 이유는? 대부분의 OS가 X로 끝나니까))란 것이 제정되기에 이르렀다. POSIX의 목표는 응용 프로그램이 source code portability를 갖도록 하는 것이다.
POSIX중에서도 real-time OS에 대한 표준을 제정하기 위한 작업도 진행되어 있는데 이것이 POSIX 1003.4[3]이다. POSIX는 원래 미국에서 나온 것이기 때문에 미국에서 나오는 대부분의 real-time OS는 이POSIX를 따르거나 따르려는 계획을 가지고 있다. 그러나 아래에서 설명할 TRON project에 비하면 아직 초기 단계라 할 수 있다. 또한 POSIX의 시작이 UNIX를 표준화하는 것이었으므로 원래 real-time OS가 아니었던 것에 확장을 하는 개념이어서 문제를 안고 있는 실정이다.
3.2.2 TRON
TRON은 The Real-time Operating system Nucleus의 약자로서 1984년에 일본의 사카무라 박사를 중심으로 시작된 프로젝트이다. TRON 프로젝트는 real-time system에 대한 전체적인 표준을 제정하려는 노력이다. TRON에는ITRON, BTRON, CTRON, MTRON 등 몇 가지가 있다.[5]
Micro processor에 대한 표준은 µTRON으로서 이를 기준으로 하는 OS목록은 http://tron.um.u-tokyo.ac.jp/TRON/ITRON/home-e.html에 가면 있는데 살펴보면 제작 회사가 모두 일본으로 대부분 chip maker이다. 따라서 지원하는 프로세서 또한 자신들의 회사에서 만든 microprocessor이다. 즉 여기서 알 수 있듯이 이 표준의 단점이라면 일본 내부에서만 쓰이는 표준으로 미국에서는 표준으로 쓰지 않는다는 점이다. 그러나 POSIX에 비해 먼저 제정되어 이미 많은 제품이 나와 있다는 장점이 있으므로 설계하는 embedded system에서 일본 chip maker에서 만든 microprocessor를 쓰는 경우에는 고려해 볼 필요가 있는 표준이다.
3.3 RTOS Kernel 과 Interface
특정 OS만을 대상으로 프로그램을 작성한다면 OS에서 제공하는 함수를 직접 호출해도 무방하겠으나 만약 시스템을 upgrade하는 경우에 그 processor에 맞는 real-time OS가 원래 쓰던 OS와 다르다면 전체 시스템에서 이전 OS에서 쓰던 함수부분을 모두 고쳐야 할 것이다.
이런 경우에 대비해서 POSIX compliance라는 것이 있으나 POSIX라는 표준자체가 미흡한 점이 있어서 마땅한 표준이 없는 상태이다. 따라서 OS Kernel과 응용 프로그램사이에 interface를 두면 다른 시스템에 porting시에 효과적이다.
Kernel Interface
3.4 RTOS Porting
Real-time OS를 porting해줄 때 가장 중요한 것은 memory, interrupt, timer부분이다. 메모리는 원래 C프로그램을 작성할 때 잡아주는 부분에 real-time OS에 관련된 부분을 추가하는 것이다. 즉, real-time OS kernel이 쓸 stack을 잡아주는 것이다. C프로그램을 작성하는 경우에 분명히 그 프로그램은 code와 data로 나누어질 것이다. data영역은 또한 초기화 된 변수, 초기화 되지 않은 변수, 동적으로 사용되는 stack, heap등으로 나뉜다. 결국 이것들은 메모리에 저장되므로 메모리의 어느 부분에 code가 들어가고 어느 부분에 data가 들어갈지를 정해야 하는데 이는 link시에 결정된다.
이렇게 해서 link시에 stack영역이 확보가 되었다고 하면 stack을 다시 나누어 real-time OS kernel이 쓸 stack, 사용자들이 쓸 stack들로 나뉜다. porting시에 해줄 작업은 이중에서도 주로 stack에 관한 것이다. Nucleus PLUS의 경우에 따라오는 int.s파일에 보면 기본적으로 stack을 잡아두고 있는데 이 값을 조정할 필요가 있는 경우엔 사용자가 변경하면 된다.
두번째로 interrupt부분이다. Interrupt signal이 발생되면 processor마다 조금씩 다르겠지만 일단 processor로 interrupt가 발생한 경우 특정 번지로 jump하게 된다.(예를 들어서 INT_IRQ) 이 루틴에서는 interrupt의 source가 어디인지 판별하고 그에 해당하는 ISR로 다시 jump한다. 이 ISR을 LISR이라고 한다. LISR에서는 대개 단지 task만을 호출하고 끝난다. 이때 호출된 task를 HISR이라고 한다. HISR은 일반 task보다 priority가 높다는 것을 제외하고는 같게 수행된다.
일반적으로 Interrupt부분을 처리하기 위해서는 시스템에서 제공하는 interrupt controller를 정확히 이해하는 것이 바람직하다. 어느 interrupt가 edge-trigger인지 level-trigger 인지 결정하고 clear를 해줄 필요가 있는 것은 clear해주어야 한다는 것이다.
timer는 시스템에서 쓰는 timer마다 다르다. timer가 제대로 설치되지 않으면 OS에서 제공하는 함수 중에서 sleep이나 time slice등에 대한 함수가 작동되지 않는다. 간혹 timer interrupt가 발생한 후interrupt clear를 하지 않는 경우에도 문제를 일으킨다.
따라서 sleep함수가 제대로 작동되지 못한다면 timer interrupt의 설정이 잘못된 것이므로 다시 살펴봐야 한다.
3.5 RTOS의 장점.
RTOS는 정해진 시간 제약을 해결하는데 초점을 두고 있으나, General OS는 하드웨어 자원(메모리, I/O 디바이스, 하드디스크 등)을 얼마나 효율적으로 사용하고, 얼마나 공평하게 자원을 분배할 것인가에 초점을 두고 있다. RTOS 는 하드웨어 자원을 좀 낭비하더라도 작업의 시간제한을 맞추려 하고, 공평성의 개념보다는 우선순위가 높은 task 가 많은 시간 동안 동작을 수행할 수 있도록 조정해 줌으로서, 주어진 시간 내에 작업을 수행함. 특히 군사용의 미사일과 같이 처리 시간 내에 수행되어야 하는 부분에 장점을 가지고 있다.
제 4 장 RTOS 의 현황
본 장에서는 시간제약의 조건을 만족시켜야 하는 RTOS의 기본요구사항에 대한 현황을 작고 빠른 커널, 실시간 버전 확장 커널, 순수한 실시간 운영체제로 나누어 기술한다.[6]
4.1 작고 빠른 커널.
작고 빠른 커널은 오버헤드의 시간을 줄이고 시스템 동작을 빠르게 하기 위하여 다음과 같은 특성을 가지고 있다.
•빠른 문맥 교환(context switch)
•최소의 기능(functionality)
•외부 인터럽트 디스에이블 기간을 최소화
•메모리 고정 혹은 가변 분할
•빠르게 데이터를 저장하는 특수한 순차 파일.
그리고 시간 예측성을 얻기 위해 시분할 시스템을 최적화하기 위하여 다음과 같은 특성을 가지고 있다.
•프리미티브의 바운드된 실행 시간.
•실시간 클락
•우선순위 스케줄링 메커니즘.
•특수한 알람과 타임 아웃
•실시간 큐잉 정책
•일정 시간동안 처리를 지연하거나 재실행할 수 있는 프리미티브
이 그룹에는 QNX, pSOS, VxWorks, VRTX 가 있다.
4.1.1 QNX
1982년에 개발된 이후 QNX는 POSIX와 UNIX 호환 시스템 서비스를 지원하는 선택적 프로세스들로 둘러쌓인 실시간 미이크로 커널을 제공함으로서 실시간 성능과 개발 유연성, 그리고 네트워크 유연성을 기본적으로 요구하는 시스템에서 사용되어왔다.
분산, 실시간, 결함허용 을 위한 X86 운영체제인 QNX는 마이크로 커널 아키텍처와 삽입 실시간 시스템을 제공한다는 점에서 다른 운영체제에 비해 큰 장점을 갖고 있다.
QNX 마이크로 커널은 프로세스 스케쥴링, 프로세스간 통신, 인터럽트 핸들링 기능만을 제공한다. EK라서 마이크로 커널과 시스템 인터럽트 핸들러가 온칩 CPU 캐쉬에 적재 가능하도록 하여 프로세서는 마이크로 커널의 서비스를 많이 사용하는 응용에 대해 높은 성능을 제공 할 수 있다.
또한, ROM-기반 삽입 응용에 대해 OS의 모듈화는 개발자로 하여금 불필요한 시스템 프로세스를 생략할 수 있도록 해준다. 감소된 크기의 QNX 시스템은 POSIX 런타임 기능과 개발환경을 제공해주면서도 실시간 실행부와 거의 대등한 기능을 갖는다.
QNX 마이크로 커널
4.1.2 pSOS
실시간 구현 자에게 여러 하드웨어 플렛폼 상에서 사용할 수 있는 표준 빌딩블록(커널, 모니터, 디버거)을 제공하는 플러그-인 운영체제이다.
pSOS+는 삽입 설계를 위한 실시간 운영체제 커널 구성요소이며, pSOS의 슈퍼 셋 이다.
태스크들은 선점 우선순위-기반 스케줄링에 따라 스케줄 되며, tightly/loosely -coupled 멀티-프로세서를 지원한다.
4.1.3 VRTX(Versatile Real-Time Executive)
VRTX은 프로세서 제어, 지능 컴퓨터 주변 장치, 통신에서 사용하는 마이크로프로세서를 위해 1·981년에 설계, 구현한 실시간 운영체제이다. 이 구성요소는 LSI 하드웨어 구성요소처럼 구성요소 수정 없이 어떤 하드웨어 환경에서도 사용할 수 있는 특징을 가지고 있다. 그리고 실시간 데드라인과 병행 실행을 처리하기 위한 기반을 제공한다.
응용들이 VRTX 소프트웨어 구성요소를 사용하여 설계됨으로써 재사용 가능한 소프트웨어를 현실화하게 되었다. 삽입 컴퓨터 시스템에서 사용되는 소프트웨어는 정용 컴퓨터의 소프트웨어와 많은 유사한 면을 갖고 있으나, 소프트웨어에 대해 다음과 같은 부가적인 요구를 필요로 한다.
1) 병행 처리 요구
대부분의 삽입 시스템은 실시간 요구를 가지기 때문에 응답 시간 요구를 충족 시켜 주어야 한다. 또한, 태스크들이 병행적으로 처리되기 때문에 공유 자원에 대해 상호 배타적 접근을 보장해 주어야 한다.
그래서 VRTX는 실시간 성능 요구를 해결하기 위해 멀티-태스킹 기능을, 상호 배타적 접근을 위해 락킹 기법을 사용하고 있다.
2) 실시간과 병행 처리 제어를 위한 태스크 서비스
VRTX 스케줄러는 논리적 병행 처리를 수행하기 위해 태스크간에 실행을 인터리빙(interleaving)방식하고 있다. 그리고 가능한 가장 빠른 응답을 제공하기 위해 선점 우선순위-기반 스케줄링을 사용하고 있다.
3) 태스크간 상호배제, 시그널링, 통신 서비스
태스크는 mailbox 와 큐를 사용하여 스케줄러에게 이벤트를 알리고, 비 공유 자원에 대한 상호 배제(mutual exclusion)를 수행하고, 태스크간에 통신을 한다.
4) 메모리 서비스
실시간 멀티-캐스킹 요구에 근거한 동적 메모리 할당 기법을 지원하기 위해 VRTX는 고정-크기 블록으로 기억장소를 할당, 반납할 수 있는 자유 풀을 메모리 블록 안에 두고 있다.
4.1.4 VxWorks
VxWorks는 다양한 프로세서 상에서 복잡한 실시간과 삽입 응용을 위해 그리고 분산 환경에 사용하기 위해 설계된 네트워크화 된 실시간 운영체제이다. VxWorks는 다음과 같은 특징을 갖고 있다.
1) 다양항 산업 표준(ANSI C, TCP/IP)을 지원한다.
2) 개발 환경은 크로스-개발 혹은 리모트 개발 기법에 기반을 둔다.
3) 빠른 멀티-태스킹과 인터럽트를 지원한다.
4) 라운드 로빈 스케줄링을 지원한다.
5) 확장이 가능하다.
6) 실시간 응용 개발을 보다 신속히 수행할 수 있도록 Host tools와 Target tools를 제공한다.
4.2 실시간 버전 확장 커널
실시간 버전 확장 커널의 예로는 UNIX를 RT-UNIX로 POSIX를 RT-POSIX로,MACH를 RT-MACH로, 그리고 CHORUS를 실시간 버전으로 확장한 것들이 있다. 이러한 운영 체제들은 앞에서 언급한 작고, 빠른 전용커널에 비해 일반적으로 느리고, 예측성이 다소 떨어지지만 보다 많은 기능과 더 나은 소프트웨어 개발 환경을 제공한다. 또한 기존의 운영 체제의 표준 인터페이스를 그대로 사용함으로서 이식성이 좋다는 장점을 갖는다.
그러나 비 실시간 운영 체제를 실시간 운영체제로 전환하려 할 때 시스템 인터페이스뿐 아니라 구현상에 있어서 여러 가지 문제점이 존재 한다. 첫째로 시스템 인터페이스 상에서, UNIX의 경우 set priority 프리미티브와 라운드 로빈 스케줄링 정책을 사용하는데 이는 실시간 스케줄링을 하는데 문제가 발생한다. 또 정밀한 타이머를 제공하지 못하고, 메모리 관리에 있어서 페이지를 메모리로 락킹할 방법이 없고, 프로세스간 통신에서도 빠르고 예측할 수 있는 통신을 지원하지 않는 문제점을 가지고 있다.
둘째로 구현상에서, 더 이상 허용될 수 없는 오버헤드, 인터럽트 반응에 과도한 지연, 커널의 비선점성, 내부 큐의 FIFO 순서 등으로 인한 문제점이 존재 한다. 이들 문제점을 해결하는 것이 이들 확장 운영 체제의 목표이다.
4.2.1 RT-POSIX
실시간 운영체제에 관해 제안된 IEEE 표준 POSIX.4와 POSIX.4a는 IEEE 1003.4 워킹 그룹에 의해 현제도 진행 중에 있다. POSIX.4는 기본 실시간에 관해 스케줄링, 이진 세마포어, 메모리 락킹, 공유메모리, 비동기/동기 I/O, 확장된 UNIX 시그널, 메시지 전달, 클럭과 타이머, 실시간 파일레 대한 인터페이스로 세분화하여 규정하고 있다. POSIX.4a는 쓰레드 확장제안으로 POSIX.1 TM레드 제어, 상호 변수와 조건변수, 쓰레드 스케줄링, POSIX4.1와 POSIX.1 프로세스-기반 인터페이스들을 정의하고 있다.
POSIX.4 Draft는 다음과 같은 기능을 제공하고 있다.
1) 실시간 스케줄링 인터페이스와 스케줄러
POSIX.4는 확장성과 이식성을 위해 SCHED_FIFO, SCHED_RR, SCHED_0THER 3가지 정책을 갖고 있다. 특히, 실시간 스케줄링으로 정당치 않다고 생각되어 지는 FIFO와 RR를 실시간 시스템이 가장 많이 사용하는 스케줄링 정책으로 선택하고 있다. 그 외에도 POSIX.4는 SCHED-OTHREF를 갖고 있어 이식성이 없는 특별한 스케줄링 정책은 정의할 수 있는 수단을 제공하고 있다.
2) 실시간 확장된 시그널
POSIX.4의 주된 관심 중에 하나는 응용을 위해 제한된 시그널을 제공하는 것이다. 그래서 응용에 의해 사용되는 시그널을 약 8개로 제한했다. 데이터를 동반할 수도 있는 POSIX.4 시그널은 수신 프로세스 큐안에 도착 순서대로 저장 된다.
3) 타이머
버클리 UNIXSMS 실시간 응용이 일정 간격에 따라 오퍼레이션을 스케줄할 수 있도록 타이머를 제공 하지만 POSIX.1은 sleep()를 제외한 DJejS 시간 서비스를 제공하지 않는다. 그러나 POSIX.4는 버클리 타이머와 유사 하지만 기능성과 정밀도에서 보다 확장된 타이머를 제공한다.
4) 비동기 I/O와 동기 I/O
POSIX.4 비동기 I/O는 파일에 읽거나 쓰기를 하는 동안 호출된 프로세스는 다른 오퍼레이션과는 상관없이 존재한다. 그러나 POSIX.4 동기 I/O는 I/O와 관련된 물리적 매체로 전송된 후에야 복귀된다.
5) 공유 메모리
POSIX.4 공유 메모리는 하나 이상의 프로세스의 주소 공간에 대칭될 명명화된 저장 공간이다. 공유 메모리 창조에 대한 호출은 파일 기술자를 반환한다. 이파일 기술자는 고유 메모리 사이즈를 설정하거나 메모리에 실제로 대칭 할 건지에 대한 호출 안에서 사용된다.
6) 메세지 전달
POSIX.4는 프로세TM가 메시지를 서로 큐잉할 수 있고, 여러 방법으로 검색할 수 있으면서 크고, 복잡한 메시지 전달 기능을 제공한다.
7) 이진 세마포어
표준 UNIX는 여러 프로세스들의 동기화를 위해 시스템 V 세마포어와 파일 락킹 메커니즘을 제공하지만 니들은 실시간 응용에는 부적절하다. POSIX.4는 단순하고 효율적인 구현을 제공하는 이진 세마포어를 지원한다.
4.2.2 RT-MACH
RT-MACH는 MACH의 인터페이스를 변경하지 않고 실시간 오플리케이션을 위한 시스템 평션을 확장함으로서 예측가능하고 신뢰성 있는 분산 실시간 컴퓨팅 환경을 제공하도록 MACH를 실시간 버전으로 개발한 것으로 실시간 프로그램 설계와 분석을 위한 툴세트와 함께 실시간 쓰레드 모델, 통합된 실시간 쓰레드 스케줄러, 실시간 쓰레드 동기화, 프로세스간 통신의 실시간 특성뿐 아니라 보다 많은 예측성을 지원하는 메카니즘을 제공한다.
1) 실시간 쓰레드 모델
RT-MACH의 실시간 TM레드 모델은 예측 가능한 실시간 스케줄러를 지원하고, 실시간과 비실시간 쓰레드에 대한 일관된 시스템 인터페이스를 위해 비 실시간 쓰레드가 명세하지 않는 시간 속성을 정의 기술하는 시간 속성 기술자를 실시간 쓰레드에 첨가 하였다.실시간 쓰레드의 특성에 따라 경성 실시간 혹은 연성 실시간 쓰레드로 나누어 질 수 있는데 경성 쓰레드는 자신의 데드라인 시간 전에 실행을 종료해야 하는 쓰레드를 나타내고 연성 쓰레드는 그러한 제약이 없는 쓰레드를 나타낸다. 또한 그들이 발생하는 간격에 ek라 주기적 혹은 비주기적 쓰레드로도 정의된다.
2)실시간 동기화
전통적인 동기화 프리미티브는 임계 구역 내로 진입하려는 쓰레드간에 동기화를 위해 FIFO 큐를 이용한다. 이 FIFO 수서는 시분할 시스템에서 기아 상태를 피할 수 있는 장점을 갖고 있으나, 실시간 환경에서는 낮은 우선순위 쓰레드가 높은 우선순위 쓰레드를 블록 시키는 우선순위 반전문제를 야기 시킨다. 이는 결국 높은 우선순위 쓰레드가 최악의 블록킹 지연 시간 을 바운드 하지 못하므로 자신의 데드라인을 지키지 못한다. 그래서 이런 최악의 블록킹 지연 시간을 바운드하기 위해 우선 순위상속 체제가 제시되었다.
T1을 가장 높은 우선순위를 갖는 쓰레드 라하고, T2를 중간 우선순위, T3을 가장 낮은 우선순위를 작은 쓰레드라 할 때, T1과 T2이 MUTEX변수를 획득하고자 한다고 가정하면, 가장 낮은 우선순위 쓰레드 T3가 MUTEX변수를 얻은 후, 가장 높은 우선순위 쓰레드 T1가 mutex변수를 얻으려 시도할 때, T1은 입계 구역 내에 있으므로, T1은 T3가 종료하기를 기다리게 된다. 이때 임계 구역으로 진입하지 않는 중간 우선순위를 갖은 T2가 T3를 선점하려하면 기존의 방법은 T3가 T2에 의해 선점되어 T1은 T3와 T2가 종료되기를 기다려야 한다. 그러나 우선순위 상속 체제에서는 T3가 T1의 우선순위를 상속받으므로 T2에 의해 선점되지 않는다. 이로 인해 T1은 T3가 종료되기만을 기다리면 된다. 결국 최악의 블록킹 지연을 바운드 시켜준다.
• 동기화 모듈
시스템의 적응성을 개선하기 위해 동기화 기능은 정책과 메카니즘을 분리하여 생각한다. 각 동기화 정책 모듈은 객체로서 구현되어지며 정책 객체와 메카니즘간의 통신은 메시지 전달 방법이 아닌, 함수 호출을 통해 이루어진다
동기화 모듈은 공통 락 객체와 락 정책 객체로 나누어진다. 공통 락 객체는 쓰레드의 블록킹과 비 블록킹을 다루는 메카니즘을 제공하며 현재 프로세서 스케줄링 정책에 따라 락을 해제하기 위해 대기하고 있는 쓰레드 큐을 관리한다. 락 객체는 그와 관련된 락 정책객체를 호출한다. 락 객체에 대한 정책 오퍼레이션은 사용자로부터 시스템 호출을 통해 시작되며, 쓰레드는 블록킹 없이 이러한 오퍼레이션을 수행한다.
만일 쓰레드가 블록 당하는 겨우 쓰레드는 공통 락 객체로 되돌아간다.
동기화 모듈
3) 실시간 스케줄링
RT-MACH는 본래 ARTS kernel을 위해 개발되어진 통합된 시가-구동 스케줄러를 확장한 스케줄링 모델을 사용한다.
시스템 설계자로 하여금 주어진 태스크가 자신의 데드라인을 만족하고 있는지의 여부를 미리 예측할 수 있도록 허용하는 통합된 시가-구동 스케줄러는 경성과 연성 실시간 활동을 관리하는데 있어서의 예측성, 유연성, 수정가능성을 제공하는 데 목적을 두고 있다. 먼저 경성 좝에게 프로세서 사이클을 할당한 뒤, 남은 사이클을 연성 실시간 좝에게 할당하는 용량 보존 스킴을 사용하여 경성과 연성 실시간 쓰레드를 루고 있는 ITDS 스케줄러는 객체 모델과 층 구조를 이용하여 설계, 구현 되었다. 스케줄링 정책은 하나의 독립된 객체로 실제로 커널에서 쓰레드를 스위칭 하는 데 사용되는 메카니즘 층으로부터 분리되어 존재함으로써 가 프로세서 세트에 대한 각각의 다른 스케줄링 정책을 할당할 수 있다.
4) 타이머와 클락
현재 운영체제들은 시간의 경과에 따라 응용 프로그램 동기화를 이루는 서비스를 제공하고 있다. MACH 3.0은 host_get_time()과 mach_msg()에 대한 타임아웃 피라미터를 제공함으로 일반 목적응용에 대해 시간 서비스에 대한 충분한 기능을 가지는 반면, 보다 더 정밀한 정확도와 유연성을 요구하는 실시간 응용에는 부적합하다. 즉, 실시간 어플리케이션에 대해 타임 스템프, 정확함 지연, 주기적 시그널, 그리고 타임아웃 기능들이 요구 된다. 그러나 이러한 기능을 지원하는데 몇 가지 요구 사항이 존재한다. 첫째, 보다 높은 정확도를 가지고 시간을 측정해야 하며, 둘째로 사용자는 높은 정확도를 가진 타임소스를 가지고 동기화를 이루어야하며 마지막으로 타이밍 폴틀 혹은 시간적 정확도상 에러가 존재할 때 계산에 대한 수정을 할 수 있도록 스케줄링과 통합되어야 한다.
이러한 요구사항들에 대해 RT-MACH는 사용자에게 다양한 방법으로 시간에 대한 동기화를 이루게 하는 액티브한 객체인 타이머와, 시간의 경과를 측정하고, 정밀한 정확도로써 타이머를 사용하는 클럭을 제공함으로써 사용자에게 타임 서비스를 지원한다.
5) RT-IPC Model
프로세스간 통신은 확장가능하고 유연한 Mach 마이크로 커널을 위한 기본적인 메커니즘을 제공하는데, Mach IPC는 많은 시분할 어플리케이션을 위해 효율적이고 공정한 통신 메커니즘을 제공하고 있으나 쓰레드간의 엄격한 시간제한을 갖는 실시간 어플리케이션에 대해서는 충분한 기능을 제공하지 못하고 우선순위 반전문제를 야기한다.
RT-Mach의 IPC 모델은 Mach -IPC의 우선순위 반전 문제를 제거하여 예측 가능한 IPC 메커니즘을 제공하는데 그 목적이 있다.
기존의 IPC와 RT-IPC간의 차이점은 크게 두 가지로 나눌 수 있다.
첫째는 포트의 구조가 서로 다르다는 점이다. 기존 IPC 포트는 대기 중인 메시지를 보관하는 메시지 큐를 직접 가지고 있는 반면, RT-IPC는 직접적으로 메시지 큐를 갖는 대신에 통합된 자원 관리 모듈로의 함수 포인터를 가진다.
둘째로 커널 메시지 버퍼 관리에 있어 기존 IPC는 작은 크기의 메시지네 대해 할당된 하나의 커널 버퍼를 가지는 반면, RT-IPC는 포트 할당 시에 모든 커널 메시지가 할당 된다.
Real Time IPC 구조
클러스터의 구조
2) 시스템 구조
3) 클락 동기화
MARS는 클락 동기화를 얻기 위해 커스텀 하드웨어라는 것을 사용한다.
이는 컴포넌트가 다른 컴포넌트로부터 시간을 읽고 계산함으로써 로컬 클락 동기화를, 각 클러스터에게 시간 수신기를 두어 어떤 표준화된 곳으로부터 시간을 수신함으로써 전역 클락 동기화를 하고 있다. 로컬 클락 동기화시 약 4μsec이하의 전역 클락 동기화시 약 100μsec 이하의 시간 오차가 발생한다.
4) 스케줄링
MARS안에 태그들은 주기 또는 비주기 태스크 일 수 있는데 이들 태스크들은 정적 스케줄링 정책에 의해 스케줄 되어 진다. 경성 실시간 태스크 시스템은 시스템 시작 시 알려진 특정 시간 간격 안에 실행되어 지고 연성 실시간 태스크는 경성 실시간 태스크가 사용하고 남은 시간을 이용하여 실행되어 진다.
5) 메시지
통신은 유일한 클러스터 이름을 갖는 메시지를 전송함으로써 이루어진다. 특히 MARS는 특정 시간에 시스템과 상태와 환경에 대한 정보를 다루기 위해 읽기 전용 메시지인 상태 메시지를 이용하는데, 이는 스케줄러에 의해 미리 결정된 주기 메시지이다. 이 상태 메시지가 전송될 때에는 단지 그 메시지에 대한 포인터만이 전송되어 진다.
4.3.4 HARTOS
노드들이 육각망(hexagonal mesh)으로 구성되어 있는 분산 기엇 구조를 위해 개발한 실시간 운영 체제인 HARTOS는 멀티미디어 어플리케이션과 자동화 로봇제어, 온라인 스케줄링을 지원할 수 있는 시스템 개발을 목적으로 하고 있다.
1) 클락 동기화
HARTOS는 클락 동기화를 위해 타임 스탬핑 장치와 상호 수렴 알고리즘으로 구성된 클락 동기화 프로토콜을 사용한다. 하드웨어 타임 스탬핑 장치는 클락 메시지의 처리와 전파에 의해 발생되는 지연이 클락 동기화에 영향을 RL치지 못하게 하는 역할을 하고 있다. 클락 동기화 프로토콜은 다른 노드의 클락 동기화 프로토콜과 상호작용을 함으로써 시스템에게 전역시간을 제공하고 있다.
2) 실시간 채널
예측할 수 없는 메시지 전송 지연이 이 메시지에 의존하는 실시간 태스크 실행에 영향을 미치므로 실시간 시스템 통신은 예측성이 있어야 한다.
그러나 여러 가지 통신 형태에 의해 메시지 정송 지연을 예측할 수 없으므로 예측할 수 있는 통신 시스템을 달성하기가 어렵다.
HARTOS는 시기적절한 메시지 전송을 보장하기 위해 실시간 채널 프로토콜을 사용하고 있다. 이 RTCP는 전송 시 큰 메시지를 잘게 쪼갠 패킷이라는 조그만 메시지를 수신자에게 전송하더라도 승인 신호를 받을 수 없는, 에러 시에도 재전송 이라는 것이 없는 전송 방식을 채택하고 있다.
3) 원격 프로 시쥬어 호출(Remote Procedure Call)
이 프로토콜은 요구 패킷에 호출 매개변수를 저장한 뒤 응답 패킷에서 그 결과를 추출하는 요구-응답(request-reply)운영방식을 채택하고 있다.
4.3.5 LynxOS
개방 시시간 운영 체제에 대한 요구사항들을 처리하기 위해 1985년 개발에 착수한 LynxOS는 형재 실시간 성능과 산업 표준 개방 시스템ㄴ인 UNIX와 호환성을 유지한다.
1) 실시간 성능
실시간 제어, 데이터 감지, 통신을 위해 설계된 LynxOS는 어플리케이션을 위해 다음과 같은 특징을 갖는다.
• 최악의 경우에도 빠른 태스크 응답을 제공하기 위해 완전한 선점성과 멀티-쓰레드를 갖으며 사용자가 태스크의 우선순위를 결정할 수 있는 우선순위 기반 스케줄러를 갖는다.
• 낮은 우선순위 태스크가 선점한 자원에 의해 높은 우선순위 태스크가 이벤트를 제때에 처리하지 못하는 것을 방지하기 위해 완전 선점 가능한 커널을 제공한다.
· • 저수준 I/O를 처리할 때, 기존의 처리 방식은 높은 우선순위 인터럽트 루틴을 이용하여 처리하지만 LynxOS는 비동기적으로 처리한다.
2) UNIX 호환성
LynxOS는 실시간, UNIX-호환 운영체제이다. UNIX-호환성으로 인해 UNIX의 다음과 같은 많은 자아점을 갖게 되었다.
• 소프트웨어 이식성
•하드웨어 독립성
•친숙한 프로그래밍 환경
•접속성(connectivity)
즉, LynxOS가 UNIX와 호환된다는 의미는 LynxOS의 인터페이스가 UNIX와 똑같다는 의미와 함께 수정 없이도 LynxOS상에서 실행할 수 있음을 나타낸다.
'시리즈' 카테고리의 다른 글
| 44대 바락 오바마 대통령 (0) | 2013.06.25 |
|---|---|
| 명상하며 격언 듣기 (0) | 2013.06.20 |
| 자본주의 경제학자 주장들 초간단 정리 (2) | 2013.06.12 |
| 독서감상문 잘 쓰는 법 (7) | 2013.06.11 |
| 화폐의 역사 -2-(로마 시대 화폐,유노 모네타:money 기원 등) (0) | 2013.06.10 |