INTER TASK COMMUNICATION

MECHANISMS
Intertask communication: Intertask communication involves sharing of data
among task through sharing of memory space, transmission of data etc. It is
executed using following mechanisms
memory sharing
signaling mechanism
message passing
• 1. Message queues
• 2. Pipes
• 3. Event registers
• 4. Signals
WHY ITC
• INFORMATION SHARING
• RESOURCE SHARING
• COMPUTATIONAL SPEED UP
• SYNCHRONIZATION
• MODULARITY
• CONVENIENCE
MESSAGE QUEUE
• A message queue is an inter-process/task communication (IPC/ITC)
mechanism that allows processes to exchange data in the form of messages
between two processes. It allows tasks to communicate asynchronously by
sending messages to each other where the messages are stored in a queue,
waiting to be processed, and are deleted after being processed.

• The message queue is a buffer that is used in non-shared memory

environments, where tasks communicate by passing messages to each
other rather than by accessing shared variables. Tasks share a common
buffer pool. The message queue is an unbounded FIFO queue that is
protected from concurrent access by different threads.
• used to send one or more messages to a task
• basically an array of mailboxes. Through a service provided by the kernel, a
task or an ISR can deposit a message (the pointer) into a message queue.
• One or more tasks can receive messages through a service provided by the
kernel. Both the sender and receiving task or tasks have to agree as to what
the pointer is actually pointing to.
• The first message inserted in the queue is the first message extracted from
the queue (FIFO).
• Some RTOSes allows a task to get messages Last-In-First-Out (LIFO).
• Many tasks can write messages into the queue, but only one can read
messages from the queue at a time. The reader waits on the message queue
until there is a message to process. Messages can be of any size.
• A waiting list is associated with each message queue, in case more
than one task is to receive messages through the queue.
• The kernel allows the task waiting for a message to specify a timeout.
If a message is not received before the timeout expires, the
requesting task is made ready to run, and an error code (indicating a
timeout has occurred) is returned to it.
• A task desiring a message from an empty queue is suspended and
placed on the waiting list until a message is received.
• When a message is deposited into the queue, either the highest
priority task, or the first task to wait for the message is given the
message.
Figure shows an ISR depositing a message into a queue. Note that
the queue is represented graphically by a double I-beam. The “10”
indicates the number of messages that can accumulate in the
queue. A “0” next to the hourglass indicates that the task will wait
forever for a message to arrive.
• data buffers with a finite amount of entries. Each entry can
contain data of a certain size (e.g 32bits). Message queues can
be used for passing data between tasks and between interrupt
service routines and tasks.

common operations that can be performed on message queues

are:

• Create/delete a message queue

• Get the number of messages currently stored in the queue
• Put a message into the queue
• Get a message from the queue
PIPES
• A message pipe is an inter-process task communication tool used
for inserting, deleting messages between two given
interconnected task or two sets of tasks.
• In a pipe there are no fixed numbers of bytes per message but
there is an end-point. A pipe can therefore be inserted limited
number of bytes and have a variable number of bytes per
message between initial and final pointers.
• Pipes are unidirectional i.e. one thread or task inserts into it and
the other one reads and deletes from it.
• The read method of a pipe has no knowledge of where the write
started, the interacting tasks must therefore share start and end
locations as the messages are inserted into the pipe.
• Pipes are a type of IPC (Inter-Process Communication)
technique that allows two or more processes to
communicate with each other by creating a
unidirectional channel between them.
• A pipe is a virtual communication channel that allows
data to be transferred between tasks in one-way .
• Pipes can be implemented using system calls in most
modern operating systems, including Linux, macOS,
and Windows
• The output of one process is directed into the input of another
process. Thus it provides one way flow of data between two related
processes.
• Pipes can be accessed like an ordinary file, the system actually
manages it as FIFO queue.
• A pipe file is created using the pipe system call.
• A pipe has an input end and an output end. One can write into a
pipe from input end and read from the output end.
• A pipe descriptor, has an array that stores two pointers, one pointer
is for its input end and the other pointer is for its output end.
Suppose two processes, Process A and Process B, need to
communicate.
• It is important that the process which writes, closes its read end of
the pipe and the process which reads, closes its write end of a pipe.
communication from Process A to Process B steps
• Process A should keep its write end open and close the read end of
the pipe.
• Process B should keep its read end open and close its write end.
When a pipe is created, it is given a fixed size in bytes.
• When a process attempts to write into the pipe, the write request is
immediately executed if the pipe is not full.
• However, if pipe is full, the process is blocked until the state of pipe
changes.
• Similarly, a reading process is blocked, if it attempts to read more
bytes that are currently in pipe, otherwise the reading process is
executed.
 ADVANTAGES
• Simplicity: Pipes are a simple and straightforward way for
tasks to communicate with each other.
• Efficiency: Pipes are an efficient way for tasks to
communicate, as they can transfer data quickly and with
minimal overhead.
• Reliability: Pipes are a reliable way for tasks to
communicate, as they can detect errors in data transmission
and ensure that data is delivered correctly.
• Flexibility: Pipes can be used to implement various
communication protocols, including one-way and two-way
communication.
 DISADVANTAGES
