본문으로 이동

미디어위키 1.45 안정화가 거의 끝났습니다. 다만 Flow 확장 기능 관련 이슈가 있어서 대체하는 작업을 수행할 계획입니다.

  1. 큰숲백과:청사진에서 위키 발전의 대략적인 방향성을 제시했습니다. 의견이 있으신 분은 큰숲백과토론:청사진에서 의견을 남겨주시면 좋겠습니다.
  2. 기능상의 오류로 지원하지 않고 있는 기능에 대해서는 큰숲백과토론:이슈 트래커에 요약했습니다. 참고하시기 바랍니다.
  3. 데이터베이스 덤프 받고싶으신 분은 큰숲백과 가입 후에 사용자토론:Bigforest에 의견 남겨주시면 ftp 주소, 계정, 비밀번호를 특수:EmailUser를 통해서 공개할 예정입니다.

RTOS

큰숲백과, 나무를 보지 말고 큰 숲을 보라.

RTOS'(Real-Time Operating System)은 모든 종류의 데이터 처리 작업의 정시성을 보장하는 운영체제이다.

보통 사용자 안전에 민감한 Hard Real-Time(경성 실시간) 시스템으로 반드시 정해진 기한(Deadline) 안에 주어진 작업을 완료해야 하기 때문에 기능적인 정확성에 더해 시간적 정확성까지 전부 만족시켜야 한다. 그렇기 때문에 아예 작업을 무조건 제때 처리하는 데에 특화된 운영체제들이 여럿 나왔고, 이들을 RTOS라고 부르게 된 것이다.

또한 많은 프로그래밍 언어의 반복문(loop) 기능은 RTOS 내에서는 정시성을 위반할 여지가 있으므로 다중 태스크로 데이터 처리 작업을 분할하는 등의 회피 방법을 사용할 수 없을 때에야 한정적으로 사용하게 된다.

RTOS의 작업 처리

[편집 | 원본 편집]

RTOS는 프로세스 스케줄링 측면에서 윈도우즈 같은 범용 운영체제는 많은 차이를 보인다. 구체적인 태스크의 작동 시간을 수동으로 정하고 그 안에 모든 작업을 끝내지 못하면 무조건 시스템에 문제가 생겼다 판단하고 리부팅에 들어가는 사례가 있다.

비율 단조 스케줄링이라 하여 실행 빈도에 비례해 임의의 프로세스 사용률과 업데이트 속도를 가지는 태스크들이 존재하는 상황에서 다음 조건을 만족하면 타이밍 제약을 만족시키면서 주기적으로 태스크 스케줄링을 할 수 있다.

  • 단조성 있는 우선순위 배분: 자주 실행될 수록 실행 시간 배정 우선순위를 높인다.
  • 다른 태스크의 응답을 기다리면서 멈춤 상태에 있을 수 없다.
  • 태스크 스케줄링과 문맥전환을 수행하는 시간은 무시할 수 있다.
  • 총 프로세서 사용률이 많아야 n(21n-1)을 넘지 않는다(예: 12개의 태스크가 도는 시스템에서 12 x (2112 - 1) ≒ 72.35%). 이상적인 튜링 머신에서 해당 식의 n을 무한대로 보내면 당연히 0%지만 임베디드 시스템의 성능을 감안하여 현실에서 보통 이 조건은 69.32% 미만이면 대체로 만족한다고 본다.

모든 RTOS는 상호 배제 기능(Mutual Exclusion 또는 MUTEX라고도 불리는 이진 세마포어 등)을 사용하는 상황을 최대한 피하고, 사용하더라도 매우 짧은 시간 내에만 해당 기능을 쓰도록 Critical Section의 크기를 최소화하는 것이 좋다. 왜냐하면 상호 배제 락이 걸린 프로세스가 정해진 시간 내에 태스크를 완료하는 데에 실패할 수 있기 때문이다. 그래서 대용책으로 메세지 큐(Message Queue, 그냥 큐라고도 한다)를 사용하는 경우가 많다. 우선순위 상속으로 태스크들 간에 동작 의존성에 따라 일시적으로 상호 배제 기능을 이용중인 낮은 우선순위의 태스크를 강제로 높은 우선순위로 끌어올려 Mutex를 빨리 놓는 조기 작업 종결을 유도하는 방법도 있다.

메모리 누수와 힙 파편화는 임베디드 시스템에서 더욱 치명적이기에 절대 허용해서는 안된다. C언어를 쓴다면 모든 malloc에 free 함수가 적절히 매칭되는지 꼭 확인하고 메모리 반환 없이 메모리를 잡고 작업하기만 하는 함수가 등장하면 매우 높은 확률로 큰일난다(멀티스레딩 환경이면 추가로 아토믹 연산을 메모리 할당/해제 과정에 걸어야 한다). 힙 파편화는 메모리 영역 블록이 메모리 전체에 조그맣게 산개한 상황으로 메모리 할당시 지연 시간이 길어지므로 아무 생각 없이 임의의 크기로 자유 메모리 영역(Heap)을 사용하지 않는 것이 좋다. 서로 다른 메모리 사용량을 보이는 태스크들이 있다면 작은 크기의 힙을 쓰는 태스크들은 아예 전역으로 큰 메모리 사용량을 보이는 태스크의 메모리 할당량과 비슷한 특정 메모리 영역을 지정하고 해당 메모리 영역을 공유하여 그 안에서 다시 메모리 할당 위치를 수동 지정하는 식으로 파편화를 피하는 방법이 있다. 운영체제 차원의 튜닝이 가능하다면 버디 블록 알고리즘을 위한 메모리 분할 구조를 임베디드 기기에서 돌아가는 태스크들의 종류에 따라 커스텀하는 경우도 있다.

주요 RTOS

[편집 | 원본 편집]
  • QNX : 원래 독립적으로 개발되다가 RIM(이후 블랙베리) 사에 인수되어 블랙베리 OS의 기반이 된 RTOS지만 블랙베리가 망한 현재에도 살아남아 계속 쓰이는 중이다.
  • Nucleus RTOS : 삼성 초기 스마트폰에 쓰였던 바다 OS의 기반이기도 하다.
  • 윈도우 CE : PMP에서 무지막지하게 쓰였던 그것. 윈도우즈 폰 운영체제의 기반이 되기도 했다. 현재는 사실상 ARM용 Windows 제품군에 흡수되어 IoT용 Windows로 잔존하고 있다.
  • 리눅스에서 PREEMPT_RT 패치를 써서 RTOS처럼 만들 수 있다. 이와는 별도로 RTLinux 등의 RTOS화된 리눅스 배포판도 있다.
  • FreeRTOS
  • VxWorks
  • 이 외에도 수없이 많다.