실시간 운영 체제

Real-time operating system

실시간 운영 체제(RTOS)는 시간 제약이 심각하게 정의된 데이터와 이벤트를 처리하는 실시간 애플리케이션을 위한 운영 체제(OS)이다.RTOS는 멀티태스킹 또는 멀티프로그래밍 환경에서 스케줄러, 데이터 버퍼 또는 고정 작업 우선순위 지정과 함께 시스템 자원 공유를 관리하는 Unix와 같은 시간 공유 운영 체제와 구별된다.처리 시간 요구사항은 단순히 최소로 유지되기 보다는 완전히 이해하고 구속할 필요가 있다.정의된 제약 시스템 내에서 발생하는 모든 처리는 이벤트 중심적이고 선제적이어야 하며, 이는 OS가 과제 완료의 관련 우선순위를 모니터링하고 과제 우선순위를 변경할 수 있음을 의미한다.이벤트 기반 시스템은 우선순위에 따라 작업 간에 전환되는 반면, 시간 공유 시스템은 클럭 인터럽트에 따라 작업을 전환한다.

특성.

RTOS의 주요 특성은 애플리케이션의 과제를 수락하고 완료하는 데 걸리는 시간에 대한 일관성의 수준이며, 변동성은 '지터'[1]이다.'하드' 실시간 운영 체제(하드 RTOS)는 '소프트' 실시간 운영 체제(소프트 RTOS)보다 지터가 적다.늦은 답은 딱딱한 RTOS에서 틀린 답인 반면, 늦은 답은 부드러운 RTOS에서 받아들여진다.주요 설계 목표는 높은 처리량이 아니라 소프트 또는 하드 성능 범주를 보장하는 것이다.보통 또는 일반적으로 기한을 맞출 수 있는 RTOS는 소프트 실시간 OS이지만 기한을 결정적으로 맞출 수 있다면 하드 실시간 OS이다.[2]

RTOS는 스케줄링을 위한 고급 알고리즘을 가지고 있다.스케줄러 유연성은 프로세스 우선 순위에 대한 컴퓨터 시스템의 광범위한 조정을 가능하게 하지만, 실시간 OS는 좁은 애플리케이션 집합에 더 자주 전용된다.실시간 OS의 주요 요인은 최소한의 인터럽트 지연 시간과 최소한의 스레드 전환 지연 시간이다. 실시간 OS는 주어진 시간 동안 수행할 수 있는 작업량보다 얼마나 빨리 또는 얼마나 예측 가능하게 대응할 수 있는지에 더 가치를 둔다.[3]

포괄적인 목록을 보려면 실시간 운영 체제 비교를 참조하십시오.또한 모든 유형의 운영 체제에 대한 운영 체제 목록을 참조하십시오.

디자인 철학

RTOS는 입력 자극을 처리하는 데 걸리는 시간이 동일한 유형의 다음 입력 자극까지 경과된 시간보다 짧은 운영 체제다.

가장 일반적인 설계는 다음과 같다.

  • 이벤트 중심 – 우선순위가 높은 이벤트가 서비스(선제 우선순위 또는 우선순위 스케줄링)가 필요할 때만 작업을 전환함
  • 시간 공유 – 규칙적으로 클럭 처리된 인터럽트와 이벤트(원형 로빈)에서 작업을 전환한다.

시간 공유 설계는 엄격하게 필요한 것보다 더 자주 작업을 전환하지만, 보다 부드러운 멀티태스킹을 제공하여 프로세스나 사용자가 기계를 단독으로 사용하는 것처럼 착각하게 한다.

초기 CPU 설계는 CPU가 다른 어떤 유용한 것도 할 수 없는 작업을 전환하기 위해 많은 사이클을 필요로 했다.전환에 너무 오랜 시간이 걸렸기 때문에 초기 OS들은 불필요한 작업 전환을 피함으로써 CPU 시간 낭비를 최소화하려고 노력했다.

스케줄링

일반적인 설계에서 태스크는 다음과 같은 세 가지 상태를 가진다.

  1. 실행(CPU에서 실행);
  2. 준비(실행 준비 완료);
  3. 차단됨(예: 이벤트 대기 중, I/O).

일반적으로 CPU당 한 번에 하나의 태스크만 실행할 수 있기 때문에 대부분의 태스크는 차단되거나 준비된다.준비된 대기열의 항목 수는 시스템이 수행해야 하는 작업의 수와 시스템이 사용하는 스케줄러 유형에 따라 크게 달라질 수 있다.보다 단순한 비선호적이지만 여전히 멀티태스킹 시스템에서 작업은 CPU에 대한 시간을 다른 작업에 포기해야 하므로, 준비된 대기열이 실행 준비 상태(리소스 기아)에서 더 많은 수의 전체 작업을 가질 수 있다.