• Limited capacity: Pipes have a limited capacity, which can limit the amount
of data that can be transferred between tasks at once.
• Synchronization: processes must be synchronized to ensure that data is
transmitted in the correct order.
• Limited scalability: Pipes are limited to communication between a small
number of tasks on the same computer, which can be a disadvantage in
large-scale distributed systems.
Overall, pipes are a useful IPC technique for simple and efficient
communication between processes on the same computer. However, they
may not be suitable for large-scale distributed systems or situations where
bidirectional communication is required.
 LIMITATIONS
• As a channel of communication a pipe operates in one direction only.
• Pipes cannot support broadcast i.e. sending message to multiple processes at
the same time.
• The read end of a pipe reads any way. It does not matter which process is
connected to the write end of the pipe. Therefore, this is very insecure mode
of communication.
• Some plumbing (closing of ends) is required to create a properly directed
pipe.
• The size of the pipe is fixed and cannot be increased, which means that if the
size of the data being sent is larger than the size of the pipe, data will be lost.
• Pipes can only be used for communication between related processes, and
cannot be used for communication between unrelated processes or between
a process and an external device.
• Creation:Creating a pipe using pipe() function, returns two file descriptors,
one for reading another for writing. Creating a message queues using
msgget() function returns a message queue identifier.
• Direction:Pipes and FIFOs are unidirectional, i.e., the data can flow in one
direction only. Message queues are bidirectional i.e., the data can flow in
both directions.
• Data fetching:With Pipes and FIFOs, the data must be fetched in first in first
out order. With message queues the messages can be read in any order
that is consistent with the values associated with the message types.
• Priorities:Priorities are not present in pipes. Priorities can assigned to the
messages by associating a priority number to type(s) of the message(s)
• Persistence:Pipes are completely deleted from the system, when the last
process having reference to it terminates. Message queue and its contents
remain in the system on process termination until they are specifically read
or deleted by some process
 Events
 Event = a Boolean flag that tasks can
 set, reset, and wait for
Task1 Task2

 Example: cordless bar-code scanner

 user pulls trigger €
 laser scanning mechanism must start
 Features of Events
 More than one task can block/ wait for an event, when event
occurs
 all blocked tasks are unblocked
 RTOS executes them in priority order
 RTOS forms groups of events:
 tasks can wait for any subset of an event group
 Example: {key-press on scanner keypad, trigger-pull}
€ start scanning
 Resetting of events:
 automatically done by RTOS
 done by user task software
 EVENT FLAGS
• Event flags are bits used to encode specific information. They are used for
synchronizing tasks and communication. The grouping of individual event flags is
called an event group or a signal.
• Events flags can be used by tasks and by interrupt service routines (ISR). A single
event flag (or a group) can be accessed by many different tasks. The most
common operations that can be performed on event flags are:
• Create/delete event flags
• Set/clear event flags
• Read a flag’s value
• Wait on a flag to take a specific value
 EVENT BITS
• Event bits are used to indicate if an event has occurred or not.
• Event bits are often referred to as event flags. Eg:
• Define a bit (or flag) that means "A message has been received and
is ready for processing" when it is set to 1, and "there are no
messages waiting to be processed" when it is set to 0.
• Define a bit (or flag) that means "The application has queued a
message that is ready to be sent to a network" when it is set to 1,
and "there are no messages queued ready to be sent to the
network" when it is set to 0.
• Define a bit (or flag) that means "It is time to send a heartbeat
message onto a network" when it is set to 1, and "it is not yet time
EVENT REGISTER
• Event group is a set of event bits. Individual event bits
within an event group are referenced by a bit number.
• The event bit that means "A message has been received and
is ready for processing" might be bit number 0 within an
event group.
• The event bit that means "The application has queued a
message that is ready to be sent to a network" might be bit
number 1 within the same event group.
• The event bit that means "It is time to send a heartbeat
message onto a network" might be bit number 2 within the
same event group.
An event group containing 24-event bits,
only three of which are in use
 SIGNALS
• A signal is a notification to a process indicating the occurrence
of an event. Signal is also called software interrupt and is not
predictable to know its occurrence, hence it is also called an
asynchronous event.
• Signal can be specified with a number or a name, usually
signal names start with SIG.SIGKILL: Kill a process
Actions performed for the signals are as follows −
• Default Action
• Handle the signal
• Ignore the signal
• They are used to signal asynchronous events to one or
more processes. A signal could be generated by a keyboard
interrupt or an error condition such as the process
attempting to access a non-existent location in its virtual
memory. Signals are also used by the shells to signal job
control commands to their child processes.
Comparison: Semaphores, Events
 Semaphores are usually the fastest and
simplest methods.
 However, not much information can pass through
a semaphore.
 Events are a little more complicated
than semaphores and take up just a
hair more microprocessor time than
semaphores.
 ADV: A task can wait for any one of several events
at the same time, whereas it can only wait for one
semaphore.
 ADV: Some RTOSs make it convenient to use events
and make it inconvenient to use semaphores.