D. Kalinsky Associates
 Home  |  Online Learning  |  Resources  |  About Us  |  Contact  |  Site Map  
Online Training Session:         Messages for Intertask Communication
Do All Communication With Messages!
•  Define Content and Structure of the Message
•  Transfer Data between Tasks
•  Report Events to Tasks
•  Messages work well in
Distributed Multiprocessor Environments
•  Do Mutual Exclusion of Shared Resources
•  Critical Sections of Code
•  Hardware Devices
•  Non-Reentrant Algorithms
•  Using “Resource Monitor” Tasks
•  Example:
Previous             Page 9 of 9         End Session
NOTES:

In conclusion, message passing is a highly popular way of passing data reliably from task to task in embedded and
real-time software.  It is supported, with slight variants, in most real-time operating systems.  On this page, we will
discuss the use of message passing beyond its traditional usage in passing data.

Messages can also be used to notify tasks of the occurence of events.  They can replace the bug-prone event
notification systems of some RTOSs, and they can provide an event-notification mechanism if your RTOS does not
have support for events.  A message with a single field of payload data is sufficient to notify a receiving task of the
occurence of an event -- if you encode an event identifier in the payload data field. Unlike RTOS-supported event
mechanisms, messages can be counted reliably.  Messages also offer the possibility of carrying large amounts of
data together with an event notification, all in the same message.

Messages can also be used as a "mutual exclusion" mechanism -- to ensure that 2 or more tasks do not access a
"critical resource" at the same time.   This can be seen in the diagram on this page.  Here we see two tasks on the
left, that would like to share the printer at the far right.   When one task is printing, we don't want the other task to join in
and print at the same time -- because that would trash the printer output.

A traditional solution for this problem would be to set up a (binary) semaphore between the 2 tasks on the left.  Each
task would be required to "lock" the semaphore for itself before starting to print; and would "unlock" the semaphore
when it finished printing.  If a task would attempt to lock an already-locked semaphore, it would be made to wait until
the semaphore became unlocked -- thus ensuring mutual exclusion or exclusive access.  This solution works, with
only small problems.

An alternative solution for this design would be to tell both tasks on the left that they're forbidden to access the printer
at all.  Instead, if they want something printed they need to send a print request message to the task shown toward the
right side of the diagram (in blue).  This kind of task is sometimes called a "Resource Monitor Task", since its job is to
hide the detailed workings of the printer while at the same time performing services at the printer at the request of
other tasks.  Mutual exclusion and exclusive access are taken care of, since the "Resource Monitor Task" handles one
printing request (message) at a time, even if a substantial queue of messages has developed.  So one print job at a
time will be printed, without interference from other print jobs.

Which of these 2 solutions, the semaphore solution or the messaging solution, is more general?  Answer:  The
semaphore solution is good in single-processor and/or single memory-partition environments.  But the messaging
solution works equally well in those environments and in multi-partitioned memory environments, as well as in
multi-CPU multi-core and fully distributed environments.  For example, the design shown in the diagram on this page
works well in a single-processor environment.  And it works equally well if the 3 tasks shown are running on 3
different processors that are linked by message communication.
Want More Learning Materials? Visit our  Online Learning Center
© Copyright 2015  D. Kalinsky Associates, All Rights Reserved.
This page Updated March 25, 2015