this case, the blocking occurs due to the message queue being empty, and the receiving tasks wait in either a FIFO or prioritybased order. The diagram for the receiving tasks is similar to Figure 7.5, except that the blocked receiving tasks are what fills the task list.
For the message queue to become full, either the receiving task list must be empty or the rate at which messages are posted in the message queue must be greater than the rate at which messages are removed. Only when the message queue is full does the task-waiting list for sending tasks start to fill. Conversely, for the task- waiting list for receiving tasks to start to fill, the message queue must be empty.
Messages can be read from the head of a message queue in two different ways:
· destructive read, and
· non-destructive read.
In a destructive read, when a task successfully receives a message from a queue, the task permanently removes the message from the message queue’s storage buffer. In a non-destructive read, a receiving task peeks at the message at the head of the queue without removing it. Both ways of reading a message can be useful; however, not all kernel implementations support the non-destructive read.
Some kernels support additional ways of sending and receiving messages. One way is the example of peeking at a message. Other kernels allow broadcast messaging, explained later in this chapter.
7.6.3 Obtaining Message Queue Information
Obtaining message queue information can be done from an application by using the operations listed in Table 7.3.
Table 7.3: Obtaining message queue information operations.
| Operation | Description |
|---|---|
| Show queue info | Gets information on a message queue |
| Show queue’s task-waiting list | Gets a list of tasks in the queue’s task-waiting list |
Different kernels allow developers to obtain different types of information about a message queue, including the message queue ID, the queuing order used for blocked tasks (FIFO or priority-based), and the number of messages queued. Some calls might even allow developers to get a full list of messages that have been queued up.
As with other calls that get information about a particular kernel object, be careful when using these calls. The information is dynamic and might have changed by the time it’s viewed. These types of calls should only be used for debugging purposes.
7.7 Typical Message Queue Use
The following are typical ways to use message queues within an application:
· non-interlocked, one-way data communication,
· interlocked, one-way data communication,
· interlocked, two-way data communication, and
· broadcast communication.
Note that this is not an exhaustive list of the data communication patterns involving message queues. The following sections discuss each of these simple cases.
7.7.1 Non-Interlocked, One-Way Data Communication
One of the simplest scenarios for message-based communications requires a sending task (also called the message source), a message queue, and a receiving task (also called a message sink), as illustrated in Figure 7.6.
Figure 7.6: Non-interlocked, one-way data communication.
This type of communication is also called non-interlocked (or loosely coupled), one-way data communication. The activities of tSourceTask and tSinkTask are not synchronized. TSourceTask simply sends a message; it does not require acknowledgement from tSinkTask.
The pseudo code for this scenario is provided in Listing 7.1.
Listing 7.1: Pseudo code for non-interlocked, one-way data communication.
tSourceTask () {
:
Send message to message queue
:
}
tSinkTask () {
:
Receive message from message queue
:
}
If tSinkTask is set to a higher priority, it runs first until it blocks on an empty message queue. As soon as tSourceTask sends the message to the queue, tSinkTask receives the message and starts to execute again.
If tSinkTask is set to a lower priority, tSourceTask fills the message queue with messages. Eventually, tSourceTask can be made to block when sending a message to a full message queue. This action makes tSinkTask wake up and start taking messages out of the message queue.
ISRs typically use non-interlocked, one-way communication. A task such as tSinkTask runs and waits on the message queue. When the hardware triggers an ISR to run, the ISR puts one or more messages into the message queue. After the ISR completes running, tSinkTask gets an opportunity to run (if it’s the highest-priority task) and takes the messages out of the message queue.
Remember, when ISRs send messages to the message queue, they must do so in a non-blocking way. If the message queue becomes full, any additional messages that the ISR sends to the message queue are lost.
