임베디드/[ RTOS ]

[ RTOS ] 03. ThreadX의 Message Queues

kim.svadoz 2021. 3. 31. 09:56
반응형

Message Queues

Message queues are the primary means of interthread communication in ThreadX. One or more messages can reside in a message queue. A message queue that holds a single message is commonly called a mailbox.

Messages are copied to a queue by tx_queue_send and are copied from a queue by tx_queue_receive. The only exception to this is when a thread is suspended while waiting for a message on an empty queue. In this case, the next message sent to the queue is placed directly into the thread’s destination area.

Each message queue is a public resource. ThreadX places no constraints on how message queues are used.

메시지 큐는 ThreadX에서 스레드 간 통신의 기본 수단입니다. 하나 이상의 메시지가 메시지 대기열에있을 수 있습니다. 단일 메시지를 보관하는 메시지 큐를 일반적으로 사서함이라고합니다.

메시지는 tx_queue_send에 의해 큐로 복사되고 tx_queue_receive에 의해 큐에서 복사됩니다. 이에 대한 유일한 예외는 빈 대기열에서 메시지를 기다리는 동안 스레드가 일시 중단되는 경우입니다. 이 경우 대기열에 전송 된 다음 메시지는 스레드의 대상 영역에 직접 배치됩니다.

각 메시지 대기열은 공용 리소스입니다. ThreadX는 메시지 큐가 사용되는 방식에 제한을 두지 않습니다.

  • Creating Message Queues

Message queues are created either during initialization or during run-time by application threads. There are no limits on the number of message queues in an application.

메시지 큐는 초기화 중에 또는 런타임 중에 애플리케이션 스레드에 의해 작성됩니다. 애플리케이션의 메시지 큐 수에는 제한이 없습니다.

  • Message Size

Each message queue supports a number of fixedsized messages. The available message sizes are 1, 2, 4, 8, and 16 32-bit words. The message size is specified when the queue is created.

Application messages greater than 16 words must be passed by pointer. This is accomplished by creating a queue with a message size of 1 word (enough to hold a pointer) and then sending and receiving message pointers instead of the entire message.

각 메시지 대기열은 여러 고정 크기 메시지를 지원합니다. 사용 가능한 메시지 크기는 1, 2, 4, 8 및 16 32 비트 단어입니다. 메시지 크기는 큐가 생성 될 때 지정됩니다.

16 단어보다 큰 응용 프로그램 메시지는 포인터로 전달되어야합니다. 이는 메시지 크기가 1 단어 (포인터를 보유하기에 충분한)의 큐를 만든 다음 전체 메시지 대신 메시지 포인터를 보내고받는 방식으로 수행됩니다.

  • Message Queue Capactiy

The number of messages a queue can hold is a function of its message size and the size of the memory area supplied during creation. The total message capacity of the queue is calculated by dividing the number of bytes in each message into the total number of bytes in the supplied memory area.

For example, if a message queue that supports a message size of 1 32-bit word (4 bytes) is created with a 100-byte memory area, its capacity is 25 messages.

큐가 보유 할 수있는 메시지 수는 메시지 크기와 작성 중에 제공된 메모리 영역의 크기에 따라 달라집니다.

큐의 총 메시지 용량은 다음과 같이 계산됩니다.
각 메시지의 바이트 수를 제공된 메모리 영역의 총 바이트 수로 나눕니다.

예를 들어, 1 개의 32 비트 워드 (4 바이트)의 메시지 크기를 지원하는 메시지 대기열이 100 바이트 메모리 영역으로 생성되는 경우 용량은 25 개 메시지입니다.

  • Queue Memory Area

As mentioned before, the memory area for buffering messages is specified during queue creation. Like other memory areas in ThreadX, it can be located anywhere in the target’s address space. This is an important feature because it gives the application considerable flexibility. For example, an application might locate the memory area of a very important queue in high-speed RAM in order to improve performance.

앞에서 언급했듯이 메시지 버퍼링을위한 메모리 영역은 큐 생성 중에 지정됩니다.

ThreadX의 다른 메모리 영역과 마찬가지로 대상 주소 공간의 어디에나 위치 할 수 있습니다.