일반적으로 스케줄러에 있는 준비목록의 데이터 구조는 스케줄러의 중요 섹션에 투입되는 최악의 시간의 길이를 최소화하도록 설계되어 있는데, 이 기간 동안 선점이 억제되고, 경우에 따라서는 모든 인터럽트가 비활성화되기도 하지만, 데이터 구조의 선택은 준비된 l에 있을 수 있는 최대 작업 수에 따라 달라진다.ist.

준비 목록에 작업이 결코 많지 않다면, 준비 작업의 두 배로 연결된 목록이 최적일 것이다.준비 목록에 일반적으로 몇 개의 태스크만 포함하지만 때때로 더 많은 태스크가 포함된 경우, 우선순위별로 목록을 정렬해야 한다.그렇게 하면, 실행할 가장 높은 우선순위 작업을 찾는 것은 전체 목록을 반복할 필요가 없다.그런 다음 태스크를 삽입하려면 목록의 끝에 도달할 때까지 또는 삽입되는 태스크의 우선순위보다 낮은 우선순위의 태스크가 될 때까지 준비 목록을 걸어가야 한다.

이 검색 중에는 선점하지 않도록 주의해야 한다.긴 임계 구간은 작은 조각으로 나누어야 한다.낮은 우선순위 태스크를 삽입하는 동안 높은 우선순위 태스크를 준비하도록 하는 인터럽트가 발생하면, 낮은 우선순위 태스크를 삽입하기 직전에 높은 우선순위 태스크를 삽입하여 실행할 수 있다.

중요 응답 시간(때로는 플라이백 시간이라고도 함)은 새로운 준비 작업을 대기열에 넣고 가장 우선 순위가 높은 작업의 상태를 실행으로 복원하는 데 걸리는 시간이다.잘 설계된 RTOS에서, 새로운 작업을 읽기 위해서는 레디큐 입력당 3~20개의 지침이 필요하며, 가장 우선순위가 높은 준비 작업의 복원은 5~30개의 지침이 필요하다.

보다 발전된 시스템에서는 실시간 작업이 많은 비실시간 업무와 컴퓨팅 자원을 공유하며, 준비목록은 임의로 길어질 수 있다.그러한 시스템에서는 링크된 목록으로 구현된 스케줄러 준비 목록이 부적절할 수 있다.

알고리즘

일반적으로 사용되는 RTOS 스케줄링 알고리즘은 다음과 같다.

태스크 간 통신 및 리소스 공유

유닉스와 같은 멀티태스킹 운영체제는 실시간 작업에서 서툴다.스케줄러는 컴퓨터의 수요가 가장 적은 직업에 가장 높은 우선순위를 부여하기 때문에 시간적으로 중요한 일이 충분한 자원에 접근할 수 있도록 보장할 방법이 없다.멀티태스킹 시스템은 여러 작업 간의 데이터 및 하드웨어 리소스 공유를 관리해야 한다.두 작업이 동일한 특정 데이터 또는 하드웨어 리소스에 동시에 액세스하는 것은 일반적으로 안전하지 않다.[4]이 문제를 해결하기 위한 세 가지 일반적인 접근법이 있다.

일시적으로 인터럽트를 마스킹/비활성화

범용 운영 체제는 사용자 프로그램이 원하는 만큼 CPU를 제어할 수 있기 때문에 일반적으로 사용자 프로그램이 인터럽트를 마스킹(비활성화)하는 것을 허용하지 않는다.일부 최신 CPU는 사용자 모드 코드가 인터럽트를 비활성화하는 것을 허용하지 않는다. 이러한 제어가 핵심 운영 체제 자원으로 간주되기 때문이다.그러나, 많은 임베디드 시스템과 RTOS는 커널 모드에서 애플리케이션 자체를 실행할 수 있게 하여 시스템 호출 효율성을 높이고 OS 개입 없이 애플리케이션이 운영 환경을 더 잘 제어할 수 있게 한다.

