| D. Kalinsky Associates |
| Home | Training Courses | Online Learning | Resources | About Us | Contact | Site Map |
Online Training Session: Messages for Intertask Communication
| How Can Tasks Wait for Messages? |
• “Direct” Message Passing RTOSs:
• Task Waits in the “Blocked” (“Waiting”) State until Message Arrives
• Message is Addressed Specifically to this Task
• “Indirect” Message Passing RTOSs:
• Task Waits in the “Blocked” State AND ALSO in a Task Waiting Queue
• FIFO or Priority, Time-Limited or Unlimited
• Each Message Queue has an associated Task Waiting Queue
• At least one of these 2 interlinked Queues is empty at any time
• Task Waits in the “Blocked” (“Waiting”) State until Message Arrives
• Message is Addressed Specifically to this Task
• “Indirect” Message Passing RTOSs:
• Task Waits in the “Blocked” State AND ALSO in a Task Waiting Queue
• FIFO or Priority, Time-Limited or Unlimited
• Each Message Queue has an associated Task Waiting Queue
• At least one of these 2 interlinked Queues is empty at any time
NOTES:
We usually think about message queues in the situation where there are a number of messages waiting to be
fetched, but no task has yet asked to fetch them. But sometimes, just the reverse happens: There may be no
messages waiting to be fetched, but one or more tasks is asking to fetch them. How will a real-time operating system
handle this situation? The answer is different, for different categories of real-time operating systems:
Direct message passing RTOSs answer this situation in a very simple way. Every task has its own (automatically
created) message queue. So if there are no messages waiting in that queue, the task that asked to fetch its
message will be made to wait until its message arrives. The task is then said to be in the "Waiting" or "Blocked" or
"Pended" state. [The term used depends on the specific RTOS.] When a message arrives, the task will be given the
message and allowed to run with it, .
Indirect message passing RTOSs handle this question in a more complex way. This is because many different
tasks may ask to fetch messages from the same message queue. For these RTOSs, each queue is actually
constructed of two queues, as shown in the diagram on this page: When we think of a queue, we normally think of the
queue for messages that's shown on the left side of this diagram. Messages wait in this queue when no task has
asked to fetch them yet. But these RTOSs automatically create a second queue for tasks that's shown on the right
side of this diagram. Both queues are created together, every time the "create_queue()" RTOS service is called.
The queue at the right is used to queue up tasks that are waiting for messages that haven't yet arrived. It's convenient
to think of these two interrelated queues as "butting head-to-head", or "conjoined".
The tasks in the queue at the right are in a waiting state, and at the same time are queued up in preparation for getting
a message in the future. They queue up in the order that they'll get their next message --- when future messages
arrive on the left. The order of the queueing of tasks can be either FIFO ordering or Task-Priority ordering. Whenever
a task is about to enter this queue (as part of the "msg_receive()" RTOS service), it can specify one of 3 choices:
(a) I'm OK to wait in this queue for as long as it takes, until I get a message. ["WAIT_FOREVER"];
(b) I'm OK to wait in this queue for a limited time only. At the end of this time, let me continue to run -- even if I didn't get
a message ["WAIT_LIMIT"]; or
(c) I don't want to wait in this queue at all. If there's no message ready for me right now, then let me continue to run
immediately. I'm OK to continue running right now without getting any message. ["NOWAIT"]
If you think about it, you'll realize that at least one of these 2 "conjioned" queues will be empty at any given time. Or
maybe both will be empty. If there are messages waiting in the message queue at the left, then tasks will fetch them
for processing and won't need to wait in the task-waiting queue on the right. On the other hand, if there are tasks
waiting in the queue at the right, then messages arriving on the left will be taken for processing immediately by tasks
-- and they won't need to wait in the message queue on the left. So both queues in a "conjoined" pair will never be
populated at the same time.
We usually think about message queues in the situation where there are a number of messages waiting to be
fetched, but no task has yet asked to fetch them. But sometimes, just the reverse happens: There may be no
messages waiting to be fetched, but one or more tasks is asking to fetch them. How will a real-time operating system
handle this situation? The answer is different, for different categories of real-time operating systems:
Direct message passing RTOSs answer this situation in a very simple way. Every task has its own (automatically
created) message queue. So if there are no messages waiting in that queue, the task that asked to fetch its
message will be made to wait until its message arrives. The task is then said to be in the "Waiting" or "Blocked" or
"Pended" state. [The term used depends on the specific RTOS.] When a message arrives, the task will be given the
message and allowed to run with it, .
Indirect message passing RTOSs handle this question in a more complex way. This is because many different
tasks may ask to fetch messages from the same message queue. For these RTOSs, each queue is actually
constructed of two queues, as shown in the diagram on this page: When we think of a queue, we normally think of the
queue for messages that's shown on the left side of this diagram. Messages wait in this queue when no task has
asked to fetch them yet. But these RTOSs automatically create a second queue for tasks that's shown on the right
side of this diagram. Both queues are created together, every time the "create_queue()" RTOS service is called.
The queue at the right is used to queue up tasks that are waiting for messages that haven't yet arrived. It's convenient
to think of these two interrelated queues as "butting head-to-head", or "conjoined".
The tasks in the queue at the right are in a waiting state, and at the same time are queued up in preparation for getting
a message in the future. They queue up in the order that they'll get their next message --- when future messages
arrive on the left. The order of the queueing of tasks can be either FIFO ordering or Task-Priority ordering. Whenever
a task is about to enter this queue (as part of the "msg_receive()" RTOS service), it can specify one of 3 choices:
(a) I'm OK to wait in this queue for as long as it takes, until I get a message. ["WAIT_FOREVER"];
(b) I'm OK to wait in this queue for a limited time only. At the end of this time, let me continue to run -- even if I didn't get
a message ["WAIT_LIMIT"]; or
(c) I don't want to wait in this queue at all. If there's no message ready for me right now, then let me continue to run
immediately. I'm OK to continue running right now without getting any message. ["NOWAIT"]
If you think about it, you'll realize that at least one of these 2 "conjioned" queues will be empty at any given time. Or
maybe both will be empty. If there are messages waiting in the message queue at the left, then tasks will fetch them
for processing and won't need to wait in the task-waiting queue on the right. On the other hand, if there are tasks
waiting in the queue at the right, then messages arriving on the left will be taken for processing immediately by tasks
-- and they won't need to wait in the message queue on the left. So both queues in a "conjoined" pair will never be
populated at the same time.
waiting tasks
| © Copyright 2010, D. Kalinsky Associates, All Rights Reserved. This page Updated January 1, 2010 |