실시간 운영 체제 - 위키백과, 우리 모두의 백과사전 실시간 운영 체제 위키백과, 우리 모두의 백과사전. 둘러보기로 가기 검색하러 가기 이 문서의 내용은 출처가 분명하지 않습니다. 이 문서를 편집하여, 신뢰할 수 있는 출처를 표기해 주세요. 검증되지 않은 내용은 삭제될 수도 있습니다. 내용에 대한 의견은 토론 문서에서 나누어 주세요. ( 2013년 7월 ) 실시간 운영 체제 ( 문화어 : 실시간조작체계 ) 또는 RTOS ( Time Operating System ) 는 실시간 응용 프로그램을 위해 개발된 운영 체제이다. 운영 체제의 기능 중 CPU 시간 관리 부분에 초점을 맞추어 설계되었다. 실시간 운영 체제는 프로그래머가 프로세스 우선 순위에 더 많은 제어를 할 수 있게 한다. 응용 프로그램의 우선 순위가 시스템 프로그램의 우선 순위를 넘어설 수도 있다. 시스템 코드의 임계 구역을 최소화하였으며, 이를 통하여 응용 프로그램의 처리 요청을 정해진 시간 안에 처리해 줄 수 있다. 실시간 운영체제의 핵심은 응용 프로그램 테스크 처리에 걸리는 시간을 일관되게 유지할 수 있는 정도에 있다. 처리 시간의 변동폭은 지터 ( jitter ) ( 실제 신호와 기준점과의 시간 편차 ) 라 부른다. 경성 ( hard ) 실시간 운영 체제와 연성 ( soft ) 실시간
1개의 태스크만 수행상태이다. 간단한 시스템 일수록 대기 상태의 태스크 목록이 짧으며, 많은 경우도 2 ~ 3개 정도이다. 일반적으로 스케줄러 대기 태스크 목록의 데이터 구조는 스케줄러의 임계 구역 ( CPU의 선점이 금지되며, 어떠한 경우에는 모든 인터럽트가 비활성화된다. ) 에서 소비되는 시간을 최소화할 수 있게 설계 한다. 하지만, 데이터 구조의 선택은 대기 리스트에 들어갈 수 있는 최대 태스크의 숫자에도 좌우된다. 만약 대기 목록에 2 ~ 3개 정도에 적은 수의 태스크만 존재하는 구조라면, 단순히 이중 연결 리스트 구조로 대기 목록을 구현 하는 것도 효율적이다. 반면, 통상 적은 수에 태스크만 존재하지만 가끔 그보다 많은 수가 존재하는 경우라면, 태스크를 실행할 때마다 전체 목록을 뒤져 우선 순위가 높은 태스크를 찾는 작업을 반복적으로 하지 않도록 우선 순위를 기준으로 미리 정렬하거나 높은 우선 순위의 태스크를 낮은 우선 순위의 태스크보다 먼저 대기 리스트에 추가할 수 있도록 설계한다. 즉, 대기 목록을 검색하는 동안 CPU의 선점을 금지하지 않거나 긴 임계 구역을 작게 나누어야 한다는 의미이다. 이 말은 낮은 우선 순위의 태스크를 리스트에
Operating Systems 》. Upper Saddle River, NJ : Pearson / Prentice Hall. 160쪽. ISBN 978 - 0 - 13 - 600663 - 3. 원본 주소 " " 분류 : 실시간 운영 체제임베디드 운영 체제운영 체제 기술숨은 분류 : 출처가 필요한 글 / 2013년 7월출처가 필요한 모든 글전체에 출처가 필요한 글문화어 표기를 포함한 문서영어 표기를 포함한 문서 둘러보기 메뉴 개인 도구 로그인하지 않음토론기여계정 만들기로그인 이름공간 문서토론 변수 보기 읽기편집역사 보기 더 보기 검색 둘러보기 대문사용자 모임요즘 화제최근 문서 보기임의 문서로도움말기부 도구 여기를 가리키는 문서가리키는 글의 최근 올리기특수 문서 목록고유 링크문서 정보위키데이터 항목이 문서 인용하기 다른 프로젝트 공용 인쇄 / 내보내기 책 만들기PDF로 다운로드인쇄용 판 다른 언어 日 本 語 中 文 링크 편집 이 문서는 2019년 5월 11일 ( 토 ) 16 : 43에 마지막으로 편집되었습니다. 모든 문서는 크리에이티브 커먼즈 저작자표시 - 동일조건변경허락 3. 0에 따라 사용할 수 있으며, 추가적인 조건이
##S ( 임베디드 운영 체제 ) 는 XIP ( 즉석에서 실행 ) 를 지원한다. 커널과 응용 프로그램들이 코드를 RAM으로 먼저 전송하지 않고 ROM에서 직접 실행된다. 운영 체제의 필요한 RAM 크기와 ROM 크기 사이의 교환을 제공한다. [ 1 ] 다양한 RTOS들 [ 편집 ] 국방 / 항공용 실시간 운영체제 NEOS BeOS ChorusOS CsLEOS eCos FreeRTOS ITRON LynxOS MicroC / OS - II Nucleus RTOS OS - 9 OSE 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.
크리에이티브 커먼즈 저작자표시 - 동일조건변경허락 3. 0에 따라 사용할 수 있으며, 추가적인 조건이 적용될 수 있습니다. 자세한 내용은 이용 약관을 참고하십시오. 미국 및 다른 국가에 등록되어 있는 Wikimedia Foundation, Inc. 소유의 등록 상표입니다. 개인정보 정책 위키백과 소개 면책 조항 개발자 쿠키 정책 모바일 보기
방식 [ 편집 ] 두 가지 기본적인 설계 방식이 존재한다. 이벤트 구동 ( event - driven ) 방식 : 우선 순위 기반 스케줄링 또는 선점형 스케줄링 이라고 부른다. 태스크 ( task ) 전환이 현재 수행중인 태스크보다 높은 우선 순위를 갖는 이벤트가 서비스를 요청할 경우에 일어난다. 시분할 ( time - sharing ) 스케줄링 방식 : 클럭 인터럽트나 라운드 로빈과 같은 주기적인 이벤트가 발생할 때 태스크의 전환이 일어난다. 엄밀히 말해, 시분할 스케줄링 방식은 실제 필요한 것보다 더 자주 태스크 전환이 일어난다. 하지만 이러한점 덕분에 좀 더 자연스럽고, 예측하기 쉬운 멀티태스킹을 제공하며, 하나의 프로세스나 한명의 사용자가 장치를 독점적으로 사용하는 것과 같은 효과를 제공한다. 때문에 이 방식이 좀 더 나은 멀티태스킹 방식처럼 보일 수 있다. 스케줄링 [ 편집 ] 전통적인 설계 방식에서, 태스크는 수행 ( running ), 대기 ( ready ), 블록 ( blocked ) 의 세 가지 상태 ( state ) 중 한 가지 상태로 존재한다. 대부분의 태스크가 블록상태이고, 오직 1개의 태스크만 수행상태이다. 간단한 시스템 일수록 대기 상태의 태스크 목록이 짧으며, 많은 경우도 2
##하지 않거나 긴 임계 구역을 작게 나누어야 한다는 의미이다. 이 말은 낮은 우선 순위의 태스크를 리스트에 추가하는 동안이라도, 높은 우선 순위의 태스크를 대기 상태로 만드는 인터럽트가 발생하면, 높은 우선 순위의 태스크를 먼저 대기 목록에 추가하고 바로 수행할 수 있도록 한다는 것이다. 새로운 태스크가 생성되면 이 태스크는 일단 대기 상태가 된다. 스케줄러는 현재 수행중인 태스크 역시 대기 상태로 변경하고, 두 개의 태스크를 대기 상태 태스크 목록에 집어 넣는다. 그 후, 가장 우선 순위가 높은 태스크를 다시 수행하는데 이 전체 과정에 걸리는 시간을 중요 응답 시간 ( critical response time ) 혹은 플라이백 타임 ( flyback time ) 이라고 부른다. 잘 설계된 실시간 운영 체제의 경우, 새로운 태스크를 대기 상태로 만드는 데 3 - 20개의 명령어를 사용한다. 또, 가장 높은 우선 순위를 가진 대기 태스크를 수행 상태로 변경하는데 5 - 30개의 명령어를 사용한다. 고급 실시간 운영 체제에서는 실시간으로 동작하는 태스크들이 실시간으로 동작하지 않는 태스크들과 컴퓨터 자원을 공유한다. 따라서 대기 리스트는 상당히 길어질 수 있다. 이러한 시스템에서 스케줄러 대기 리스트를 간단한 연결 리스트 (
최우선 순위가 되도록 하는 것이다. 교착에서는 두 개의 작업이 두 개의 세마포어를 역순으로 잠근다. 이것은 대개 대기열을 구현할 때 면밀하게 설계하거나 또는 floored semaphores ( 정해진 상황에서 세마포어의 제어권을 높은 순위의 작업에 넘기는 ) 를 추가함으로써 해결된다. 메시지 전달 [ 편집 ] 다른 해결책은 작업들이 서로 메시지를 주고 받게 하는 것이다. 이것 또한 똑같은 문제점들을 안고 있다 : 작업이 낮은 우선 순위의 메시지를 수행하느라 in - box에 있는 더 높은 순위의 메시지를 무시할 때 우선 순위 역전이 일어난다. 두 개의 작업이 서로 상대방의 응답을 기다릴 때 교착이 일어난다. 실시간 동작은 세마포어 시스템의 경우보다는 덜 분명하지만, 메시지 기반 시스템들은 자체적으로는 고정적이지 않아 일반적으로 세마포어 시스템들보다는 더 잘 동작한다. 인터럽트 핸들러와 스케줄러 [ 편집 ] 인터럽트 핸들러는 실행중인 가장 높은 우선의 태스크 조차도 중단 시킬 수 있으며, 실시간 운영 체제는 스레드 대기시간을 최소화하도록 설계되어 있기 때문에, 인터럽트 핸들러의 기능은 가능한 최소화되기 마련이다. 동적 메모리 할당 [ 편집 ] 실시간 운영 체제의 동적
##하기 전이나 완전히 종료된 후 뿐이다. ) 이 문제를 해결하기 위해서 보통 사용되는 3가지 방식을 소개한다. 일시적인 인터럽트 비활성화 [ 편집 ] 범용 운영 체제에서는 사용자가 인터럽트를 마스크 ( 비활성화 ) 하지 못한다. 그 이유는 사용자의 프로그램이 운영 체제의 핵심 자원인 CPU를 너무 긴 시간동안 점유하고 있을 수 있기 때문이다. 다시 말해, 현재 사용되는 대다수의 CPU들은 사용자 모드 코드가 인터럽트를 비활성화할 수 있는 권한을 부여하지 않는다. 하지만, 많은 임베디드 시스템과 실시간 운영 체제들은 응용 프로그램이 운영 체제의 간섭 없이 시스템 콜을 효율적으로 사용할 수 있게 하기 위해 커널 모드에서도 동작할 수 있도록 한다. 단일 프로세서 시스템에서, 만약 응용 프로그램이 현재 커널 모드로 동작하고, 인터럽트를 비활성화할 수 있다면, 대개 인터럽트 비활성화야말로 두 개 이상의 태스크가 동시에 공유자원에 접근하는 것을 막아주는 최고의 기법이다. 인터럽트가 비활성화되어 있는 경우, 현재 돌고 있는 태스크는 다른 태스크나 인터럽트가 CPU를 제어할 수 없기 때문에 " 배타성 " 을 띠며, 따라서 임계 구역은 보호 받는
자원을 공유한다. 따라서 대기 리스트는 상당히 길어질 수 있다. 이러한 시스템에서 스케줄러 대기 리스트를 간단한 연결 리스트 ( linked list ) 로 구현하는 것은 알맞지 않다. 스케줄링 알고리즘 [ 편집 ] 일반적으로 RTOS에서 사용되는 스케줄링 알고리즘에는 아래와 같은 것이 있다. 협력형 스케줄링 ( cooperative scheduling ) 선점형 스케줄링 ( pre - emptive scheduling ) 라운드 로빈 스케줄링 ( Round - robin scheduling ) 고정 우선순위 선점형 스케줄링 ( fixed priority pre - emptive scheduling ) 태스크 간 통신과 자원 공유 [ 편집 ] 멀티태스킹 시스템은 여러 개의 태스크 사이에 공유되는 데이터와 하드웨어 자원을 관리해 주어야 한다. 대부분의 경우 두 개 이상의 태스크가 동시에 같은 데이터나 하드웨어 자원에 접근하는 것은 위험하다. ( " 위험 " 하다는 것은 한 태스크가 복수의 데이터를 갱신하는 중일 경우, 결과가 일관성이 없고 예측 불가능하다는 뜻이다. 다른 태스크가 이 데이터들에 접근해도 되는 시점은 갱신이 시작하기 전이나 완전히 종료된 후 뿐이다. ) 이 문제를 해결하기 위해서 보통 사용되는 3가지 방식을 소개한다. 일시적인
실시간 운영체제(문화어: 실시간조작체계) 또는 RTOS(←Real Time Operating System)는 실시간 응용 프로그램을 위해 개발된 운영체제이다. 운영체제의 기능 중 CPU 시간 관리 부분에 초점을 맞추어 설계되었다. 실시간 운영체제는 프로그래머가 프로세스 우선 순위에 더 많은 제어를 할 수 있게 한다. 응용 프로그램의 우선 순위가 시스템 프로그램의 우선 순위를 넘어설 수도 있다. 시스템 코드의 임계 구역을 최소화하였으며, 이를 통하여 응용 프로그램의 처리 요청을 정해진 시간 안에 처리해 줄 수 있다. 실시간 운영체제의 핵심은 응용 프로그램 테스크 처리에 걸리는 시간을 일관되게 유지할 수 있는 정도에 있다. 처리 시간의 변동폭은 지터(jitter)(실제 신호와 기준점과의 시간 편차)라 부른다. 경성(hard) 실시간 운영체제와 연성(soft) 실시간 운영체제로 구분할 수 있으며, 전자가 후자에 비해 지터가 적다. RTOS의 주된 설계 목표는 높은 처리율(throughput)이 아니라, 실시간 성능 보장에 있다. 실시간 시스템의 데드라인을 대체로 맞추는 RTOS를 연성 실시간 운영체제라 하고, 데드라인을 결정론적 알고리즘(deterministic algorithm)에 의해 만족하는 경우를 경성 실시간 운영체제라 한다.규모가 큰 실시간 운영체제의 초기 예는 "제어 프로그램"이었는데, 이는 아메리칸 항공(American Airlines)과 IBM이 세이버(Sabre) 항공 예약 시스템을 위해서 개발한 것이었다.