Operating Systems

10EC65

Unit 8

Message Passing

Reference Book:
Operating Systems - A Concept based Approach
D. M. Dhamdhare, TMH, 3rd Edition, 2010
Shrishail Bhat, AITM Bhatkal
Overview of Message Passing

Message passing is one way in which processes interact with one another

Process sends a message to process by executing the statement

send ( ,<message>)
The compiled code of the send statement invokes the library module
send
send makes a system call send, with and the message as parameters
Execution of the statement receive ( , msg_area), where msg_area
is an area in s address space, results in a system call receive
Shrishail Bhat, AITM Bhatkal
Overview of Message Passing (continued)

The semantics of message passing are as follows:

At a send call by , the kernel checks whether process is blocked
on a receive call for receiving a message from process
If so, it copies the message into msg_area and activates
If process has not already made a receive call, the kernel
arranges to deliver the message to it when eventually makes a
receive call
When process receives the message, it interprets the message
and takes an appropriate action

Shrishail Bhat, AITM Bhatkal

Overview of Message Passing (continued)

Processes may exist in the same computer or in different computers

connected to a network
Uses of message passing:
Client-server paradigm
To communicate between components of a microkernel-based OS and user processes
To provide services such as the print service to processes within an OS
To provide Web-based services to client processes located in other computers
Backbone of higher-level communication protocols
For communicating between computers or for providing the electronic mail facility
Parallel and distributed programs
To implement communication between tasks

Shrishail Bhat, AITM Bhatkal

Message Passing using Shared Variables

In principle, message passing can be performed by using

shared variables
For example, msg_area in Figure 9.1 could be a shared
variable
could deposit a value or a message in it and could collect
it from there
However, this approach is cumbersome because the processes
would have to create a shared variable with the correct size
and share its name

Shrishail Bhat, AITM Bhatkal

Producers Consumers Problem

The producers consumers problem with a single buffer, a

single producer process, and a single consumer process can be
implemented by message passing

Shrishail Bhat, AITM Bhatkal

Producers Consumers Problem (continued)

The solution does not use any shared variables

Instead, process , which is the producer process, has a variable
called buffer and process , which is the consumer process, has a
variable called message_area
The producer process produces in buffer and sends the contents of
buffer in a message to the consumer
The consumer receives the message in message_area and
consumes it from there
The send system call blocks the producer process until the message
is delivered to the consumer, and the receive system call blocks the
consumer until a message is sent to it
Shrishail Bhat, AITM Bhatkal
Issues in Message Passing

Two important issues in message passing are:

Naming of processes
Names may be explicitly indicated or deduced by the kernel in some manner
Delivery of messages
Whether sender should be blocked until delivery
What the order is in which messages are delivered to a destination process
How exceptional conditions are handled

Shrishail Bhat, AITM Bhatkal

Direct and Indirect Naming

In direct naming, sender and receiver processes mention each

others name

In symmetric naming, both sender and receiver processes specify each

others name
In asymmetric naming, receiver does not name process from which it
wishes to receive a message; kernel gives it a message sent to it by some
process
In indirect naming, processes do not mention each others name in
send and receive statements

Shrishail Bhat, AITM Bhatkal

Blocking and Nonblocking Sends

A blocking send blocks sender process until message is delivered to

destination process
Synchronous message passing
Simplifies design of concurrent processes
A nonblocking send call permits sender to continue its operation
after send call
Asynchronous message passing
Enhances concurrency between sender and receiver
In both cases, receive is typically blocking
Kernel performs message buffering pending delivery
Shrishail Bhat, AITM Bhatkal
Exceptional Conditions in Message Passing

To facilitate handling exceptional conditions, send and receive take

two additional parameters:
Flags indicate how exceptions should be handled
status_area is for storing code concerning outcome
Some exceptional conditions:
1. Destination process mentioned in send doesnt exist
2. Source process does not exist (symmetric naming)
3. send cannot be processed (out of buffer memory)
4. No message exists for process when it makes receive
5. A set of processes become deadlocked when one is blocked on a receive

Shrishail Bhat, AITM Bhatkal

Exceptional Conditions in Message Passing (continued)

In cases 1 and 2, the kernel may abort the process that made the
send or receive call and set its termination code to describe the
exceptional condition
In case 3, the sender process may be blocked until some buffer
space becomes available
In case 4, a process may prefer the standard action, which is that
the kernel should block the process until a message arrives for it, or
it may prefer an action of its own choice, like waiting for a specified
amount of time before giving up
The deadlock situation of case 5 is an example of a severe
exception. Most operating systems do not handle this particular
exception because it incurs the overhead of deadlock detection
Shrishail Bhat, AITM Bhatkal
Implementing Message Passing

When a process sends a message to some process by using a

