실시간 운영 체제 - 위키백과, 우리 모두의 백과사전 실시간 운영 체제 위키백과, 우리 모두의 백과사전. 둘러보기로 가기 검색하러 가기 이 문서의 내용은 출처가 분명하지 않습니다. 이 문서를 편집하여, 신뢰할 수 있는 출처를 표기해 주세요. 검증되지 않은 내용은 삭제될 수도 있습니다. 내용에 대한 의견은 토론 문서에서 나누어 주세요. ( 2013년 7월 ) 실시간 운영 체제 ( 문화어 : 실시간조작체계 ) 또는 RTOS ( [UNK] Time Operating System ) 는 실시간 응용 프로그램을 위해 개발된 운영 체제이다. 운영 체제의 기능 중 CPU 시간 관리 부분에 초점을 맞추어 설계되었다. 실시간 운영 체제는 프로그래머가 프로세스 우선 순위에 더 많은 제어를 할 수 있게 한다. 응용 프로그램의 우선 순위가 시스템 프로그램의 우선 순위를 넘어설 수도 있다. 시스템 코드의 임계 구역을
) 실시간 운영 체제로 구분할 수 있으며, 전자가 후자에 비해 지터가 적다. RTOS의 주된 설계 목표는 높은 처리율 ( throughput ) 이 아니라, 실시간 성능 보장에 있다. 실시간 시스템의 데드라인을 대체로 맞추는 RTOS를 연성 실시간 운영체제라 하고, 데드라인을 결정론적 알고리즘 ( deterministic algorithm ) 에 의해 만족하는 경우를 경성 실시간 운영체제라 한다. [ 1 ] 규모가 큰 실시간 운영 체제의 초기 예는 " 제어 프로그램 " 이었는데, 이는 아메리칸 항공 ( American Airlines ) 과 IBM이 세이버 ( Sabre ) 항공 예약 시스템을 위해서 개발한 것이었다. 목차 1 설계 방식 2 스케줄링 2. 1 스케줄링 알고리즘 3 태스크 간 통신과 자원 공유 3. 1 일시적인 인터럽트 비활성화 3. 2 세
어 설계되었다. 실시간 운영 체제는 프로그래머가 프로세스 우선 순위에 더 많은 제어를 할 수 있게 한다. 응용 프로그램의 우선 순위가 시스템 프로그램의 우선 순위를 넘어설 수도 있다. 시스템 코드의 임계 구역을 최소화하였으며, 이를 통하여 응용 프로그램의 처리 요청을 정해진 시간 안에 처리해 줄 수 있다. 실시간 운영체제의 핵심은 응용 프로그램 테스크 처리에 걸리는 시간을 일관되게 유지할 수 있는 정도에 있다. 처리 시간의 변동폭은 지터 ( jitter ) ( 실제 신호와 기준점과의 시간 편차 ) 라 부른다. 경성 ( hard ) 실시간 운영 체제와 연성 ( soft ) 실시간 운영 체제로 구분할 수 있으며, 전자가 후자에 비해 지터가 적다. RTOS의 주된 설계 목표는 높은 처리율 ( throughput ) 이 아니라, 실시간 성능 보장에 있
OSEK / VDX pSOS QNX RMX RSX - 11 RT - 11 RTOS - UH ThreadX VRTX Velos VxWorks 윈도 CE RTLinux RTAI 많은 회사들이 리눅스에 실시간 기능을 가미한 버전을 판매하고 있다. 2004년 10월 8일 몬타비스타는 리눅스 커널 메일링 리스트를 통해 리눅스에 실시간 성능을 향상하기 위한 실시간 패치를 공개했다. 각주 [ 편집 ] ↑ Tanenbaum, Andrew ( 2008 ). 《 Modern Operating Systems 》. Upper Saddle River, NJ : Pearson / Prentice Hall. 160쪽. ISBN 978 - 0 - 13 - 600663 - 3. 원본 주소 " " 분류 : 실시간 운영 체제임베디드 운영
다 높은 우선 순위를 갖는 이벤트가 서비스를 요청할 경우에 일어난다. 시분할 ( time - sharing ) 스케줄링 방식 : 클럭 인터럽트나 라운드 로빈과 같은 주기적인 이벤트가 발생할 때 태스크의 전환이 일어난다. 엄밀히 말해, 시분할 스케줄링 방식은 실제 필요한 것보다 더 자주 태스크 전환이 일어난다. 하지만 이러한점 덕분에 좀 더 자연스럽고, 예측하기 쉬운 멀티태스킹을 제공하며, 하나의 프로세스나 한명의 사용자가 장치를 독점적으로 사용하는 것과 같은 효과를 제공한다. 때문에 이 방식이 좀 더 나은 멀티태스킹 방식처럼 보일 수 있다. 스케줄링 [ 편집 ] 전통적인 설계 방식에서, 태스크는 수행 ( running ), 대기 ( ready ), 블록 ( blocked ) 의 세 가지 상태 ( state ) 중 한 가지 상태로 존재한다
럽트가 있다면 실행되도록 인터럽트를 다시 활성화시켜야 한다. 일시적으로 인터럽트를 비활성화하는 것은 임계 구역의 가장 긴 경로가 인터럽트 대기 시간보다 짧은 경우 유효한 전략이다. 그렇지 않다면 이 방법을 통하여 시스템의 최대 인터럽트 대기 시간을 증가시킬 가능성이 있다. 따라서 임계 구역이 단지 몇 개의 명령어로 이루어졌거나, 반복구문을 포함하지 않은 경우 유효하다고 할 수 있다. 세마포어 [ 편집 ] 세마포어는 잠기거나 풀려있다. 잠겨 있을 때 작업들의 대기는 세마포어 ( 가 풀리기 ) 를 기다린다. 세마포어 디자인들이 가지는 문제점들은 잘 알려져 있다 : 우선 순위 역전과 교착 상태이다. 우선 순위 역전은 높은 순위의 작업이 낮은 순위의 세마포어를 가지는
는 시간을 최소화할 수 있게 설계 한다. 하지만, 데이터 구조의 선택은 대기 리스트에 들어갈 수 있는 최대 태스크의 숫자에도 좌우된다. 만약 대기 목록에 2 ~ 3개 정도에 적은 수의 태스크만 존재하는 구조라면, 단순히 이중 연결 리스트 구조로 대기 목록을 구현 하는 것도 효율적이다. 반면, 통상 적은 수에 태스크만 존재하지만 가끔 그보다 많은 수가 존재하는 경우라면, 태스크를 실행할 때마다 전체 목록을 뒤져 우선 순위가 높은 태스크를 찾는 작업을 반복적으로 하지 않도록 우선 순위를 기준으로 미리 정렬하거나 높은 우선 순위의 태스크를 낮은 우선 순위의 태스크보다 먼저 대기 리스트에 추가할 수 있도록 설계한다. 즉, 대기 목록을 검색하는 동안 CPU의 선점을 금지하지 않거나 긴 임계 구역을 작게 나누어야 한다는 의미
하고, 두 개의 태스크를 대기 상태 태스크 목록에 집어 넣는다. 그 후, 가장 우선 순위가 높은 태스크를 다시 수행하는데 이 전체 과정에 걸리는 시간을 중요 응답 시간 ( critical response time ) 혹은 플라이백 타임 ( flyback time ) 이라고 부른다. 잘 설계된 실시간 운영 체제의 경우, 새로운 태스크를 대기 상태로 만드는 데 3 - 20개의 명령어를 사용한다. 또, 가장 높은 우선 순위를 가진 대기 태스크를 수행 상태로 변경하는데 5 - 30개의 명령어를 사용한다. 고급 실시간 운영 체제에서는 실시간으로 동작하는 태스크들이 실시간으로 동작하지 않는 태스크들과 컴퓨터 자원을 공유한다. 따라서 대기 리스트는 상당히 길어질 수 있다. 이러한 시스템에서 스케줄러 대기 리스트를 간단한 연결 리스트 ( linked list ) 로 구현하는 것은 알맞
는 3가지 방식을 소개한다. 일시적인 인터럽트 비활성화 [ 편집 ] 범용 운영 체제에서는 사용자가 인터럽트를 마스크 ( 비활성화 ) 하지 못한다. 그 이유는 사용자의 프로그램이 운영 체제의 핵심 자원인 CPU를 너무 긴 시간동안 점유하고 있을 수 있기 때문이다. 다시 말해, 현재 사용되는 대다수의 CPU들은 사용자 모드 코드가 인터럽트를 비활성화할 수 있는 권한을 부여하지 않는다. 하지만, 많은 임베디드 시스템과 실시간 운영 체제들은 응용 프로그램이 운영 체제의 간섭 없이 시스템 콜을 효율적으로 사용할 수 있게 하기 위해 커널 모드에서도 동작할 수 있도록 한다. 단일 프로세서 시스템에서, 만약 응용 프로그램이 현재 커널 모드로 동작하고, 인터럽트를 비활성화할 수 있다면, 대개 인터럽트 비활성화야말로 두
인터럽트 핸들러는 실행중인 가장 높은 우선의 태스크 조차도 중단 시킬 수 있으며, 실시간 운영 체제는 스레드 대기시간을 최소화하도록 설계되어 있기 때문에, 인터럽트 핸들러의 기능은 가능한 최소화되기 마련이다. 동적 메모리 할당 [ 편집 ] 실시간 운영 체제의 동적 메모리 할당은 일반 운영 체제보다 엄격한 조건이 요구된다. 먼저, 할당 속도가 중요하다. 표준 메모리 할당 방식은 알맞은 크기의 사용되지 않는 메모리 블록을 찾기 위해서 연결 리스트를 검색하는 것이다. 하지만, 이 방식은 정해진 시간 안에 메모리 할당이 일어나야 하는 실시간 운영 체제에는 맞지 않는다. 또한, 메모리의 공간을 분할하여 사용하 보면 단편화 ( Fragmentation ) 가 발생한다. 따라서 메모리 자체는 충분하더라도 메모리를 확보할 수 없어, 프로그램이 멈추는
실시간 운영체제(문화어: 실시간조작체계) 또는 RTOS(←Real Time Operating System)는 실시간 응용 프로그램을 위해 개발된 운영체제이다. 운영체제의 기능 중 CPU 시간 관리 부분에 초점을 맞추어 설계되었다. 실시간 운영체제는 프로그래머가 프로세스 우선 순위에 더 많은 제어를 할 수 있게 한다. 응용 프로그램의 우선 순위가 시스템 프로그램의 우선 순위를 넘어설 수도 있다. 시스템 코드의 임계 구역을 최소화하였으며, 이를 통하여 응용 프로그램의 처리 요청을 정해진 시간 안에 처리해 줄 수 있다. 실시간 운영체제의 핵심은 응용 프로그램 테스크 처리에 걸리는 시간을 일관되게 유지할 수 있는 정도에 있다. 처리 시간의 변동폭은 지터(jitter)(실제 신호와 기준점과의 시간 편차)라 부른다. 경성(hard) 실시간 운영체제와 연성(soft) 실시간 운영체제로 구분할 수 있으며, 전자가 후자에 비해 지터가 적다. RTOS의 주된 설계 목표는 높은 처리율(throughput)이 아니라, 실시간 성능 보장에 있다. 실시간 시스템의 데드라인을 대체로 맞추는 RTOS를 연성 실시간 운영체제라 하고, 데드라인을 결정론적 알고리즘(deterministic algorithm)에 의해 만족하는 경우를 경성 실시간 운영체제라 한다.규모가 큰 실시간 운영체제의 초기 예는 "제어 프로그램"이었는데, 이는 아메리칸 항공(American Airlines)과 IBM이 세이버(Sabre) 항공 예약 시스템을 위해서 개발한 것이었다.