| D. Kalinsky Associates |
| Home | Training Courses | Online Learning | Resources | About Us | Contact | Site Map |
Online Training Session: Messages for Intertask Communication
| “Direct” Message Passing |
• Messages themselves are High Performance, Separate RTOS Objects
• Sent Directly from Task to Task
• No Intermediary Queue Object !
• Synchronous vs. Asynchronous Direct Message Passing
• Sent Directly from Task to Task
• No Intermediary Queue Object !
• Synchronous vs. Asynchronous Direct Message Passing
NOTES:
A growing number of real-time operating systems use a different data-passing technique we'll call "Direct" Message
Passing. In this approach, messages are sent directly from task to task, without any intermediary like a message
queue.
In the diagram on this page, the message sender task shown on the left communicates directly with the message
receiver task on the right. There is no "independent" message queue between the two tasks. The envelope in the
diagram represents a message, and is shown on its way directly from the sender to the receiver task.
There is no need to create a Message Queue when using direct message passing. However, the message sender
task needs to know the identity of the receiver task (this is usually a 32-bit number, called a "Task-Identifier"), in order
to send a message to that task.
Some real-time operating systems that use "Direct" Message Passing avoid the copying of message data (via a
"hidden" area of RAM memory), that can cause performance problems in many "indirect" message passing RTOSs.
They do this by delivering to the receiver task a pointer to the buffer containing the message. For long messages, this
is much more efficient than delivering a copy of the message itself. In order to prevent "mutual exclusion violations"
(see previous page), the RTOS will obliterate the buffer pointer that is being stored in the sender task, before
delivering a copy of the pointer to the receiver task.
This technique of message passing via pointer passing is highly efficient. And it is equally efficient for both short and
long messages. Hence, messages can be lengthened without slowing down their delivery. This idea is used by
some direct message passing RTOSs in order to add some extra bytes of 'administrative data' to the messages they
carry. These RTOSs can then use these extra data for quality control and reliability management. Some typical
administrative data are shown in the 'blow-up' of the message in the diagram on this page.
Some RTOSs offer synchronous direct message passing, while others offer asynchronous direct message
passing. In synchronous message passing, the message sender task must wait for the receiver task to actually
receive the message before the sender task will continue to run. This could delay a message sender task if, for
example, the receiver task is busy doing something else and is not attempting to fetch the new message. In
asynchronous message passing, the message sender task need not wait for the receiver task to do anything. After
sending a message to the receiver task, the sender task can continue to run irrespective of the situation of the receiver
task. Both of these synchronization approaches have their advantages and disadvantages, depending on your
specific software design.
How can a programmer make direct message passing happen? It's quite similar to the programming of indirect
message passing. The main difference is that a message sender task will provide the receiver's Task-Identifier
(instead of a Queue-Identifier), when making a "message_send()"-style service call.
A growing number of real-time operating systems use a different data-passing technique we'll call "Direct" Message
Passing. In this approach, messages are sent directly from task to task, without any intermediary like a message
queue.
In the diagram on this page, the message sender task shown on the left communicates directly with the message
receiver task on the right. There is no "independent" message queue between the two tasks. The envelope in the
diagram represents a message, and is shown on its way directly from the sender to the receiver task.
There is no need to create a Message Queue when using direct message passing. However, the message sender
task needs to know the identity of the receiver task (this is usually a 32-bit number, called a "Task-Identifier"), in order
to send a message to that task.
Some real-time operating systems that use "Direct" Message Passing avoid the copying of message data (via a
"hidden" area of RAM memory), that can cause performance problems in many "indirect" message passing RTOSs.
They do this by delivering to the receiver task a pointer to the buffer containing the message. For long messages, this
is much more efficient than delivering a copy of the message itself. In order to prevent "mutual exclusion violations"
(see previous page), the RTOS will obliterate the buffer pointer that is being stored in the sender task, before
delivering a copy of the pointer to the receiver task.
This technique of message passing via pointer passing is highly efficient. And it is equally efficient for both short and
long messages. Hence, messages can be lengthened without slowing down their delivery. This idea is used by
some direct message passing RTOSs in order to add some extra bytes of 'administrative data' to the messages they
carry. These RTOSs can then use these extra data for quality control and reliability management. Some typical
administrative data are shown in the 'blow-up' of the message in the diagram on this page.
Some RTOSs offer synchronous direct message passing, while others offer asynchronous direct message
passing. In synchronous message passing, the message sender task must wait for the receiver task to actually
receive the message before the sender task will continue to run. This could delay a message sender task if, for
example, the receiver task is busy doing something else and is not attempting to fetch the new message. In
asynchronous message passing, the message sender task need not wait for the receiver task to do anything. After
sending a message to the receiver task, the sender task can continue to run irrespective of the situation of the receiver
task. Both of these synchronization approaches have their advantages and disadvantages, depending on your
specific software design.
How can a programmer make direct message passing happen? It's quite similar to the programming of indirect
message passing. The main difference is that a message sender task will provide the receiver's Task-Identifier
(instead of a Queue-Identifier), when making a "message_send()"-style service call.
| © Copyright 2010, D. Kalinsky Associates, All Rights Reserved. This page Updated January 1, 2010 |
MESSAGE CONTENT
Message Type: msgID_17
Sender: task_35
Destination: task_71
Message Owner: rtos_region3
Data Payload: 1.718.555.8562
Message Type: msgID_17
Sender: task_35
Destination: task_71
Message Owner: rtos_region3
Data Payload: 1.718.555.8562