죄송합니다. 더 이상 지원되지 않는 웹 브라우저입니다.

RTOS 메시지 큐의 다양한 용도

글/쟝 J. 래브로스(Jean J. Labrosse), 미크리엄(Micrium) 설립자이자 실리콘랩스 소프트웨어 아키텍트

RTOS란 무엇인가?

RTOS(Real Times OS)는 CPU, MPU 또는 DSP의 시간을 가능한 효율적으로 관리하는 소프트웨어를 말한다. 대부분의 RTOS 커널은 C 언어로 작성되며, 커널을 서로 다른 CPU 아키텍처에 맞춰 조절하기 위해 어셈블리 언어로 작성된 코드의 작은 부분을 필요로 한다.
커널은 프로그래머에게 멀티태스킹, 인터럽트 관리, 메시지 큐(message queue)를 통한 태스크 간 통신, 시그널링, 자원 관리, 시간 관리, 메모리 파티션 관리 등과 같은 다양하고 유용한 서비스를 제공한다.
애플리케이션(즉, 최종 제품)은 기본적으로 여러 태스크로 나뉘며, 각각의 태스크는 애플리케이션의 한 부분을 담당한다. 태스크는 자체적으로 CPU를 점유한다고 볼 수 있는 간단한 프로그램이다. 각 태스크는 작업의 중요도에 따라 우선순위가 할당된다.

메시지 큐란 무엇인가?
그림 1에서 보듯이 메시지 큐는 ISR(interrupt service routine) 또는 태스크로부터 다른 태스크(대기)로 메시지를 보내는(즉, 포스트하는) 커널 오브젝트(데이터 구조체)이다. 애플리케이션이 가질 수 있는 메시지 큐의 수에는 특정한 제한이 없으며, 각 메시지 큐는 고유의 목적을 갖는다. 예를 들어 하나의 메시지 큐는 통신 인터페이스 ISR로부터 수신한 패킷을 이러한 패킷을 처리하는 태스크에 전달하는 데 사용할 수 있다. 또 다른 메시지 큐는 디스플레이의 적절한 업데이트를 담당하는 디스플레이 태스크에 콘텐츠를 전달하는 데 사용할 수 있다.

[그림 1] 메시지 큐는 콘텐츠를 태스크에 전달하는 데 사용되는 커널 오브젝트이다.

메시지는 일반적으로 실제 메시지를 포함하는 저장 영역을 가리키는 보이드(void) 포인터이다. 하지만 포인터는 수신 태스크 실행 기능을 포함해 어느 것이나 가리킬 수 있다. 따라서 메시지의 의미는 애플리케이션에 따라 달라진다. 각 메시지 큐는 갖게 될 저장공간 크기에 맞게 구성할 수 있다. 메시지 큐는 하나의 메시지(메일박스) 또는 N개의 메시지를 갖도록 구성할 수 있다. 큐의 크기는 애플리케이션에 따라 다르며, 큐가 가득 차기 전에 수신 태스크가 얼마나 빨리 메시지를 처리할 수 있는지에 따라 달라진다.
태스크가 메시지에 대해 대기(기다리는) 상태이고 큐에 메시지가 없으면, 태스크는 메시지가 큐에 포스트(송신)될 때까지 블로킹된다. 대기 중인 태스크는 RTOS가 다른 작업을 실행하기 때문에 메시지를 기다리는 동안 CPU 시간을 소비하지 않는다. 그림 1에서 보듯이 대기 중인 태스크는 타임아웃을 지정할 수 있다. 메시지가 지정된 타임아웃 내에 수신되지 않으면, 태스크는 최상위 우선순위 태스크가 될 때 실행을 재개(블로킹 해제)할 수 있다. 태스크가 실행될 때에는 기본적으로 타임아웃으로 인해 메시지를 받지 못했기 때문에라는 태스크가 재개된 이유를 전달받는다.
메시지 큐는 일반적으로 선입선출(First-In-First-Out, FIFO) 방식으로 구현된다. 이는 맨 처음 수신된 메시지가 큐에서 가장 먼저 처리된다는 것을 의미한다. 그러나 일부 커널에서는 다른 메시지보다 더 중요한 메시지를 보낼 수 있도록 큐의 헤드에 포스트할 수 있게 한다. 달리 말하면 후입선출(Last-In-First-Out, LIFO)에서 해당 메시지가 태스크에 의해 가장 먼저 처리되게 한다.
메시지 큐의 중요한 측면의 하나는 메시지 자체가 전송된 시간부터 처리되는 시간까지의 범위 내에 있어야 한다는 점이다. 이것은 포인터를 스택 변수, 다른 코드에 의해 변경될 수 있는 글로벌 변수 등에 전달할 수 없다는 것을 의미한다. 메시지를 범위 내에 유지하기 위해 일반적으로 그림 2에서 보는 것과 같은 메시지의 풀(pool) 로부터 얻을 수 있는 구조체를 가져온다. 메시지를 송신하는 ISR 또는 태스크는 풀로부터 구조체를 얻고 가져온 다음, 구조체를 가리키는 포인터를 큐에 포스트한다. 수신 태스크는 큐에서 포인터를 추출하고, 구조를 처리하고, 처리가 완료되면 구조체를 풀에 돌려 보낸다. 데이터 구조체의 필드가 어떤 풀이 사용되었는지를 지시하지 않는 한, 송신자와 수신자는 모두 동일한 풀을 사용해야 한다.

[그림 2] 메시지 저장 영역의 풀

