임베디드 OS란 무엇인가
2009.08.15 17:58
출처 : http://wedcum.egloos.com/
임베디드 OS에는 어떤 것들이 있는가
임베디드 시스템을 개발하려면 개발하려는 시스템이 어떠한 기능을 수행하는지 그 복잡도는 어느 정도인지 실시간성을 요구하는지 개발기간은 얼마나 필요한지 등에 따라 적당한 임베디드 OS를 선택하여 적용해야 한다. 따라서 그러한 임베디드 OS에는 어떠한 것들이 있으며 각각의 특징이 무엇인지 알 필요가 있다. 현재 나온 임베디드 OS는 그 종류가 무수하게 많은 편이다. 데스크톱 시장처럼 특정 OS가 임베디드 OS 시장을 점유하는 것이 아니기 때문이다. 수많은 임베디드 OS 중에서 주류를 이루고 있는 상용 RTOS, 윈도우 CE 닷넷, 윈도우 XP 임베디드, 임베디드 리눅스에 대해서 알아보겠다.
상용 RTOS
RTOS는 그 종류만 해도 수를 헤아리기 힘들다. RTOS는 실시간 처리에 대한 강력한 지원과 통합 개발 및 디버깅 환경을 지원한다. 대표적으로 화성 착륙선인 패스파인더(PathFinder)와 혼다에서 만든 로봇인 아시모(ASIMO)의 운영체제로 쓰인 윈드리버(WindRiver)의 VxWorks, ISI에서 개발해서 지금은 윈드리버에 통합된 pSOS, Mentor Graphics의 VRTX 등이 있으며 교육용으로 만들어진 uC/OS-II가 있다. 이들 RTOS는 선점형 멀티태스킹을 지원하며 각 태스크들은 우선순위를 가지고 있어 높은 우선순위를 가지는 태스크들이 먼저 실행되는 구조를 가지고 있다. 또한 통합개발환경과 디버깅 툴을 개발하여 개발자들에게 용이한 개발환경을 지원하고 있다. 단점이라고 하면 이들 RTOS들이 대부분이 상용이라 라이선스 비가 만만치 않다.
pSOS
ISI에서 1980년대에 개발한 pSOSystem은 우리나라의 여러 업체가 채택해서 사용하고 있는 RTOS로 삼성전자가 pSOS+ 개발에 참여해 라이선스를 갖고 있어 잘 알려져 있다. 삼성전자의 휴대폰에 사용되어 왔으며, 각종 통신장비와 네트워크 장비에서 사용되고 있다. pSOSystem은 커널을 중심으로 해서 여러 개의 소프트웨어 컴포넌트들로 구성되어 있다. 이들 소프트웨어 컴포넌트들은 각각의 독립적인 모듈로 되어 있으며 통합개발환경 툴로 pRISM+을 제공하고 있다.
pSOSystem은 멀티태스킹 RTOS로 각 태스크들은 우선순위를 가지고 있어 우선순위가 높은 태스크들의 작업 수행이 먼저 이루어진다. 따라서 선점형 스케쥴링 방식을 따른다고 볼 수 있다. 만일 각 태스크들이 같은 우선순위를 가진다면 스케쥴링 방식은 라운드로빈(Round-robin) 방식으로 바뀌게 된다. 태스크의 수는 총 256개이다. 그리고 태스크 관리, 세마포어(semaphore), 메시지 큐, 시간 관리 및 타이머, 이벤트 및 비동기 시그널, 에러 처리, 동적인 메모리 저장관리, 다른 태스크들로부터의 코드나 데이터 보호 등의 서비스를 지원한다. 여러 개의 다른 실행 모드를 가지고 있는 CPU를 위해서 사용자 모드와 슈퍼바이저 모드를 제공하고 있다.
pSOSystem은 실시간 멀티태스킹 커널을 중심으로 여러 개의 소프트웨어 컴포넌트와 라이브러리를 두고 있다. 이런 컴포넌트와 라이브러리는 선택적으로 사용될 수 있다. 하부 구조에는 디바이스 드라이버와 칩과 각종 디바이스의 정보를 담고 있는 BSP(Board Support Package)가 있다. BSP를 따로 구별하는 이유는 만일 하드웨어가 변경될 경우 시스템 프로그램에 큰 변경없이 BSP만 수정하여 쉽게 처리할 수 있기 때문이다. 따라서 전체적으로 정리해 보면 BSP와 디바이스 드라이버의 바탕 위에 커널과 기타 필요한 컴포넌트들을 링크하고, 다시 그 위에 사용할 각종 태스크와 응용 프로그램을 제작하여 사용하는 것이다. pRISM+는 pSOSystem 개발자가 좀더 용이한 개발을 위해 소스 코드 분석을 위한 툴과 컴파일러, 링커, 디버깅할 수 있는 툴을 제공하는 통합개발환경이다.
VxWorks
윈드리버의 RTOS인 VxWorks는 pSOSystem과 유사한 점이 많다. pSOSystem이 통합개발환경으로 pRISM+를 제공한다면 VxWorks는 토네이도를 제공한다. VxWorks의 커널인 마이크로커널은 선점형 멀티태스킹이며 총 태스크의 단계는 256, 스케쥴링 방식도 높은 우선순위를 가지는 태스크가 먼저 실행하는 방식을 지원한다. 만일 같은 우선순위를 가진다면 라운드로빈 방식의 스케쥴링을 이용하는 것도 pSOSystem과 유사하다. 또 하나 pSOSystem이 여러 개의 컴포넌트로 되어 있다고 하면 VxWorks는 200개 가량이 모듈을 지원하는 형식으로 되어 있어 개발자는 이들 필요한 모듈만 사용해서 시스템에 맞는 운영체제를 구성할 수 있다. VxWorks는 현대의 RTOS들이 지원하는 거의 모든 서비스를 지원하고 있다. 태스크간의 통신을 위해 세마포어와 메시지 큐, 공유 메모리, 소켓, 시그널 등을 제공하고, 표준 TCP/IP 네트워킹과 ROM이나 로컬 디스크, 네트워크로 부팅이 가능하게 되어 있다.
VxWorks의 구조는 크게 하드웨어에 의존하는 BSP, 디바이스 드라이브 영역과 하드웨어에 의존하지 않는 커널과 그에 따른 모듈, 그리고 애플리케이션 프로그램으로 나뉜다. 이것은 pSOSystem과 매우 유사한 부분이다. VxWorks의 토네이도는 교차 개발환경을 지원하는 통합개발환경이다.
윈도우 CE 닷넷과 윈도우 XP 임베디드
마이크로소프트(이하 MS)는 임베디드 시장에 대한 공략을 위해 1996년 윈도우 CE를 발표했다. MS에서 제작된 기존의 윈도우 인터페이스에 모바일 네트워크 기능을 강화해 가전제품, PDA, 셋톱박스 등에 주로 사용되고 있다. 적외선 통신, 웹 브라우징 기능 이외에도 편리한 개발환경을 가지고 있으며 UI가 기존의 윈도우와 매우 유사하게 제작돼 있어 대부분의 사용자들은 별도의 학습없이도 바로 사용이 가능하다. 또한 윈도우 CE 계열의 PDA는 흑백 및 컬러 디스플레이가 가능하며 동영상, WAV, MP3 등 멀티미디어 파일의 재생이 가능하여 PDA의 엔터테인먼트 기기화를 가져왔다.
또한 PC용의 윈도우 OS나 각종 오피스 프로그램들과 완벽한 호환이 가능해 기존의 데스크톱이나 노트북에서 가능하던 각종 애플리케이션들을 PDA에서도 그대로 사용할 수 있다는 이점이 있다. 그러나 제한적인 하드웨어를 가진 임베디드 시스템에 너무 많은 기능을 구현하려 했기 때문에 느린 실행 속도와 불편한 UI를 초래했다.
이를 개선해 MS는 2000년 4월 윈도우 CE 3.0을 개발하고 기존의 윈도우 CE와는 전혀 다른 것이라는 것을 강조하기 위해 그것을 포켓PC(PocketPC)라고 명명했다. 포켓PC의 등장으로 기존 윈도우 CE에서 보여주었던 수행속도의 저하와 비효율적인 하드웨어의 활용 등의 문제점들이 보완됐다. 윈도우 PC는 사운드와 동영상 재생 및 컬러 디스플레이 구현 등 다양한 멀티미디어 기능을 기본적으로 제공하며 PC와의 호환성이 뛰어나다. 또한 포켓 인터넷 익스플로러를 기본으로 내장해 모바일 인터넷을 실현했다. 게다가 데스크톱과 거의 흡사한 UI를 갖춤으로써 윈도우에 익숙한 사용자들을 쉽게 끌어들이고 있다. 그럼에도 불구하고 PDA 업계에서 윈도우 CE의 시장점유율은 팜 OS에 미치지 못했다. 하지만 유명 PDA 업체들이 윈도우 CE 채용 제품들을 대거 출시함에 따라 점유율은 계속 증가 추세에 있다.
MS는 윈도우 CE 3.0의 소스 코드를 공개한 후 2002년 초 코드명 탈리스커(Talisker)로 알려졌던 윈도우 CE 닷넷과 윈도우 XP 임베디드를 공식 발표했다. MS는 윈도우 CE 닷넷을 Non-X86 프로세서 계열이거나 실시간이 요구되는 시스템에 대해서 권고를 하고 있으며 PC 운영체제인 윈도우 XP 프로페셔널의 컴포넌트 버전인 윈도우 XP 임베디드는 네트워킹과 서버 기능을 수행하는 시스템 개발에 권고를 하고 있다.
임베디드 리눅스
리눅스는 초기 PC나 서버급 시스템에 포팅돼 사용되기 시작하다 현재는 임베디드 시스템으로도 많이 사용된다. 리눅스는 상용 임베디드 OS보다는 실시간적 요소를 충족하지 못하고 윈도우 CE보다는 개발환경이 좋지는 않지만, 오픈소스에 라이선스 비용이 없기 때문에 커널 크기를 줄여 다양한 임베디드 시스템의 개발에 유리하다. 리눅스는 소스를 공개하는 오픈소스 정책을 따르는 관계로 관련 개발자가 세계 곳곳에 있어 현지의 응용 프로그램을 개발할 수 있는 개발자 층이 넓다는 것이 다른 OS들과 구별되는 큰 장점이다. 이에 따라 리눅스를 채용한 임베디드 시스템은 다른 제품에 비해 가격 경쟁력이 우수하고 다양한 응용 프로그램의 개발이 가능할 것으로 기대된다. 임베디드 리눅스는 소스 공개와 아울러 안정성, 신뢰성 및 성능의 확보에 따라 활용도가 급격히 증대되고 있으며, 레드햇, 몬타비스타, 리니오 등이 임베디드 리눅스 개발 및 기술 지원 사업에 주력하고 있다.
그러나 임베디드 리눅스는 열악한 개발환경에 따른 개발기간에 대한 부담과 라운드로빈 방식의 스케쥴링을 하므로 실시간 시스템에는 적합하지 않다는 문제점을 가지고 있다. New Mexico Tech에서 기존 리눅스 커널에 실시간 기능을 추가한 RT-Linux를 개발했으며 또한 오픈소스 진영에서는 임베디드 리눅스를 기반으로 한 표준화를 통해 시장 확대를 도모중인데, 2000년에 애질런트, 알카텔, HP, IBM, 윈드리버, ARM, 모토롤라 등이 참여하는 세계 최대 규모의 임베디드 리눅스 컨소시엄(ELC: Embedded Linux Consortium)이 결성되어 임베디드 리눅스 및 실시간 운영체제 API 표준인 EL/IX(Em bedded Linux based on POSIX)를 기반으로 플랫폼 표준화를 추진하고 있다.
임베디드 운영체제 시장은 전통적인 RTOS 중심에서 다기능 임베디드 OS 중심으로 발전하는 추세에 따라 VxWorks, pSOS 등의RTOS의 시장 성장율이 둔화되고 있으며, 전용 실시간 임베디드 시스템에서 높은 시장 점유율을 보였던 VxWorks, pSOS, VRTX와 같은 전통적인 RTOS는 2001년을 기점으로 시장 점유율이 하락하고 있다. <그림 1>에서와 같이 2003년에는 임베디드 리눅스, 임베디드 윈도우 CE 및 팜 OS 등의 임베디드 OS 시장이 기존의 RTOS 시장을 능가할 것으로 예측된다. 전통적인 RTOS의 시장 점유 하락으로 임베디드 OS 시장에서는 MS와 임베디드 리눅스가 시장 선점을 위해 치열한 각축을 벌일 것으로 예상된다.
임베디드 시스템 개발 환경
임베디드 시스템을 개발하기 위해선 기본적으로 <그림 2>와 같은 요소들이 갖춰져 있어야 한다. ‘호스트’는 임베디드 시스템 개발을 위한 컴퓨터를 말하며, ‘타겟’은 실제 임베디드 시스템이 설치된 개발하고자 하는 하드웨어를 말한다. 호스트에는 개발을 위한 개발 툴, 개발된 응용 프로그램을 임시로 수행해 볼 수 있는 타겟 시뮬레이터, 타겟과 연결되어 타겟에 개발된 이미지를 업로드하거나 타겟에 반응하는 디버그 에이전트를 통해 원격 디버깅을 할 수 있게 하는 타겟 서버가 설치돼 있다. 또한 타겟에는 호스트에서 만들어져서 설치된 여러 컴포넌트가 존재하는데 타겟을 부팅하기 위한 부트 로더와 커널, 그리고 임베디드 응용 프로그램이 존재하게 된다. 호스트에 설치된 개발 툴에는 타겟에서 수행될 수 있는 바이너리를 생성하는 크로스 컴파일러가 존재하며 그 밖에 오류를 검색해 주는 디버거 등으로 이뤄져 있다.
임베디드 시스템 개발 과정
임베디드 시스템 개발 과정은 대략적으로 부트로더 개발, 커널 및 파일 시스템 개발, 응용 프로그램 개발의 세 단계로 볼 수 있다.
부트 로더 개발
부트 로더는 타겟 보드에 전원이 인가되면 부트 롬으로부터 가장 먼저 수행되는 프로그램이다. 보통 부트 로더는 OS의 커널을 로드하는 순수 로더로서의 기능뿐만이 아니라 현재 레지스터나 메모리 값, 버스 상태 등을 살펴볼 수 있는 모니터 기능, 기초적인 네트워크 모듈을 내장해 네트워크를 통한 커널을 다운받아서 커널 로드를 할 수 있는 기능을 포괄하고 있다.부트 로더는 보통 부트 롬에 내장되어 있으며 부트 로더를 새로 작성하여 타겟에 설치하려면 호스트와 JTAG 인터페이스 혹은 기타 인터페이스를 통하여 설치할 수 있으며 이외의 방법에는 롬 라이터를 이용하여 롬에 구워서 설치할 수 있다.
대부분 상용 임베디드 OS에서는 부트 롬 부분을 앞서 잠깐 언급한 BSP라 불리는 패키지의 일부분으로 규정하고 있다. 반면 임베디드 리눅스의 경우는 규격화된 BSP가 존재하지 않으므로 하드웨어 벤더가 리눅스용 BSP를 제공하지 않을 경우 부트 롬 부분을 각 하드웨어 플랫폼에 맞게 작성해야 한다.
커널 및 디바이스 드라이버 및 파일 시스템 개발
커널 및 디바이스 드라이버의 개발은 호스트의 임베디드 시스템 개발 툴에서 이뤄진다. 개발을 위해서는 개발자가 먼저 시스템에 대한 하드웨어 사양을 숙지해야 하며 이를 바탕으로 커널 및 디바이스 드라이버를 설정하게 된다. 이렇게 생성된 커널 및 디바이스 드라이버들은 부트 롬과 같이 하나의 이미지 파일 형태로 되어 부트 롬에 저장되거나 별도의 저장 장치에 파일 시스템을 통한 파일 형태로 구현된다. 만일 부트 롬의 용량이 작거나 기타 저장장치가 없는 경우 부트 로더에서 네트워크 모듈을 통해 별도의 서버로부터 커널을 다운받아 부팅이 진행될 수도 있다. 특히 부트 롬이나 저장장치의 용량이 제한적일 경우는 커널 이미지 자체를 압축해 저장되는 것이 일반적이다.
임베디드 응용 프로그램
임베디드 응용 프로그램은 앞에서 구현된 커널과 파일 시스템을 바탕으로 수행된다. 응용 프로그램의 개발은 커널과 마찬가지 방법으로 호스트에서 생성이 가능하며 호스트에 설치된 개발 툴의 크로스 컴파일러에 의해 타겟 보드에 맞는 바이너리가 생성되게 된다. 생성된 응용 프로그램의 실행은 임베디드 OS 개발 툴 내의 타겟 에뮬레이터나 실제로 타겟 보드에 옮겨서 실행이 가능하다. 또한 응용 프로그램은 네트워크를 이용한 원거리 디버깅을 이용하거나, JTAG 인터페이스를 이용한 디버깅을 통하여 에러를 확인해 볼 수 있다.
임베디드 OS의 주요 개념 및 테크&팁
임베디드 시스템의 성능이 커지면서 기존에 간단한 펌웨어 형식으로 구현되었던 임베디드 프로그램이 점차 해야 할 일이 많아지고 복잡하게 된다. 이는 순차적인 프로그램으로는 해결하기 어려운 단계로 발전하고 결국 임베디드 시스템에도 운영체제의 개념이 필요하게 된다. 임베디드 시스템의 대부분 특성상 실시간이라는 요소를 만족해야 하는 점 때문에 많은 임베디드 OS는 RTOS의 속성을 가진다. 다음에 설명하는 주요 개념들은 여러분이 임베디드 OS를 이용해 임베디드 시스템을 개발하기 위하여 반드시 알아두어야 할 여러 개념 중 중요한 개념들을 선정하여 설명한 것이다.
스케쥴러
임베디드 OS는 보통 태스크(Task)라 불리는 프로그램 수행 단위를 가지게 된다. 보통 임베디드 시스템에서는 복수 개의 태스크가 동시에 수행되는 환경을 가지게 되며 이때 OS 내부의 스케쥴러에 의해서 다음 번에 수행되어야 할 태스크를 선택하게 된다. 이때 사용되는 임베디드 OS의 스케쥴링 알고리즘으로는 다양한 알고리즘이 나와 있지만 구현상의 문제 등으로 인해 실제 대부분의 임베디드 OS에서는 우선순위에 기반을 둔 스케쥴링 알고리즘을 사용한다.
대표적인 우선순위 알고리즘으로 FIFO(First In First Out)와 라운드로빈 방식이 있다. FIFO의 알고리즘은 동일한 우선순위를 가진 태스크들이 존재시 먼저 시작한 태스크가 종료될 때까지 다음 번 수행된 태스크가 스케쥴링을 받지 못하는 스케쥴링 알고리즘이며, 라운드로빈 방식은 동일한 우선순위를 가진 태스크들이 존재할 경우 각각 미리 정해진 타임슬라이스(time-slice)만큼씩 차례로 스케쥴링이 되는 알고리즘이다.
프리엠티브 커널
프리엠티브 커널(Preemptive kernel)은 어떤 태스크가 수행되고 있을 경우 커널이 강제로 그 태스크의 수행을 중지시키고 다른 태스크의 기능을 수행시킬 수 있는 능력을 지닌 커널을 말한다. Non-pree mptive 커널에 비해 interrupt latency가 조금 길어지는 단점이 있긴 하지만 대부분의 임베디드 OS에서 프리엠티브 커널을 채택하는 이유는 우선순위가 높은 태스크가 먼저 수행될 수 있다는 점 때문이다. 이는 결국 커널의 안정성을 높게 유지시킨다는 점에서 좋은 점이 될 수 있다.
상호 배제
하나의 태스크가 한 자원을 점유하여 사용중에 또다른 태스크가 접근하여 사용중인 자원에 무단으로 접근 시도 변경을 가한다면 곧 그 자원은 예측불허의 상황으로 치달을 수밖에 없다. 이런 부분을 임계 지역(critical section)이라 명하며, 한 자원이 점유중일 경우 나머지 자원들은 점유하고 있던 태스크가 자원을 모두 사용하고 사용권을 반환하기 전까지 모두 접근이 지연돼야 하는 지역을 말한다. 따라서 임계 지역은 상호 배제(mutual exclusion)로써 보호해야 하며 임베디드 OS는 상호 배제를 위해 인터럽트 Enable/Disable이나 세마포어의 기능으로 임계 지역을 보호할 수 있다.
태스크 커뮤니케이션
임베디드 OS에서의 태스크들은 종종 서로 데이터를 교환해야 할 경우가 생기게 된다. 이럴 경우 태스크간 통신을 통하여 교환할 수 있으며 이 기능은 OS에서 지원하는 여러 도구들에 의해 수행이 된다. 대표적인 방법으로는 시스템 전역의 변수를 선언하여 사용방법이 있으나 이 경우에는 변수 자체가 임계 지역이 되므로 인터럽트 Enable/ Disable이나 세마포어 등으로 상호 배제를 해야 한다. 그 밖의 방법으로는 큐, 파이프, 메일박스, 공유 메모리 등이 있으며 이들은 커널에 의해 자동으로 상호 배제가 이루어짐으로 임계 지역이 보호된다.
[ 임베디드 환경의 파일 시스템 ]
파일 시스템이란 저장장치에 파일을 관리하는 시스템을 말한다. 임베디드 시스템에서 주로 사용하는 저장장치는 보통 네트워크를 통한 외부 서버의 저장장치, 타겟 내의 일반 메모리 및 플래시 메모리 등을 말하며 각각 장치의 특성상 다른 파일 시스템이 올라가게 된다. 외부 서버로부터는 저장 장치에 대한 파일 시스템으로는 NFS(Network File System)라는 것이 있는데, 이는 네트워크를 통해 마치 외부 서버의 파일 시스템을 로컬의 파일 시스템처럼 사용할 수 있게 해주는 파일 시스템이다.
일반 메모리에 대한 파일 시스템은 RAMFS(RAm File System)이라 하여 보통 부트 롬 내에 파일 시스템 이미지를 저장해두고 시스템이 부팅시 일반 메모리에 그 파일들을 모두 복사한 다음 RAMFS를 통하여 파일을 유지 관리하는 파일 시스템이다. 단 일반 메모리에 구현돼 있으므로 타겟의 전원이 없어지면 그 내용이 소실된다.
플래시 메모리는 일반 메모리와는 다르게 전원이 나가도 그 내용이 보전되는 특성이 있으므로 한번 파일 시스템이 구현되면 그 내용이 보존되는 특징이 있다. 하지만 플래시 메모리의 특성상 기록 및 삭제의 횟수 제한이 있으므로 파일 시스템 내에서 이를 효율적으로 관리해 주는 부분이 고려되어야 한다.
[ 세마포어 ]
세마포어(semaphore)는 60년대 중반 Dijkstra가 고안한 메커니즘이다. 이는 태스크간에 상호 공유하는 변수이며, 임계 지역을 세마포어로 보호하면 태스크간 상호 배제을 구현할 수 있다. 기본적인 알고리즘은 먼저 세마포어 변수를 선언한 후 임계 지역에 전에 세마포어를 얻기를 시도한다. 만일 아무도 세마포어 얻기를 시도하지 않았으면 바로 임계 지역에 들어갈 수 있으나 다른 태스크가 세마포어를 얻어서 임계 지역에 있으면 나중에 시도한 태스크는 세마포어를 풀어줄 때까지 블럭 상태로 되게 된다. 이후 세마포어가 풀리면 블럭된 태스크는 세마포어를 얻어 임계 지역에 진입할 수 있게 된다.
세마포어는 초기화시 동시에 진입할 수 있는 개수를 명시할 수 있는데 그 개수가 하나인 세마포어에 대하여 바이너리 세마포어(binary semaphore)라 하며 그 이상의 값을 명시하면 카운팅 세마포어(counting semaphore)라 한다.
[ JTAG란? ]
JTAG(Joint Test Access Group)는 IEEE 표준 1149.1-1990 Test Access Port and Boundary-Scan Architecture에 근거한 규격으로 CPU에서 직접 지원하는 디버깅을 위한 인터페이스로 현재 CPU의 상태를 점검하거나 프로그램의 디버깅, 플래시 메모리에 새로운 자료를 저장할 때 주로 사용한다.
Priority Inversion
낮은 우선순위를 가진 태스크에 의해 높은 우선순위를 가진 태스크가 블럭되어 수행이 되지 않는 현상을 말한다. 이러한 우선 순위 역전 현상은 시스템의 schedulability와 predictability를 떨어뜨려 결국 시스템을 불안정하게 만드는 원인이 되기도 한다. 일부 임베디드 OS에서는 OS 차원에서 priority inheritance를 이용하여 해결하기도 하나, 가장 안전한 방법은 태스크들을 디자인할 경우 그러한 상황이 벌어지지 않도록 설계를 하는 것이다. 보통 이를 막기 위해 같은 세마포어를 쓰는 태스크들 사이에는 같은 우선순위를 주는 등의 방법을 사용한다.
Priority Inheritance
우선 순위 역전현상을 피하는 방법으로 예를 들면 태스크 T2가 특정 리소스를 점유하고 있는 상태에서 우선순위가 높은 T1이 같은 리소스에 접근할 경우 우선순위 역전현상이 나타난다. 이때 이 리소스를 대기하고 있는 가장 큰 우선순위인 T2의 우선순위만큼 T1이 우선순위를 상속(inheritance)받아서 그 우선순위의 값을 유지한 상태로 리소스를 점유하게 된다. 이후 해당 리소스를 모두 사용한 후에는 다시 원래의 T1의 우선순위 값으로 환원된다.
임베디드 OS에는 어떤 것들이 있는가
임베디드 시스템을 개발하려면 개발하려는 시스템이 어떠한 기능을 수행하는지 그 복잡도는 어느 정도인지 실시간성을 요구하는지 개발기간은 얼마나 필요한지 등에 따라 적당한 임베디드 OS를 선택하여 적용해야 한다. 따라서 그러한 임베디드 OS에는 어떠한 것들이 있으며 각각의 특징이 무엇인지 알 필요가 있다. 현재 나온 임베디드 OS는 그 종류가 무수하게 많은 편이다. 데스크톱 시장처럼 특정 OS가 임베디드 OS 시장을 점유하는 것이 아니기 때문이다. 수많은 임베디드 OS 중에서 주류를 이루고 있는 상용 RTOS, 윈도우 CE 닷넷, 윈도우 XP 임베디드, 임베디드 리눅스에 대해서 알아보겠다.
상용 RTOS
RTOS는 그 종류만 해도 수를 헤아리기 힘들다. RTOS는 실시간 처리에 대한 강력한 지원과 통합 개발 및 디버깅 환경을 지원한다. 대표적으로 화성 착륙선인 패스파인더(PathFinder)와 혼다에서 만든 로봇인 아시모(ASIMO)의 운영체제로 쓰인 윈드리버(WindRiver)의 VxWorks, ISI에서 개발해서 지금은 윈드리버에 통합된 pSOS, Mentor Graphics의 VRTX 등이 있으며 교육용으로 만들어진 uC/OS-II가 있다. 이들 RTOS는 선점형 멀티태스킹을 지원하며 각 태스크들은 우선순위를 가지고 있어 높은 우선순위를 가지는 태스크들이 먼저 실행되는 구조를 가지고 있다. 또한 통합개발환경과 디버깅 툴을 개발하여 개발자들에게 용이한 개발환경을 지원하고 있다. 단점이라고 하면 이들 RTOS들이 대부분이 상용이라 라이선스 비가 만만치 않다.
pSOS
ISI에서 1980년대에 개발한 pSOSystem은 우리나라의 여러 업체가 채택해서 사용하고 있는 RTOS로 삼성전자가 pSOS+ 개발에 참여해 라이선스를 갖고 있어 잘 알려져 있다. 삼성전자의 휴대폰에 사용되어 왔으며, 각종 통신장비와 네트워크 장비에서 사용되고 있다. pSOSystem은 커널을 중심으로 해서 여러 개의 소프트웨어 컴포넌트들로 구성되어 있다. 이들 소프트웨어 컴포넌트들은 각각의 독립적인 모듈로 되어 있으며 통합개발환경 툴로 pRISM+을 제공하고 있다.
pSOSystem은 멀티태스킹 RTOS로 각 태스크들은 우선순위를 가지고 있어 우선순위가 높은 태스크들의 작업 수행이 먼저 이루어진다. 따라서 선점형 스케쥴링 방식을 따른다고 볼 수 있다. 만일 각 태스크들이 같은 우선순위를 가진다면 스케쥴링 방식은 라운드로빈(Round-robin) 방식으로 바뀌게 된다. 태스크의 수는 총 256개이다. 그리고 태스크 관리, 세마포어(semaphore), 메시지 큐, 시간 관리 및 타이머, 이벤트 및 비동기 시그널, 에러 처리, 동적인 메모리 저장관리, 다른 태스크들로부터의 코드나 데이터 보호 등의 서비스를 지원한다. 여러 개의 다른 실행 모드를 가지고 있는 CPU를 위해서 사용자 모드와 슈퍼바이저 모드를 제공하고 있다.
pSOSystem은 실시간 멀티태스킹 커널을 중심으로 여러 개의 소프트웨어 컴포넌트와 라이브러리를 두고 있다. 이런 컴포넌트와 라이브러리는 선택적으로 사용될 수 있다. 하부 구조에는 디바이스 드라이버와 칩과 각종 디바이스의 정보를 담고 있는 BSP(Board Support Package)가 있다. BSP를 따로 구별하는 이유는 만일 하드웨어가 변경될 경우 시스템 프로그램에 큰 변경없이 BSP만 수정하여 쉽게 처리할 수 있기 때문이다. 따라서 전체적으로 정리해 보면 BSP와 디바이스 드라이버의 바탕 위에 커널과 기타 필요한 컴포넌트들을 링크하고, 다시 그 위에 사용할 각종 태스크와 응용 프로그램을 제작하여 사용하는 것이다. pRISM+는 pSOSystem 개발자가 좀더 용이한 개발을 위해 소스 코드 분석을 위한 툴과 컴파일러, 링커, 디버깅할 수 있는 툴을 제공하는 통합개발환경이다.
VxWorks
윈드리버의 RTOS인 VxWorks는 pSOSystem과 유사한 점이 많다. pSOSystem이 통합개발환경으로 pRISM+를 제공한다면 VxWorks는 토네이도를 제공한다. VxWorks의 커널인 마이크로커널은 선점형 멀티태스킹이며 총 태스크의 단계는 256, 스케쥴링 방식도 높은 우선순위를 가지는 태스크가 먼저 실행하는 방식을 지원한다. 만일 같은 우선순위를 가진다면 라운드로빈 방식의 스케쥴링을 이용하는 것도 pSOSystem과 유사하다. 또 하나 pSOSystem이 여러 개의 컴포넌트로 되어 있다고 하면 VxWorks는 200개 가량이 모듈을 지원하는 형식으로 되어 있어 개발자는 이들 필요한 모듈만 사용해서 시스템에 맞는 운영체제를 구성할 수 있다. VxWorks는 현대의 RTOS들이 지원하는 거의 모든 서비스를 지원하고 있다. 태스크간의 통신을 위해 세마포어와 메시지 큐, 공유 메모리, 소켓, 시그널 등을 제공하고, 표준 TCP/IP 네트워킹과 ROM이나 로컬 디스크, 네트워크로 부팅이 가능하게 되어 있다.
VxWorks의 구조는 크게 하드웨어에 의존하는 BSP, 디바이스 드라이브 영역과 하드웨어에 의존하지 않는 커널과 그에 따른 모듈, 그리고 애플리케이션 프로그램으로 나뉜다. 이것은 pSOSystem과 매우 유사한 부분이다. VxWorks의 토네이도는 교차 개발환경을 지원하는 통합개발환경이다.
윈도우 CE 닷넷과 윈도우 XP 임베디드
마이크로소프트(이하 MS)는 임베디드 시장에 대한 공략을 위해 1996년 윈도우 CE를 발표했다. MS에서 제작된 기존의 윈도우 인터페이스에 모바일 네트워크 기능을 강화해 가전제품, PDA, 셋톱박스 등에 주로 사용되고 있다. 적외선 통신, 웹 브라우징 기능 이외에도 편리한 개발환경을 가지고 있으며 UI가 기존의 윈도우와 매우 유사하게 제작돼 있어 대부분의 사용자들은 별도의 학습없이도 바로 사용이 가능하다. 또한 윈도우 CE 계열의 PDA는 흑백 및 컬러 디스플레이가 가능하며 동영상, WAV, MP3 등 멀티미디어 파일의 재생이 가능하여 PDA의 엔터테인먼트 기기화를 가져왔다.
또한 PC용의 윈도우 OS나 각종 오피스 프로그램들과 완벽한 호환이 가능해 기존의 데스크톱이나 노트북에서 가능하던 각종 애플리케이션들을 PDA에서도 그대로 사용할 수 있다는 이점이 있다. 그러나 제한적인 하드웨어를 가진 임베디드 시스템에 너무 많은 기능을 구현하려 했기 때문에 느린 실행 속도와 불편한 UI를 초래했다.
이를 개선해 MS는 2000년 4월 윈도우 CE 3.0을 개발하고 기존의 윈도우 CE와는 전혀 다른 것이라는 것을 강조하기 위해 그것을 포켓PC(PocketPC)라고 명명했다. 포켓PC의 등장으로 기존 윈도우 CE에서 보여주었던 수행속도의 저하와 비효율적인 하드웨어의 활용 등의 문제점들이 보완됐다. 윈도우 PC는 사운드와 동영상 재생 및 컬러 디스플레이 구현 등 다양한 멀티미디어 기능을 기본적으로 제공하며 PC와의 호환성이 뛰어나다. 또한 포켓 인터넷 익스플로러를 기본으로 내장해 모바일 인터넷을 실현했다. 게다가 데스크톱과 거의 흡사한 UI를 갖춤으로써 윈도우에 익숙한 사용자들을 쉽게 끌어들이고 있다. 그럼에도 불구하고 PDA 업계에서 윈도우 CE의 시장점유율은 팜 OS에 미치지 못했다. 하지만 유명 PDA 업체들이 윈도우 CE 채용 제품들을 대거 출시함에 따라 점유율은 계속 증가 추세에 있다.
MS는 윈도우 CE 3.0의 소스 코드를 공개한 후 2002년 초 코드명 탈리스커(Talisker)로 알려졌던 윈도우 CE 닷넷과 윈도우 XP 임베디드를 공식 발표했다. MS는 윈도우 CE 닷넷을 Non-X86 프로세서 계열이거나 실시간이 요구되는 시스템에 대해서 권고를 하고 있으며 PC 운영체제인 윈도우 XP 프로페셔널의 컴포넌트 버전인 윈도우 XP 임베디드는 네트워킹과 서버 기능을 수행하는 시스템 개발에 권고를 하고 있다.
임베디드 리눅스
리눅스는 초기 PC나 서버급 시스템에 포팅돼 사용되기 시작하다 현재는 임베디드 시스템으로도 많이 사용된다. 리눅스는 상용 임베디드 OS보다는 실시간적 요소를 충족하지 못하고 윈도우 CE보다는 개발환경이 좋지는 않지만, 오픈소스에 라이선스 비용이 없기 때문에 커널 크기를 줄여 다양한 임베디드 시스템의 개발에 유리하다. 리눅스는 소스를 공개하는 오픈소스 정책을 따르는 관계로 관련 개발자가 세계 곳곳에 있어 현지의 응용 프로그램을 개발할 수 있는 개발자 층이 넓다는 것이 다른 OS들과 구별되는 큰 장점이다. 이에 따라 리눅스를 채용한 임베디드 시스템은 다른 제품에 비해 가격 경쟁력이 우수하고 다양한 응용 프로그램의 개발이 가능할 것으로 기대된다. 임베디드 리눅스는 소스 공개와 아울러 안정성, 신뢰성 및 성능의 확보에 따라 활용도가 급격히 증대되고 있으며, 레드햇, 몬타비스타, 리니오 등이 임베디드 리눅스 개발 및 기술 지원 사업에 주력하고 있다.
그러나 임베디드 리눅스는 열악한 개발환경에 따른 개발기간에 대한 부담과 라운드로빈 방식의 스케쥴링을 하므로 실시간 시스템에는 적합하지 않다는 문제점을 가지고 있다. New Mexico Tech에서 기존 리눅스 커널에 실시간 기능을 추가한 RT-Linux를 개발했으며 또한 오픈소스 진영에서는 임베디드 리눅스를 기반으로 한 표준화를 통해 시장 확대를 도모중인데, 2000년에 애질런트, 알카텔, HP, IBM, 윈드리버, ARM, 모토롤라 등이 참여하는 세계 최대 규모의 임베디드 리눅스 컨소시엄(ELC: Embedded Linux Consortium)이 결성되어 임베디드 리눅스 및 실시간 운영체제 API 표준인 EL/IX(Em bedded Linux based on POSIX)를 기반으로 플랫폼 표준화를 추진하고 있다.
임베디드 운영체제 시장은 전통적인 RTOS 중심에서 다기능 임베디드 OS 중심으로 발전하는 추세에 따라 VxWorks, pSOS 등의RTOS의 시장 성장율이 둔화되고 있으며, 전용 실시간 임베디드 시스템에서 높은 시장 점유율을 보였던 VxWorks, pSOS, VRTX와 같은 전통적인 RTOS는 2001년을 기점으로 시장 점유율이 하락하고 있다. <그림 1>에서와 같이 2003년에는 임베디드 리눅스, 임베디드 윈도우 CE 및 팜 OS 등의 임베디드 OS 시장이 기존의 RTOS 시장을 능가할 것으로 예측된다. 전통적인 RTOS의 시장 점유 하락으로 임베디드 OS 시장에서는 MS와 임베디드 리눅스가 시장 선점을 위해 치열한 각축을 벌일 것으로 예상된다.
임베디드 시스템 개발 환경
임베디드 시스템을 개발하기 위해선 기본적으로 <그림 2>와 같은 요소들이 갖춰져 있어야 한다. ‘호스트’는 임베디드 시스템 개발을 위한 컴퓨터를 말하며, ‘타겟’은 실제 임베디드 시스템이 설치된 개발하고자 하는 하드웨어를 말한다. 호스트에는 개발을 위한 개발 툴, 개발된 응용 프로그램을 임시로 수행해 볼 수 있는 타겟 시뮬레이터, 타겟과 연결되어 타겟에 개발된 이미지를 업로드하거나 타겟에 반응하는 디버그 에이전트를 통해 원격 디버깅을 할 수 있게 하는 타겟 서버가 설치돼 있다. 또한 타겟에는 호스트에서 만들어져서 설치된 여러 컴포넌트가 존재하는데 타겟을 부팅하기 위한 부트 로더와 커널, 그리고 임베디드 응용 프로그램이 존재하게 된다. 호스트에 설치된 개발 툴에는 타겟에서 수행될 수 있는 바이너리를 생성하는 크로스 컴파일러가 존재하며 그 밖에 오류를 검색해 주는 디버거 등으로 이뤄져 있다.
임베디드 시스템 개발 과정
임베디드 시스템 개발 과정은 대략적으로 부트로더 개발, 커널 및 파일 시스템 개발, 응용 프로그램 개발의 세 단계로 볼 수 있다.
부트 로더 개발
부트 로더는 타겟 보드에 전원이 인가되면 부트 롬으로부터 가장 먼저 수행되는 프로그램이다. 보통 부트 로더는 OS의 커널을 로드하는 순수 로더로서의 기능뿐만이 아니라 현재 레지스터나 메모리 값, 버스 상태 등을 살펴볼 수 있는 모니터 기능, 기초적인 네트워크 모듈을 내장해 네트워크를 통한 커널을 다운받아서 커널 로드를 할 수 있는 기능을 포괄하고 있다.부트 로더는 보통 부트 롬에 내장되어 있으며 부트 로더를 새로 작성하여 타겟에 설치하려면 호스트와 JTAG 인터페이스 혹은 기타 인터페이스를 통하여 설치할 수 있으며 이외의 방법에는 롬 라이터를 이용하여 롬에 구워서 설치할 수 있다.
대부분 상용 임베디드 OS에서는 부트 롬 부분을 앞서 잠깐 언급한 BSP라 불리는 패키지의 일부분으로 규정하고 있다. 반면 임베디드 리눅스의 경우는 규격화된 BSP가 존재하지 않으므로 하드웨어 벤더가 리눅스용 BSP를 제공하지 않을 경우 부트 롬 부분을 각 하드웨어 플랫폼에 맞게 작성해야 한다.
커널 및 디바이스 드라이버 및 파일 시스템 개발
커널 및 디바이스 드라이버의 개발은 호스트의 임베디드 시스템 개발 툴에서 이뤄진다. 개발을 위해서는 개발자가 먼저 시스템에 대한 하드웨어 사양을 숙지해야 하며 이를 바탕으로 커널 및 디바이스 드라이버를 설정하게 된다. 이렇게 생성된 커널 및 디바이스 드라이버들은 부트 롬과 같이 하나의 이미지 파일 형태로 되어 부트 롬에 저장되거나 별도의 저장 장치에 파일 시스템을 통한 파일 형태로 구현된다. 만일 부트 롬의 용량이 작거나 기타 저장장치가 없는 경우 부트 로더에서 네트워크 모듈을 통해 별도의 서버로부터 커널을 다운받아 부팅이 진행될 수도 있다. 특히 부트 롬이나 저장장치의 용량이 제한적일 경우는 커널 이미지 자체를 압축해 저장되는 것이 일반적이다.
임베디드 응용 프로그램
임베디드 응용 프로그램은 앞에서 구현된 커널과 파일 시스템을 바탕으로 수행된다. 응용 프로그램의 개발은 커널과 마찬가지 방법으로 호스트에서 생성이 가능하며 호스트에 설치된 개발 툴의 크로스 컴파일러에 의해 타겟 보드에 맞는 바이너리가 생성되게 된다. 생성된 응용 프로그램의 실행은 임베디드 OS 개발 툴 내의 타겟 에뮬레이터나 실제로 타겟 보드에 옮겨서 실행이 가능하다. 또한 응용 프로그램은 네트워크를 이용한 원거리 디버깅을 이용하거나, JTAG 인터페이스를 이용한 디버깅을 통하여 에러를 확인해 볼 수 있다.
임베디드 OS의 주요 개념 및 테크&팁
임베디드 시스템의 성능이 커지면서 기존에 간단한 펌웨어 형식으로 구현되었던 임베디드 프로그램이 점차 해야 할 일이 많아지고 복잡하게 된다. 이는 순차적인 프로그램으로는 해결하기 어려운 단계로 발전하고 결국 임베디드 시스템에도 운영체제의 개념이 필요하게 된다. 임베디드 시스템의 대부분 특성상 실시간이라는 요소를 만족해야 하는 점 때문에 많은 임베디드 OS는 RTOS의 속성을 가진다. 다음에 설명하는 주요 개념들은 여러분이 임베디드 OS를 이용해 임베디드 시스템을 개발하기 위하여 반드시 알아두어야 할 여러 개념 중 중요한 개념들을 선정하여 설명한 것이다.
스케쥴러
임베디드 OS는 보통 태스크(Task)라 불리는 프로그램 수행 단위를 가지게 된다. 보통 임베디드 시스템에서는 복수 개의 태스크가 동시에 수행되는 환경을 가지게 되며 이때 OS 내부의 스케쥴러에 의해서 다음 번에 수행되어야 할 태스크를 선택하게 된다. 이때 사용되는 임베디드 OS의 스케쥴링 알고리즘으로는 다양한 알고리즘이 나와 있지만 구현상의 문제 등으로 인해 실제 대부분의 임베디드 OS에서는 우선순위에 기반을 둔 스케쥴링 알고리즘을 사용한다.
대표적인 우선순위 알고리즘으로 FIFO(First In First Out)와 라운드로빈 방식이 있다. FIFO의 알고리즘은 동일한 우선순위를 가진 태스크들이 존재시 먼저 시작한 태스크가 종료될 때까지 다음 번 수행된 태스크가 스케쥴링을 받지 못하는 스케쥴링 알고리즘이며, 라운드로빈 방식은 동일한 우선순위를 가진 태스크들이 존재할 경우 각각 미리 정해진 타임슬라이스(time-slice)만큼씩 차례로 스케쥴링이 되는 알고리즘이다.
프리엠티브 커널
프리엠티브 커널(Preemptive kernel)은 어떤 태스크가 수행되고 있을 경우 커널이 강제로 그 태스크의 수행을 중지시키고 다른 태스크의 기능을 수행시킬 수 있는 능력을 지닌 커널을 말한다. Non-pree mptive 커널에 비해 interrupt latency가 조금 길어지는 단점이 있긴 하지만 대부분의 임베디드 OS에서 프리엠티브 커널을 채택하는 이유는 우선순위가 높은 태스크가 먼저 수행될 수 있다는 점 때문이다. 이는 결국 커널의 안정성을 높게 유지시킨다는 점에서 좋은 점이 될 수 있다.
상호 배제
하나의 태스크가 한 자원을 점유하여 사용중에 또다른 태스크가 접근하여 사용중인 자원에 무단으로 접근 시도 변경을 가한다면 곧 그 자원은 예측불허의 상황으로 치달을 수밖에 없다. 이런 부분을 임계 지역(critical section)이라 명하며, 한 자원이 점유중일 경우 나머지 자원들은 점유하고 있던 태스크가 자원을 모두 사용하고 사용권을 반환하기 전까지 모두 접근이 지연돼야 하는 지역을 말한다. 따라서 임계 지역은 상호 배제(mutual exclusion)로써 보호해야 하며 임베디드 OS는 상호 배제를 위해 인터럽트 Enable/Disable이나 세마포어의 기능으로 임계 지역을 보호할 수 있다.
태스크 커뮤니케이션
임베디드 OS에서의 태스크들은 종종 서로 데이터를 교환해야 할 경우가 생기게 된다. 이럴 경우 태스크간 통신을 통하여 교환할 수 있으며 이 기능은 OS에서 지원하는 여러 도구들에 의해 수행이 된다. 대표적인 방법으로는 시스템 전역의 변수를 선언하여 사용방법이 있으나 이 경우에는 변수 자체가 임계 지역이 되므로 인터럽트 Enable/ Disable이나 세마포어 등으로 상호 배제를 해야 한다. 그 밖의 방법으로는 큐, 파이프, 메일박스, 공유 메모리 등이 있으며 이들은 커널에 의해 자동으로 상호 배제가 이루어짐으로 임계 지역이 보호된다.
[ 임베디드 환경의 파일 시스템 ]
파일 시스템이란 저장장치에 파일을 관리하는 시스템을 말한다. 임베디드 시스템에서 주로 사용하는 저장장치는 보통 네트워크를 통한 외부 서버의 저장장치, 타겟 내의 일반 메모리 및 플래시 메모리 등을 말하며 각각 장치의 특성상 다른 파일 시스템이 올라가게 된다. 외부 서버로부터는 저장 장치에 대한 파일 시스템으로는 NFS(Network File System)라는 것이 있는데, 이는 네트워크를 통해 마치 외부 서버의 파일 시스템을 로컬의 파일 시스템처럼 사용할 수 있게 해주는 파일 시스템이다.
일반 메모리에 대한 파일 시스템은 RAMFS(RAm File System)이라 하여 보통 부트 롬 내에 파일 시스템 이미지를 저장해두고 시스템이 부팅시 일반 메모리에 그 파일들을 모두 복사한 다음 RAMFS를 통하여 파일을 유지 관리하는 파일 시스템이다. 단 일반 메모리에 구현돼 있으므로 타겟의 전원이 없어지면 그 내용이 소실된다.
플래시 메모리는 일반 메모리와는 다르게 전원이 나가도 그 내용이 보전되는 특성이 있으므로 한번 파일 시스템이 구현되면 그 내용이 보존되는 특징이 있다. 하지만 플래시 메모리의 특성상 기록 및 삭제의 횟수 제한이 있으므로 파일 시스템 내에서 이를 효율적으로 관리해 주는 부분이 고려되어야 한다.
[ 세마포어 ]
세마포어(semaphore)는 60년대 중반 Dijkstra가 고안한 메커니즘이다. 이는 태스크간에 상호 공유하는 변수이며, 임계 지역을 세마포어로 보호하면 태스크간 상호 배제을 구현할 수 있다. 기본적인 알고리즘은 먼저 세마포어 변수를 선언한 후 임계 지역에 전에 세마포어를 얻기를 시도한다. 만일 아무도 세마포어 얻기를 시도하지 않았으면 바로 임계 지역에 들어갈 수 있으나 다른 태스크가 세마포어를 얻어서 임계 지역에 있으면 나중에 시도한 태스크는 세마포어를 풀어줄 때까지 블럭 상태로 되게 된다. 이후 세마포어가 풀리면 블럭된 태스크는 세마포어를 얻어 임계 지역에 진입할 수 있게 된다.
세마포어는 초기화시 동시에 진입할 수 있는 개수를 명시할 수 있는데 그 개수가 하나인 세마포어에 대하여 바이너리 세마포어(binary semaphore)라 하며 그 이상의 값을 명시하면 카운팅 세마포어(counting semaphore)라 한다.
[ JTAG란? ]
JTAG(Joint Test Access Group)는 IEEE 표준 1149.1-1990 Test Access Port and Boundary-Scan Architecture에 근거한 규격으로 CPU에서 직접 지원하는 디버깅을 위한 인터페이스로 현재 CPU의 상태를 점검하거나 프로그램의 디버깅, 플래시 메모리에 새로운 자료를 저장할 때 주로 사용한다.
Priority Inversion
낮은 우선순위를 가진 태스크에 의해 높은 우선순위를 가진 태스크가 블럭되어 수행이 되지 않는 현상을 말한다. 이러한 우선 순위 역전 현상은 시스템의 schedulability와 predictability를 떨어뜨려 결국 시스템을 불안정하게 만드는 원인이 되기도 한다. 일부 임베디드 OS에서는 OS 차원에서 priority inheritance를 이용하여 해결하기도 하나, 가장 안전한 방법은 태스크들을 디자인할 경우 그러한 상황이 벌어지지 않도록 설계를 하는 것이다. 보통 이를 막기 위해 같은 세마포어를 쓰는 태스크들 사이에는 같은 우선순위를 주는 등의 방법을 사용한다.
Priority Inheritance
우선 순위 역전현상을 피하는 방법으로 예를 들면 태스크 T2가 특정 리소스를 점유하고 있는 상태에서 우선순위가 높은 T1이 같은 리소스에 접근할 경우 우선순위 역전현상이 나타난다. 이때 이 리소스를 대기하고 있는 가장 큰 우선순위인 T2의 우선순위만큼 T1이 우선순위를 상속(inheritance)받아서 그 우선순위의 값을 유지한 상태로 리소스를 점유하게 된다. 이후 해당 리소스를 모두 사용한 후에는 다시 원래의 T1의 우선순위 값으로 환원된다.
본 웹사이트는 광고를 포함하고 있습니다.
광고 클릭에서 발생하는 수익금은 모두 웹사이트 서버의 유지 및 관리, 그리고 기술 콘텐츠 향상을 위해 쓰여집니다.
광고 클릭에서 발생하는 수익금은 모두 웹사이트 서버의 유지 및 관리, 그리고 기술 콘텐츠 향상을 위해 쓰여집니다.