nonblocking send, the kernel builds an interprocess message
control block (IMCB) to store all information needed to deliver the
message
The control block contains names of the sender and destination
processes, the length of the message, and the text of the message
The control block is allocated a buffer in the kernel area
When process makes a receive call, the kernel copies the
message from the appropriate IMCB into the message area
provided by
Shrishail Bhat, AITM Bhatkal
Implementing Message Passing (continued)

Shrishail Bhat, AITM Bhatkal

Implementing Message Passing (continued)

Figure 9.4 shows the organization of IMCB lists when blocking

sends and FCFS message delivery are used
In symmetric naming, a separate list is used for every pair of
communicating processes
When a process performs a receive call to receive a message
from process , the IMCB list for the pair is used to deliver
the message
In asymmetric naming, a single IMCB list can be maintained per
recipient process
When a process performs a receive, the first IMCB in its list is
processed to deliver a message

Shrishail Bhat, AITM Bhatkal

Delivery of Interprocess Messages

When a process sends a message to process , the kernel

delivers the message to immediately if is currently blocked on
a receive call for a message from , or from any process
After delivering the message, the kernel must also change the state
of to ready
If process has not already performed a receive call, the kernel
must arrange to deliver the message when performs a receive
call later
Thus, message delivery actions occur at both send and receive calls

Shrishail Bhat, AITM Bhatkal

Delivery of Interprocess Messages (continued)

The kernel uses an event control block (ECB) to note actions that
should be performed when an anticipated event occurs

The ECB contains three fields:

Description of the anticipated event
Id of the process that awaits the event
An ECB pointer for forming ECB lists
Shrishail Bhat, AITM Bhatkal
Delivery of Interprocess Messages (continued)

When makes a send call, the kernel checks whether an ECB

exists for the send call by , i.e., whether had made a
receive call and was waiting for to send a message
If it is not the case, the kernel knows that the receive call
would occur sometime in future, so it creates an ECB for the
event receive from by and specifies as the process
that will be affected by the event
Process is put into the blocked state and the address of the
ECB is put in the event info field of its PCB

Shrishail Bhat, AITM Bhatkal

Delivery of Interprocess Messages (continued)

When process makes a receive call before makes a send

call, an ECB for a send to by event is created
The id of is put in the ECB to indicate that the state of will
be affected when the send event occurs

Shrishail Bhat, AITM Bhatkal

Kernel Actions in Message Passing

Shrishail Bhat, AITM Bhatkal

Kernel Actions in Message Passing (continued)

At a send call, the kernel creates an IMCB even though a sender process is
blocked until message delivery
When process sends a message to process , the kernel first checks
whether the send was anticipated, i.e., whether an ECB was created for the
send event
It will have happened if process has already made a receive call for a
message from
If this is the case, action S3 immediately delivers the message to and
changes its state from blocked to ready
The ECB and the IMCB are now destroyed
If an ECB for send does not exist, step S4 creates an ECB for a receive call by
process , which is now anticipated, blocks the sender process, and
enters the IMCB in the IMCB list of process
Shrishail Bhat, AITM Bhatkal
Kernel Actions in Message Passing (continued)

At a receive call, if a matching send has already occurred, a

message is delivered to process and is activated
Otherwise, an ECB is created for a send call and is blocked

Shrishail Bhat, AITM Bhatkal

Mailboxes

Mailbox: repository for interprocess messages

Has a unique name
Owner is typically the process that created it
Indirect naming
Only owner process can receive messages
Any process that knows name of a mailbox can send messages to it
Kernel may provide fixed set of mailbox names, or it may
permit user processes to assign the names
Varying levels of confidentiality

Shrishail Bhat, AITM Bhatkal

Mailboxes (continued)

Shrishail Bhat, AITM Bhatkal

Mailboxes (continued)

Process creates the mailbox, using the statement

create_mailbox
Process sends a message to the mailbox, using the mailbox
name in its send statement
If has not already executed a receive statement, the kernel
would store the message in a buffer

Shrishail Bhat, AITM Bhatkal

Mailboxes (continued)

Kernel may require a process to explicitly connect to a

mailbox before starting to use it, and to disconnect when it
finishes using it
It can destroy a mailbox if no process is connected to it
Alternatively, it may permit the owner of a mailbox to destroy
it
It should inform all processes that have connected to the mailbox
The kernel may permit the owner of a mailbox to transfer the
ownership to another process

Shrishail Bhat, AITM Bhatkal

Advantages of Mailboxes

Use of a mailbox has following advantages:

Anonymity of receiver
A mailbox relieves the sender process of the need to know the identity of the
receiver
If the OS permits the ownership of a mailbox to be changed dynamically, one
process can readily take over the service of another
Classification of messages
Through use of separate mailboxes for different classes
A process may create several mailboxes, and use each mailbox to receive
messages of a specific kind

Shrishail Bhat, AITM Bhatkal

Use of Mailboxes An Airline Reservation System

It consists of a centralized data base and a set of booking

processes
Each process represents one booking agent.

