INTERTASK

COMMUNICATION IN RTOS
Semaphore as inter-task
synchronization
Semaphore is simply a variable which is non-negative and shared between
threads. This variable is used to solve the critical section problem and to
achieve process synchronization in the multiprocessing environment.
 Embedded OSs with multiple intercommunicating processes commonly
implement inter process communication (IPC) and synchronization
algorithms based upon one or some combination of memory sharing,
message passing, and signaling mechanisms.
 With the shared data model shown in Figure, processes communicate via
access to shared areas of memory in which variables modified by one
process are accessible to all processes.
 OS tasks send messages to a message queue, or receive messages from
a queue to communicate.
Difference between semaphore and mutex
Message queues, mailboxes, and
pipes
 Message queues, mailboxes, and pipes are services that are provided by
RTOSs that enable tasks to communicate with each other.
 Tasks need to communicate with each other in order to coordinate
activities and to share data.
 WHAT IS MAILBOX??
 If you need strong control over prioritization, mailboxes might be a good
choice. You can easily prioritize mailbox messages no matter when they
entered the mailbox.
 This characteristic provides a definite advantage over other inter-task
communication options such as queues which are particularly sensitive
to the order in which messages are added and removed from the data
structure.
 The other benefit of mailboxes is that there is typically no size limit on
individual mailboxes. The size limit is typically fixed and is set by the
programmer.
 WHAT IS QUEUE??
 If you have an implementation that requires first-in-first-out
prioritization, queues are a great choice. They are flexible and relatively
easy to implement, making them a common choice in RTOS
implementations.

 The downside of queues is that, unlike mailboxes, you are often limited
in the amount of data that you can write to the queue in any given call.
Many RTOSs don’t have a lot of flexibility when it comes to this.
WHAT IS PIPE??

 If you need to be able to write messages of varying lengths, pipes are

the best choice. Pipes are identical
SENDING MESSAGE

When sending messages, a kernel typically fills a message queue from

head to tail in FIFO order, as shown in Figure. Each new message is placed
at the end of the queue.
 Many message-queue implementations allow urgent messages to go straight to
the head of the queue. If all arriving messages are urgent, they all go to the head of the
queue, and the queuing order effectively becomes last-in/first-out (LIFO). In any case,
messages are sent to a message queue in the following ways:
 not block (ISRs and tasks),
 block with a timeout (tasks only), and
 block forever (tasks only).
At times, messages must be sent without blocking the sender. If a message queue
is already full, the send call returns with an error, and the task or ISR making the call
continues executing. This type of approach to sending messages is the only way to send
messages from ISRs, because ISRs cannot block.
Most times, however, the system should be designed so that a task will block if it
attempts to send a message to a queue that is full. Setting the task to block either forever
or for a specified timeout accomplishes this step. The blocked task is placed in the
message queue’s task-waiting list, which is set up in either FIFO or priority-based order.
Recursive shared resource

 Sometimes a developer might want a task to access a shared resource

recursively. This situation might exist if tAccessTask calls Routine A that
calls Routine B, and all three need access to the same shared resource,
as shown in Figure.