단일 프로세서 시스템에서 커널 모드에서 실행 중인 애플리케이션과 마스킹 인터럽트는 공유 리소스에 대한 동시 액세스를 방지하는 가장 낮은 오버헤드 방법이다.인터럽트가 마스킹되고 현재 작업이 차단 OS 호출을 하지 않는 반면, 현재 태스크는 다른 태스크나 인터럽트가 제어를 할 수 없기 때문에 CPU를 독점적으로 사용하므로 중요 섹션은 보호된다.태스크가 중요한 섹션을 종료할 때 인터럽트를 마스킹 해제해야 하며, 보류 중인 인터럽트가 있는 경우 실행된다.임시로 마스킹 인터럽트는 중요 섹션을 통과하는 가장 긴 경로가 원하는 최대 인터럽트 지연 시간보다 짧은 경우에만 수행해야 한다.일반적으로 이 보호 방법은 중요 섹션이 단지 몇 가지 지시사항일 뿐 루프가 없는 경우에만 사용된다.이 방법은 비트가 다른 작업에 의해 제어될 때 하드웨어 비트맵 레지스터를 보호하는 데 이상적이다.

뮤텍스

다른 모든 작업(예: 플래시 메모리가 작성되기를 기다리는 것)을 차단하지 않고 공유 리소스를 예약해야 하는 경우, 뮤텍스 및 OS가 감독하는 인터프로세스 메시징과 같은 범용 운영 체제에서도 사용할 수 있는 메커니즘을 사용하는 것이 좋다.그러한 메커니즘은 시스템 호출을 포함하며, 대개 종료 시 OS의 디스패처 코드를 호출하므로, 일반적으로 실행하기 위해 수백 개의 CPU 명령이 필요한 반면, 마스킹 인터럽트는 일부 프로세서에 대해 하나의 명령만 필요할 수 있다.

A(비복구) 뮤텍스가 잠기거나 잠금 해제된다.태스크가 뮤텍스를 잠근 경우, 다른 모든 태스크는 원래 쓰레드 소유자가 뮤텍스를 잠금 해제할 때까지 기다려야 한다.작업은 뮤텍스에 대한 대기 시간을 설정할 수 있다.뮤텍스 기반 설계에는 우선순위 반전 및 교착 상태와 같은 몇 가지 잘 알려진 문제가 있다.

우선 순위가 낮은 태스크에는 뮤텍스가 있기 때문에 우선 순위가 높은 태스크가 대기하지만 우선 순위가 낮은 태스크에는 작업을 완료할 CPU 시간이 주어지지 않는다.일반적인 해결책은 뮤텍스를 소유한 태스크가 가장 높은 대기 작업의 우선 순위를 '상속'하도록 하는 것이다.그러나 이러한 간단한 접근방식은 여러 단계의 대기자가 있을 때 더욱 복잡해진다: 작업 A는 작업 B에 의해 잠긴 뮤텍스를 기다리고, 작업 C에 의해 잠긴 뮤텍스를 기다린다.여러 단계의 상속을 처리하면 다른 코드가 높은 우선순위 컨텍스트에서 실행되므로 중간 우선순위 스레드가 부족해질 수 있다.

교착 상태에서는 두 개 이상의 태스크가 시간 초과 없이 뮤텍스를 잠근 다음 다른 태스크의 뮤텍스를 영원히 기다리며 순환 종속성을 생성한다.가장 간단한 교착상태 시나리오는 두 작업이 번갈아 두 뮤텍스를 잠글 때 발생하지만 반대 순서로 나타난다.세심한 설계로 교착상태를 방지한다.

메시지 전달

자원 공유에 대한 또 다른 접근방식은 조직화된 메시지 전달 방식으로 메시지를 보내는 작업이다.이 패러다임에서 자원은 한 가지 업무만으로 직접 관리된다.다른 태스크가 리소스를 조회하거나 조작하려는 경우, 관리 태스크에 메시지를 전송한다.비록 그들의 실시간 행동이 세마포어 시스템보다 덜 상쾌하지만, 간단한 메시지 기반 시스템은 대부분의 프로토콜 교착 상태 위험을 피하며, 일반적으로 세마포어 시스템보다 더 나은 행동이다.그러나 세마포어 같은 문제는 가능하다.우선 순위 역전은 태스크가 낮은 우선순위 메시지로 작업 중이고 수신 메시지 대기열에서 높은 우선순위 메시지(또는 높은 우선순위 태스크에서 간접적으로 발생하는 메시지)를 무시할 때 발생할 수 있다.프로토콜 교착상태는 둘 이상의 태스크가 서로 응답 메시지를 전송하기 위해 대기할 때 발생할 수 있다.

인터럽트 핸들러 및 스케줄러