Shrishail Bhat, AITM Bhatkal

An Airline Reservation System (continued)

It uses three mailboxes named enquire, book, and cancel, and

expects a booking process to send enquiry, booking, and
cancellation messages to these mailboxes, respectively
The server processes all pending cancellation messages before
processing a booking request or an enquiry, and performs
bookings before enquiries

Shrishail Bhat, AITM Bhatkal

Message Passing in Unix

Three interprocess communication facilities:

Pipe:
Data transfer facility
Unnamed pipes can be used only by processes that belong to the same
process tree, while named pipes can be used by other processes as well.
Message queue: analogous to a mailbox
Used by processes within Unix system domain
Access permissions indicate which processes can send or receive messages
Socket: one end of a communication path
Can be used for setting up communication paths between processes within
the Unix system domain and within certain Internet domains

Shrishail Bhat, AITM Bhatkal

Message Passing in Unix (continued)

One common feature: processes can communicate without

knowing each others identities

Shrishail Bhat, AITM Bhatkal

Message Passing in Unix: Pipes

FIFO mechanism for data transfer between processes called

reader and writer processes
Usually implemented in file system
But, data put into a pipe can be read only once
Removed from pipe when it is read by a process
Two kinds of pipes: named and unnamed
Created through the system call pipe
A named pipe has an entry in a directory
Like a file, but size is limited and kernel treats it as a queue
Shrishail Bhat, AITM Bhatkal
Message Passing in Unix: Pipes (continued)

When data is written, it is entered into the pipe by using the write
offset, and the write offset is incremented by the number of bytes
written
Data written by multiple writers gets mixed up if their writes are
interleaved
If a pipe is full, a process wishing to write data into it would be put
to sleep
A read operation is performed by using the read offset, and the
read offset is incremented by the number of bytes read
A process reading data from a pipe would be put to sleep if the
pipe is empty

Shrishail Bhat, AITM Bhatkal

Message Passing in Unix: Message Queues

Analogous to a mailbox
Created and owned by one process
Creator specifies access permissions for send/receive
Size specified at the time of its creation
A message queue is created by a system call msgget (key, flag)
where key specifies the name of the message queue and flag
indicates some options
Each message consists of a message type, in the form of an integer,
and a message text

Shrishail Bhat, AITM Bhatkal

Message Passing in Unix: Message Queues (continued)

Messages are sent and received by using following system calls:

msgsnd (msgqid, msg_struct_ ptr, count, flag)
msgrcv (msgqid, msg_struct_ ptr, maxcount, type, flag)
The count and flag parameters of a msgsnd call specify the number of
bytes in a message and the actions to be taken if sufficient space is not
available in the message queue, e.g., whether to block the sender, or
return with an error code
msg_struct_ ptr is the address of a structure that contains the type of a
message, which is an integer, and the text of the message
maxcount is the maximum length of the message
type indicates the type of the message to be received

Shrishail Bhat, AITM Bhatkal

Message Passing in Unix: Message Queues (continued)

The cancellation, booking, and enquiry messages are assigned the

types 1, 2, and 3, respectively
The msgrcv call with type = 4 and flag = no wait returns a
cancellation message, if one is present
If no cancellation messages are present, it returns a bookings
message if present, or an enquiry message

Shrishail Bhat, AITM Bhatkal

Message Passing in Unix: Sockets

A socket is one end of a communication path

Can be used for interprocess communication within the Unix system
domain and in the Internet domain
The client and server processes create a socket each
These two sockets are then connected together to set up a communication
path for sending and receiving messages
Server can set up communication paths with many clients
simultaneously
A server creates a socket s using the system call
s = socket (domain, type, protocol)
The socket call returns a socket identifier to the process

Shrishail Bhat, AITM Bhatkal

Message Passing in Unix: Sockets (continued)

The server process now makes a call bind (s, addr, . . . ), which
binds the socket to the address addr
The server performs the system call listen (s, . . . ) to indicate that it
is interested in considering some connect calls to its socket s
A client creates a socket by means of a socket call, e.g.,
cs = socket (. . .), and attempts to connect it to a servers socket
using the system call
connect (cs, server_socket_addr, server_socket_addrlen)
The kernel now creates a new socket with the call
new_soc = accept (s, client_addr, client_addrlen)
The server uses this socket to implement the client server
communication
Shrishail Bhat, AITM Bhatkal
Message Passing in Unix: Sockets (continued)

Typically, after the connect call the server forks a new process to
handle the new connection
Leaves the original socket created by the server process free to accept
more connections through listen and connect calls
Communication between a client and a server is implemented
through read and write or send and receive calls.
A send call has the format
count = send (s, message, message_length, flags)
A socket connection is closed by using the call close (s) or
shutdown (s, mode)
Sockets use indirect naming: address (domain) used instead of
process ids
Shrishail Bhat, AITM Bhatkal