RTOS에서는 많은 메시지 큐 구현 사례들의 경우, 큐가 이미 가득 차 있다면 큐로 송신 중인 메시지는 폐기된다. 흔히 이는 별로 문제가 되지 않으며 애플리케이션의 로직으로 이러한 상황으로부터 복구할 수 있다. 하지만 그림 3에서 보듯이 수신자가 메시지의 하나를 추출할 때까지 송신 태스크를 븥로킹하는 것과 같은 방법을 구현하는 것이 훨씬 쉽다.
그림 3(1) 카운팅 세마포어(counting semaphore)는 큐가 수용할 수 있는 항목의 최대 수에 해당하는 값으로 초기화된다.
그림 3(2) 송신 태스크는 메시지를 큐에 포스트하도록 허용받기 전에 세마포어에서 대기한다. 세마포어 값이 0이면 송신자는 기다린다.
그림 3(3) 값이 0이 아니면 세마포어 카운트가 감소되고 송신자는 메시지를 큐에 포스트한다.
그림 3(4) 메시지의 수신자는 언제나처럼 메시지 큐에서 대기한다.
그림 3(5) 메시지가 수신되면 수신자는 큐에서 메시지에 대한 포인터를 추출하고 세마포어에 큐의 항목 하나가 추출되었다는 것을 나타내는 신호를 보낸다.
그림에서 보듯이 ISR은 세마포어에서 대기할 수 없으므로 이 방식은 두 개의 태스크에서만 작동한다.

[그림 3] 큐가 가득 차면 송신자를 블로킹한다.

메시지 큐의 다른 용도

그림 4는 메시지 큐의 다양한 용도를 보여준다.
그림 4(1-4) 앞서 언급했듯이, 메시지 큐는 주로 ISR 또는 태스크에서 다른 태스크로 메시지를 보내는 데 사용된다.
그림 4(5)  그러나 메시지가 포인터의 워드 크기 안에 있다면, 실제 메시지를 보내고 저장 영역을 할당할 필요가 없다. 예컨대 포인터가 32bit 폭이라면, 12bit ADC로부터 읽는 아날로그-디지털 컨버터(ADC)를 포인터로 캐스트하여 이를 메시지 큐를 통해 보낼 수 있다. 수신자가 값을 정수로 다시 캐스트하는 걸 아는 한 이는 완벽하게 정상적이다.
그림 4(6-7) 태스크는 메시지가 자신 쪽으로 송신되지 않는다는 것을 알면 일정 시간 동안 스스로 지연시키는 타임아웃 기법을 사용할 수 있다. 이 경우 단일 항목을 보류할 수 있는 큐 하나면 충분하다. 실제로 만약 다른 태스크나 ISR이 메시지를 보내면 지연은 취소된다. 이는 사용자가 구현하고자 하는 동작일 것이다.
그림 4(8) 메시지 큐는 간단히 이벤트가 발생했다는 것을 태스크에게 알려주는 세마포어로 사용할 수 있다. 이 경우 메시지는 어떤 것이나 될 수 있다. 큐의 크기는 얼마나 많은 신호를 애플리케이션이 버퍼링할 필요가 있는지에 따라 달라진다.

그림 4(9-10) 메시지 큐는 또한 자원 공유를 위한 바이너리 세마포어 또는 카운팅 세마포어로 사용할 수 있다. 바이너리 세마포어의 경우 메시지 큐는 단일 메시지를 포함할 수 있으며, 메시지(어떤 값이나)는 큐에 배치된다. 자원에 액세스하기 위해 태스크는 큐에서 대기한다. 큐에 메시지가 있으면, 태스크는 자원에 대한 액세스를 획득한다. 자원을 모두 사용하면 큐는 포스트되고, 필요 시 다른 태스크가 사용할 수 있도록 자원을 양도한다. 동일한 메커니즘이 ‘N’ 자원을 갖는 카운팅 세마포어를 구현하는 데 적용되며, 큐는 N 더미 메시지로 사전에 채워진다.
그림 4(11) 메시지는 실제로 이벤트 플래그를 에뮬레이트하는 데 사용할 수 있다. 여기서 32bit 포인터 크기 변수(정수로 캐스트)의 각 비트는 이벤트를 나타낼 수 있다.
그림 4(12) 메시지 큐는 스택 구조체를 구현하는 데 사용할 수 있다. 이것은 기본적으로 LIFO 메커니즘의 또 다른 용도이다.

[그림 4] 메시지 큐의 다양한 용도 중 몇 가지 사례들

요약

메시지 큐는 여러 방법으로 사용될 수 있다. 실제로 메시지 큐만 가지고도 매우 복잡한 애플리케이션을 작성할 수 있다. 메시지 큐만 사용할 경우 세마포어, 시간 지연, 이벤트 플래그 등 다른 많은 서비스를 시뮬레이트할 수 있기 때문에 코드 크기(풋프린트)를 줄일 수 있다.

[저자 소개]
쟝 J. 래브로스(Jean J. Labrosse)는 1999년에 미크리엄(Micrium)을 설립하고 실리콘랩스의 소프트웨어 아키텍트로서 제품 개발에 적극적인 역할을 지속적으로 담당하면서 RTOS 제품을 강력하게 만들어주는 엄격한 정책과 표준을 고수하도록 이끌고 있다. 쟝 래브로스는 보스턴 및 실리콘밸리에서 열리는 임베디드 월드, ARM 테크콘, 임베디드 시스템즈 컨퍼런스와 같은 IT 컨퍼런스에 연사로 자주 참가하고 있다. 그는 임베디드 디자인에 관한 세 권의 손꼽히는 책의 저자이며, RTOS μC/OS 시리즈 설계자이다. 캐나다 퀘벡 셔브룩대학에서 전기전자공학 학사 및 석사학위를 받았다.