인터럽트 핸들러는 가장 높은 우선 순위 태스크의 실행을 차단하고 실시간 운영 체제는 스레드 지연 시간을 최소로 유지하도록 설계되므로 인터럽트 핸들러는 일반적으로 가능한 짧게 유지된다.인터럽트 핸들러는 가능한 경우 하드웨어와의 모든 상호작용을 방어한다. 일반적으로 필요한 것은 인터럽트를 승인하거나 비활성화하거나(인터럽트 핸들러가 돌아올 때 다시 발생하지 않도록 하기 위해) 작업이 수행되어야 하는 작업을 통지하는 것이다.이는 세마포어 해제, 플래그 설정 또는 메시지 전송을 통해 드라이버 작업 차단을 해제하여 수행할 수 있다.스케줄러는 종종 인터럽트 처리기 컨텍스트에서 작업을 차단 해제하는 기능을 제공한다.

OS는 스레드, 뮤텍스, 메모리 등과 같이 관리하는 개체의 카탈로그를 유지 관리한다.이 카탈로그에 대한 업데이트는 엄격하게 관리되어야 한다.이 때문에 어플리케이션도 하는 중에 인터럽트 핸들러가 OS 함수를 호출할 때 문제가 될 수 있다.인터럽트 핸들러에서 호출된 OS 함수는 애플리케이션의 업데이트로 인해 개체 데이터베이스가 일관되지 않은 상태임을 발견할 수 있었다.이 문제를 다루기 위한 두 가지 주요한 접근방식이 있다: 통합 아키텍처와 세분화된 아키텍처.통합 아키텍처를 구현하는 RTOS는 내부 카탈로그가 업데이트되는 동안 단순히 인터럽트를 비활성화함으로써 문제를 해결한다.이것의 단점은 인터럽트 대기 시간이 증가하여 인터럽트가 손실될 가능성이 있다는 것이다.세분화된 아키텍처는 OS를 직접 호출하지 않고 OS 관련 작업을 별도의 처리기로 위임한다.이 핸들러는 어떤 스레드보다 높은 우선순위에서 실행되지만 인터럽트 핸들러보다 낮은 우선순위로 실행된다.이 아키텍처의 이점은 지연 시간을 방해하는 사이클을 거의 추가하지 않는다는 것이다.결과적으로, 세분화된 아키텍처를 구현하는 OS는 통일된 아키텍처에 비해 더 예측 가능하고 더 높은 인터럽트 비율을 처리할 수 있다.[citation needed]

마찬가지로, x86 호환 하드웨어의 시스템 관리 모드는 운영 체제에 대한 제어권을 반환하는 데 많은 시간이 걸릴 수 있다.

메모리 할당

메모리 할당은 다른 운영체제보다 실시간 운영체제에서 더 중요하다.

첫째, 안정성을 위해 메모리 누수가 있을 수 없다(사용 후 할당되지만 해제되지 않는 메모리).이 장치는 재부팅할 필요 없이 무한정 작동해야 한다.이 때문에 동적 메모리 할당은 눈살을 찌푸리게 한다.[citation needed]가능할 때마다 필요한 모든 메모리 할당은 컴파일 시간에 정적으로 지정된다.

동적 메모리 할당을 피하는 또 다른 이유는 메모리 조각화 때문이다.작은 메모리 덩어리의 빈번한 할당과 해제로 사용 가능한 메모리가 여러 섹션으로 나뉘고 RTOS는 충분한 여유 메모리가 있지만 충분히 큰 연속적인 메모리 블록을 할당할 수 없는 상황이 발생할 수 있다.둘째, 할당 속도가 중요하다.표준 메모리 할당 체계는 일정한 시간 내에 메모리 할당이 발생해야 하기 때문에 RTOS에서 수용할 수 없는 적절한 여유 메모리 블록을 찾기 위해 미확정 길이의 링크된 목록을 스캔한다.[5]

기계식 디스크는 훨씬 더 길고 예측 불가능한 응답 시간을 가지기 때문에 위에서 설명한 RAM 할당과 같은 이유로 디스크 파일로 스와핑을 사용하지 않는다.

단순한 고정 크기 블록 알고리즘은 오버헤드가 낮기 때문에 단순한 임베디드 시스템에 매우 잘 작동한다.

참고 항목

참조

  1. ^ "Response Time and Jitter".
  2. ^ Tanenbaum, Andrew (2008). Modern Operating Systems. Upper Saddle River, NJ: Pearson/Prentice Hall. p. 160. ISBN 978-0-13-600663-3.
  3. ^ "RTOS Concepts".
  4. ^ Phraner, Ralph A. (Fall 1984). "The Future of Unix on the IBM PC". BYTE. pp. 59–64.
  5. ^ "CS 241, University of Illinois" (PDF).