이것은 애플리케이션에 상당한 유연성을 제공하기 때문에 중요한 기능입니다.

예를 들어, 응용 프로그램은 성능 향상을 위해 고속 RAM에서 매우 중요한 대기열의 메모리 영역을 찾을 수 있습니다.

  • Thread Suspension

Application threads can suspend while attempting to send or receive a message from a queue. Typically, thread suspension involves waiting for a message from an empty queue. However, it is also possible for a thread to suspend trying to send a message to a full queue.

After the condition for suspension is resolved, the service requested is completed and the waiting thread is resumed. If multiple threads are suspended on the same queue, they are resumed in the order they were suspended (FIFO).

However, priority resumption is also possible if the application calls tx_queue_prioritize prior to the queue service that lifts thread suspension. The queue prioritize service places the highest priority thread at the front of the suspension list, while leaving all other suspended threads in the same FIFO order.

Time-outs are also available for all queue suspensions. Basically, a time-out specifies the maximum number of timer ticks the thread will stay suspended. If a time-out occurs, the thread is resumed and the service returns with the appropriate error code.

큐에서 메시지를 보내거나받는 동안 응용 프로그램 스레드가 일시 중지 될 수 있습니다. 일반적으로 스레드 일시 중단에는 빈 큐에서 메시지를 기다리는 것이 포함됩니다. 그러나 스레드가 전체 큐에 메시지를 보내려고 시도하는 것을 일시 중단 할 수도 있습니다.

일시 중단 조건이 해결되면 요청 된 서비스가 완료되고 대기중인 스레드가 재개됩니다. 여러 스레드가 동일한 대기열에 일시 중단 된 경우 일시 중단 된 순서 (FIFO)에 따라 다시 시작됩니다.

그러나 스레드 일시 중단을 해제하는 큐 서비스 이전에 애플리케이션이 tx_queue_prioritize를 호출하는 경우에도 우선 순위 재개가 가능합니다. 큐 우선 순위 지정 서비스는 가장 높은 우선 순위 스레드를 일시 중단 목록의 맨 앞에 배치하고 다른 모든 일시 중단 된 스레드는 동일한 FIFO 순서로 둡니다.

시간 제한은 모든 대기열 일시 중단에도 사용할 수 있습니다. 기본적으로 시간 제한은 스레드가 일시 중단 된 상태로 유지되는 최대 타이머 틱 수를 지정합니다. 시간 초과가 발생하면 스레드가 재개되고 서비스가 적절한 오류 코드와 함께 반환됩니다.

  • Queue Control Block TX_QUEUE

The characteristics of each message queue are found in its control block. It contains interesting information such as the number of messages in the queue. This structure is defined in the tx_api.h file. Message queue control blocks can also be located anywhere in memory, but it is most common to make the control block a global structure by defining it outside the scope of any function.

각 메시지 큐의 특성은 제어 블록에서 찾을 수 있습니다. 큐에있는 메시지 수와 같은 흥미로운 정보가 포함되어 있습니다.

이 구조는 tx_api.h 파일에 정의되어 있습니다. 메시지 큐 제어 블록은 메모리의 어느 위치 에나 위치 할 수도 있지만 제어 블록을 모든 기능의 범위 밖에서 정의하여 글로벌 구조로 만드는 것이 가장 일반적입니다.

  • Message Destination Pitfall

As mentioned previously, messages are copied between the queue area and application data areas. It is very important to insure that the destination for a received message is large enough to hold the entire message. If not, the memory following the message destination will likely be corrupted.

This is especially lethal when a too-small message destination is on the stack—nothing like corrupting the return address of a function!

앞서 언급했듯이 메시지는 큐 영역과 애플리케이션 데이터 영역간에 복사됩니다. 수신 된 메시지의 대상이 전체 메시지를 저장할 수있을만큼 충분히 큰지 확인하는 것이 매우 중요합니다. 그렇지 않으면 메시지 대상 다음의 메모리가 손상 될 수 있습니다.

이는 함수의 반환 주소를 손상시키는 것과 같이 너무 작은 메시지 대상이 스택에있을 때 특히 치명적입니다.

반응형