| D. Kalinsky Associates |
| Home | Training Courses | Online Learning | Resources | About Us | Contact | Site Map |
Online Training Session: Messages for Intertask Communication
| Tasks and their Message Queues |
• Using “Indirect” Message Passing RTOSs, there can be
a Many-to-Many Relationship between Tasks and Queues
• Complex Application Software
• Task can Wait for Messages on Only 1 Queue at a time
• Most Applications Restrict Design to one Queue per Task
• Conceptually like “Direct” Message Passing
a Many-to-Many Relationship between Tasks and Queues
• Complex Application Software
• Task can Wait for Messages on Only 1 Queue at a time
• Most Applications Restrict Design to one Queue per Task
• Conceptually like “Direct” Message Passing
NOTES:
As we've seen, Message Queues are used as the conduits through which messages can be passed between
software tasks. In some cases, the RTOS will create the queues automatically (asynchronous direct message
passing). In other cases, you will need to make service calls to the RTOS to create your queues (indirect message
passing). [Only in the case of synchronous direct message passing can the need for queues be avoided.]
Applications using indirect message passing will contain lots of message queues. You may want to set up a
separate queue for every pair of tasks that need to transfer data from one to the other. If data transfer is bi-directional,
that pair of tasks may well need two queues -- one for each direction of data transfer. If different kinds of data are
being transferred, separate queues are often used for the separate kinds of data. In this way, you'll end up with lots
and lots of queues -- probably many more queues than you've got tasks in your software system. And the result may
well be quite a complex many-to-many relationship between your tasks and your queues.
This situation may be made even more complicated by restrictions in your particular RTOS, as seen in the diagram at
the top of this page. It shows a portion of a software design using an RTOS which allows a task to wait for messages
on only one queue at a time. But the task shown on the right has a requirement to fetch a message from any of 3
queues, from whichever queue has a message first. This sounds impossible, based on the restriction in the RTOS.
And it can best be solved using a complex work-around (involving event flags) which makes the design diagram look
like a bowl of spaghetti.
How can we avoid the complexities of designing inter-task message communications when using an indirect
message passing RTOS? Answer: Use the same "Design Rule" that's built-in to asynchronous direct message
passing RTOSs: Set up no more than one message queue for each task that will be receiving messages. [If
different messages to this task will contain different kinds of payload content, have the first field of the message data
contain a payload type identification number.]
As we've seen, Message Queues are used as the conduits through which messages can be passed between
software tasks. In some cases, the RTOS will create the queues automatically (asynchronous direct message
passing). In other cases, you will need to make service calls to the RTOS to create your queues (indirect message
passing). [Only in the case of synchronous direct message passing can the need for queues be avoided.]
Applications using indirect message passing will contain lots of message queues. You may want to set up a
separate queue for every pair of tasks that need to transfer data from one to the other. If data transfer is bi-directional,
that pair of tasks may well need two queues -- one for each direction of data transfer. If different kinds of data are
being transferred, separate queues are often used for the separate kinds of data. In this way, you'll end up with lots
and lots of queues -- probably many more queues than you've got tasks in your software system. And the result may
well be quite a complex many-to-many relationship between your tasks and your queues.
This situation may be made even more complicated by restrictions in your particular RTOS, as seen in the diagram at
the top of this page. It shows a portion of a software design using an RTOS which allows a task to wait for messages
on only one queue at a time. But the task shown on the right has a requirement to fetch a message from any of 3
queues, from whichever queue has a message first. This sounds impossible, based on the restriction in the RTOS.
And it can best be solved using a complex work-around (involving event flags) which makes the design diagram look
like a bowl of spaghetti.
How can we avoid the complexities of designing inter-task message communications when using an indirect
message passing RTOS? Answer: Use the same "Design Rule" that's built-in to asynchronous direct message
passing RTOSs: Set up no more than one message queue for each task that will be receiving messages. [If
different messages to this task will contain different kinds of payload content, have the first field of the message data
contain a payload type identification number.]
| © Copyright 2010, D. Kalinsky Associates, All Rights Reserved. This page Updated January 1, 2010 |
