| D. Kalinsky Associates |
| Home | Training Courses | Online Learning | Resources | About Us | Contact | Site Map |
Online Training Session: Messages for Intertask Communication
| Asynchronous Communication |
• Loosely-coupled operation: Sender “Shoot and Forget”
• Task delivers Messages to RTOS, then Continues Execution
• Never Waits “Non-Blocking”
• Message normally deposited at the Tail of the Receiver’s Queue
• “Hopes” that Receiver Task will (eventually) Fetch the Message
• Content/Structure of Message Payload are irrelevant to RTOS
• Variable Data, Pointers, Structures, Unions, …
• Task delivers Messages to RTOS, then Continues Execution
• Never Waits “Non-Blocking”
• Message normally deposited at the Tail of the Receiver’s Queue
• “Hopes” that Receiver Task will (eventually) Fetch the Message
• Content/Structure of Message Payload are irrelevant to RTOS
• Variable Data, Pointers, Structures, Unions, …
NOTES:
The majority of off-the-shelf RTOSs, whether using direct or indirect message passing, offer message passing which
is asynchronous in its behavior: The message sender task does not wait (or "block") for the receiver task to receive
the message, or do anything else. After sending its message, the sender task can continue to run irrespective of the
situation of the receiver task. [In the Western USA, this is often called "Shoot and Forget".]
In indirect message passing RTOSs, the message sender task is allowed to continue to run as soon as its
message has been deposited into the queue from which the message will eventually (hopefully) be fetched by the
receiver task. It may be some time (if ever) before the message will be fetched, but the sender task is not waiting for
this to occur.
In direct message passing RTOSs, the message sender task is also allowed to continue to run as soon as it gives
its message to the RTOS. But what would happen if the intended receiver task is not ready to immediately receive the
message? Answer: The RTOS will automatically create a message queue for the intended receiver task, and will hold
messages in this queue until the task asks for them. The queue is created without any programmer involvement. In
fact, these RTOSs don't even need a "create_queue()" service call in their repertoire of services. This kind of
automatic creation of message queues only happens in asynchronous direct message passing RTOSs.
Please note that when a message sender task is allowed to continue execution by an asynchronous message
passing RTOS, this does not necessarily mean that the message has been delivered to the intended receiver task (or
any other task, for that matter). In many instances, it only means that the message has been stored by the RTOS for
later delivery. The actual time of delivery depends on the behavior of the task that fetches the message from RTOS
storage. And if no task ever asks to fetch the message, the message may never be delivered. So there's no
guarantee of delivery in asynchronous message passing RTOSs. That's what's meant by the phrase "Hopes that
Receiver Task will (eventually) Fetch the Message". [In fact, in indirect message passing RTOSs, the wrong task
may eventually come around and fetch the message you intended for a totally different task.]
Final point on this page: RTOSs do not check or manipulate the application "payload" content of the messages your
tasks send and receive. So you can in fact structure the content of your messages in any way you please. You can
even do dangerous things like sending pointers to pointers to pointers, or esoteric things like sending unions of
unions of unions.
The majority of off-the-shelf RTOSs, whether using direct or indirect message passing, offer message passing which
is asynchronous in its behavior: The message sender task does not wait (or "block") for the receiver task to receive
the message, or do anything else. After sending its message, the sender task can continue to run irrespective of the
situation of the receiver task. [In the Western USA, this is often called "Shoot and Forget".]
In indirect message passing RTOSs, the message sender task is allowed to continue to run as soon as its
message has been deposited into the queue from which the message will eventually (hopefully) be fetched by the
receiver task. It may be some time (if ever) before the message will be fetched, but the sender task is not waiting for
this to occur.
In direct message passing RTOSs, the message sender task is also allowed to continue to run as soon as it gives
its message to the RTOS. But what would happen if the intended receiver task is not ready to immediately receive the
message? Answer: The RTOS will automatically create a message queue for the intended receiver task, and will hold
messages in this queue until the task asks for them. The queue is created without any programmer involvement. In
fact, these RTOSs don't even need a "create_queue()" service call in their repertoire of services. This kind of
automatic creation of message queues only happens in asynchronous direct message passing RTOSs.
Please note that when a message sender task is allowed to continue execution by an asynchronous message
passing RTOS, this does not necessarily mean that the message has been delivered to the intended receiver task (or
any other task, for that matter). In many instances, it only means that the message has been stored by the RTOS for
later delivery. The actual time of delivery depends on the behavior of the task that fetches the message from RTOS
storage. And if no task ever asks to fetch the message, the message may never be delivered. So there's no
guarantee of delivery in asynchronous message passing RTOSs. That's what's meant by the phrase "Hopes that
Receiver Task will (eventually) Fetch the Message". [In fact, in indirect message passing RTOSs, the wrong task
may eventually come around and fetch the message you intended for a totally different task.]
Final point on this page: RTOSs do not check or manipulate the application "payload" content of the messages your
tasks send and receive. So you can in fact structure the content of your messages in any way you please. You can
even do dangerous things like sending pointers to pointers to pointers, or esoteric things like sending unions of
unions of unions.
| © Copyright 2010, D. Kalinsky Associates, All Rights Reserved. This page Updated January 1, 2010 |
