💡

Unit 3: Interprocess
Communication
Type Unit 3

Reviewed

Writing Not started

Interprocess Communication
Interprocess communication (IPC) is a mechanism that allows two or more
processes to communicate with each other. IPC is essential for the efficient
operation of computer systems. It enables different programs to run in parallel, share
data, and communicate with each other.
There are different types of IPC mechanisms, each with its own advantages and
disadvantages. Some of the most common IPC mechanisms include:

Shared memory: This is a memory area that is shared by two or more

processes. Processes can access the shared memory to read and write data.

Message passing: This is a mechanism where processes send messages to

each other. Messages can contain any type of data, and they can be sent in
either a blocking or non-blocking manner.

Semaphores: This is a synchronization mechanism that allows processes to

control access to shared resources. Semaphores can be used to prevent race
conditions and deadlocks.

Mutexes: This is a synchronization mechanism that allows processes to lock

and unlock shared resources. Mutexes can be used to prevent race conditions.

IPC is a complex topic, and there are many different factors to consider when
designing an IPC mechanism. However, IPC is an essential part of operating
systems, and it is a powerful tool that can be used to improve the performance and
scalability of applications.

Unit 3: Interprocess Communication 1

 Here are some of the benefits of IPC:

Improved performance: IPC can improve the performance of applications by

allowing them to share data and communicate with each other more efficiently.

Increased scalability: IPC can help applications to scale by allowing them to be

divided into smaller processes that can communicate with each other.

Enhanced flexibility: IPC can give applications more flexibility by allowing them
to be designed in a modular way.

Here are some of the challenges of IPC:

Complexity: IPC can be complex to implement and use.

Security: IPC can be a security risk if it is not implemented correctly.

Performance: IPC can have a negative impact on performance if it is not used

efficiently.

Overall, IPC is a powerful tool that can be used to improve the performance,
scalability, and flexibility of applications. However, it is important to be aware of the
challenges of IPC before using it.

Race Conditions
A race condition is an undesirable situation that occurs when two or more processes
or threads access a shared resource at the same time and the outcome of the
execution depends on the order in which the processes or threads access the
resource.

Race conditions are a common problem in operating systems, and they can be
difficult to debug. There are a number of ways to prevent race conditions, including:

Using locks: A lock is a mechanism that ensures that only one process or
thread can access a shared resource at a time.

Using semaphores: A semaphore is a counting semaphore that can be used to

control access to a shared resource.

Using atomic operations: An atomic operation is an operation that cannot be

interrupted by another process or thread.

Using synchronization primitives: Synchronization primitives are a set of tools

that can be used to prevent race conditions.

Race conditions can have a number of negative consequences, including:

Unit 3: Interprocess Communication 2

 Inconsistent data: If two or more processes or threads access a shared
resource at the same time, the data in the resource may become inconsistent.

System crashes: Race conditions can sometimes cause system crashes.

Performance degradation: Race conditions can sometimes degrade the

performance of a system.

It is important to be aware of race conditions and to take steps to prevent them.

There are a number of tools and techniques that can be used to prevent race
conditions, and the best approach will vary depending on the specific application.

Here are some examples of race conditions:

Two processes are trying to update the same variable at the same
time. The outcome of the update will depend on the order in which the
processes access the variable.

Two threads are trying to access the same file at the same time. The
outcome of the access will depend on the order in which the threads access the
file.

Two processes are trying to send a message to the same queue at the
same time. The outcome of the send operation will depend on the order in
which the processes send the message.

Critical Section
A critical section is a segment of code that is executed by multiple concurrent
processes or threads, and which accesses shared resources. These resources may
include shared memory, files, or I/O devices. The critical section cannot be executed
by more than one process at a time; operating systems face the difficulties in
allowing and disallowing the processes from entering the critical section. The critical
section problem is used to design a set of protocols which can ensure that the Race
condition among the processes will never arise.

Here are some of the key properties of a critical section:

Mutual exclusion: Only one process can be in the critical section at a time.

Progress: If a process is not using the critical section, then it should not stop
any other process from accessing it. In other words, any process can enter a
critical section if it is free.

Unit 3: Interprocess Communication 3

 Bounded waiting: Each process must have a limited waiting time. It should not
wait endlessly to access the critical section.

There are a number of different ways to implement critical sections in operating

systems. Some of the most common methods include:

Locks: A lock is a synchronization primitive that can be used to ensure that only
one process can access a shared resource at a time.

Semaphores: A semaphore is a counting semaphore that can be used to

control access to a shared resource.

Spin locks: A spin lock is a simple lock that can be implemented using a busy
wait loop.

Mutexes: A mutex is a lock that can be used to protect shared resources.

The best way to implement critical sections in operating systems depends on the
specific needs of the application. For example, if the application needs to guarantee
that only one process can access a shared resource at a time, then a lock might be
a good choice. If the application needs to be able to handle a large number of
concurrent processes, then a semaphore might be a good choice.

Critical sections are an important part of operating systems. They are used to ensure
that shared resources are accessed in a safe and consistent manner. By
understanding critical sections and the different ways to implement them, you can
help to ensure the stability and performance of your applications.

Solution for Critical section

There are many solutions to the critical section problem. Some of the most common
solutions include:

Peterson's algorithm uses two variables, flag and turn , to ensure that only
one process can be in the critical section at a time.

Semaphores are a more general solution to the critical section problem.

Semaphores are used to control access to shared resources.

Monitors are a more structured way of using semaphores. Monitors provide a

way to group together shared resources and the code that accesses them.

Hardware solutions can also be used to solve the critical section problem.
These solutions use hardware instructions that can atomically access and
modify shared variables.

Unit 3: Interprocess Communication 4

 The following are the three requirements that any solution to the critical section
problem must satisfy:

Mutual exclusion: Only one process can be in the critical section at a time.

Progress: If no process is in the critical section, and there exists a process that
wishes to enter its critical section, it should not have to wait indefinitely to enter
it.

Bounded waiting: Each process must have a limited waiting time. It should not
wait endlessly to access the critical section.

The choice of which solution to use depends on the specific needs of the application.
For example, if the application needs to be very efficient, then a hardware solution
may be the best choice. If the application needs to be flexible, then a software
solution such as semaphores or monitors may be a better choice.

Here is a table summarizing the different solutions to the critical section problem:

Solution Description Advantages Disadvantages

Not as flexible
Peterson's Uses two variables to ensure
Simple and efficient. as other
algorithm mutual exclusion.
solutions.

Use a counting semaphore to Can be more

Flexible and general-
Semaphores control access to shared complex than
purpose.
resources. other solutions.

Provides a structured
Use a monitor object to group Can be more
way to solve the
Monitors together shared resources and complex than
critical section
the code that accesses them. other solutions.
problem.
Use hardware instructions to Not as flexible
Hardware
atomically access and modify Very efficient. as other
solutions
shared variables. solutions.

Peterson’s Solution
Peterson's solution is a classic solution to the critical section problem. It uses two
shared variables, flag and turn , to ensure that only one process can be in the
critical section at a time.
The following is the pseudocode for Peterson's solution:

Unit 3: Interprocess Communication 5

 procedure critical_section(i)
flag[i] := true
turn := j
while (flag[j] and turn == j) do
continue
// critical section
flag[i] := false
end procedure

The flag array is used to indicate whether a process is interested in entering the
critical section. The turn variable is used to determine which process has the right
to enter the critical section.

The algorithm works as follows:

1. Process i sets its flag variable to true .

2. Process i sets the turn variable to the other process's ID.

3. Process i enters a loop and repeatedly checks the other process's flag
variable and the turn variable. If the other process's flag variable is true and
the turn variable is equal to the other process's ID, then process i knows that
the other process is also interested in entering the critical section. In this case,
process i waits in the loop.

4. If the other process's flag variable is false or the turn variable is not equal to
the other process's ID, then process i knows that it has the right to enter the
critical section. Process i enters the critical section and performs the required
operations.

5. When process i is finished with the critical section, it sets its flag variable to
false .

Peterson's solution satisfies the three requirements of the critical section problem:

Mutual exclusion: Only one process can be in the critical section at a time. This
is guaranteed by the fact that the turn variable is only set to one process's ID at
a time.

Progress: If no process is in the critical section, and there exists a process that
wishes to enter its critical section, it should not have to wait indefinitely to enter
it. This is guaranteed by the fact that process i will eventually be able to enter
the critical section if the other process is not interested in entering the critical
section.

Unit 3: Interprocess Communication 6

 Bounded waiting: Each process must have a limited waiting time. It should not
wait endlessly to access the critical section. This is guaranteed by the fact that
process i will only wait in the loop for a finite amount of time.

Peterson's solution is a simple and efficient solution to the critical section problem.
However, it is not as flexible as some other solutions, such as semaphores or
monitors.

Mutual Exclusion
Mutual exclusion is a property of concurrency control, which is instituted for the
purpose of preventing race conditions. It is the requirement that one thread of
execution never enters a critical section while a concurrent thread of execution is
already accessing said critical section, which refers to an interval of time during
which a thread of execution accesses a shared resource or shared memory.

In an operating system, mutual exclusion is used to ensure that only one process
can access a shared resource at a time. This is important to prevent race conditions,
which can occur when two or more processes are accessing the same resource at
the same time and modifying it.

There are a number of different ways to implement mutual exclusion in an operating

system. Some common methods include:

Locks: A lock is a synchronization primitive that allows a process to acquire

exclusive access to a resource. When a process acquires a lock, no other
process can acquire the same lock until the first process releases it.

Semaphores: A semaphore is a synchronization primitive that allows a process

to wait for a resource to become available. When a process acquires a
semaphore, it decrements the semaphore's value. If the semaphore's value is
zero, the process waits until the value is incremented by another process.

Monitors: A monitor is a synchronization construct that combines locks and

condition variables. A monitor allows a process to acquire exclusive access to a
resource and wait for a condition to become true.

The choice of which method to use for mutual exclusion in an operating system
depends on a number of factors, including the type of resource to be protected, the
number of processes that will be accessing the resource, and the performance
requirements of the system.

Here are some examples of mutual exclusion in operating systems:

Unit 3: Interprocess Communication 7

 When a process is writing to a file, it must acquire a lock on the file to prevent
other processes from accessing the file while it is being written.

When a process is accessing a shared memory region, it must acquire a lock on

the memory region to prevent other processes from accessing the memory
region while it is being used.

When a process is waiting for an event to occur, it can acquire a semaphore to

wait for the event to occur.

Mutual exclusion is an important concept in operating systems and is used to

prevent race conditions and ensure the correct operation of shared resources

Hardware solution
Hardware solutions in operating systems are used to solve problems that are difficult
or inefficient to solve in software. Some common hardware solutions in operating
systems include:

Memory management: Hardware memory management is used to allocate and

deallocate memory for processes. This is done by the hardware, which allows
the operating system to focus on other tasks.

I/O: Hardware I/O is used to transfer data between the computer and peripheral
devices. This is done by the hardware, which allows the operating system to
focus on other tasks.

Synchronization: Hardware synchronization is used to ensure that multiple

processes do not access shared resources at the same time. This is done by the
hardware, which allows the operating system to avoid race conditions.

Interrupt handling: Hardware interrupt handling is used to handle interrupts

from peripheral devices. This is done by the hardware, which allows the
operating system to continue running without being interrupted.

Hardware solutions can improve the performance and efficiency of operating

systems. They can also make it easier to write operating systems, as the operating
system does not have to worry about implementing certain features in software.

Here are some specific examples of hardware solutions in operating systems:

Test-and-set: This is a hardware instruction that atomically tests and sets a bit.
It is used to implement locks in operating systems.

Unit 3: Interprocess Communication 8

 Swap: This is a hardware instruction that atomically swaps the values of two
registers. It is used to implement mutexes in operating systems.

Compare-and-swap: This is a hardware instruction that atomically compares

the value of a memory location with a value and, if they are equal, sets the
memory location to a new value. It is used to implement atomic operations in
operating systems.

Hardware solutions are an important part of operating systems. They can improve
the performance, efficiency, and security of operating systems.

Semaphores
Semaphores are a synchronization mechanism in operating systems that are used to
control access to shared resources. They are typically implemented as integer
variables, and their values are used to track the number of processes that are
allowed to access the shared resource.
Semaphores have two operations:

wait: This operation decrements the value of the semaphore. If the value of the
semaphore is zero, the process is blocked until the value of the semaphore is
incremented by another process.

signal: This operation increments the value of the semaphore. If the value of the
semaphore is positive, a process that is blocked on the semaphore is unblocked.

Semaphores are used to solve a variety of synchronization problems in operating

systems. Some common problems that can be solved using semaphores include:

Mutual exclusion: Semaphores can be used to ensure that only one process
can access a shared resource at a time.

Producer-consumer problem: Semaphores can be used to solve the producer-

consumer problem, which is a problem of ensuring that two processes, a
producer and a consumer, can access a shared resource safely.

Race conditions: Semaphores can be used to prevent race conditions, which

are errors that can occur when two or more processes are accessing the same
resource at the same time and modifying it.

Semaphores are a powerful tool for synchronization in operating systems. They are
simple to use and can be implemented in a variety of programming languages.
Here are some of the advantages of using semaphores:

Unit 3: Interprocess Communication 9

 Simple to use: Semaphores are a simple concept to understand and use. They
can be implemented in a variety of programming languages.

Efficient: Semaphores are an efficient way to synchronize access to shared

resources. They do not waste CPU time by busy waiting.

Robust: Semaphores are a robust way to synchronize access to shared

resources. They can be used to solve a variety of synchronization problems.

Here are some of the disadvantages of using semaphores:

Not deadlock-free: Semaphores can be used to create deadlocks. This is a

problem where two or more processes are waiting for each other to release a
resource, and they will never be able to continue.

Not starvation-free: Semaphores can be used to create starvation. This is a

problem where one process is always waiting for a resource, and it will never be
able to get the resource.

Overall, semaphores are a powerful tool for synchronization in operating systems.

They are simple to use, efficient, and robust. However, they can be used to create
deadlocks and starvation.

Here are some examples of how semaphores are used in operating systems:

File locking: Semaphores are used to lock files in operating systems. This
ensures that only one process can access a file at a time.

Mutual exclusion: Semaphores are used to implement mutual exclusion in

operating systems. This ensures that only one process can access a critical
section at a time.

Producer-consumer problem: Semaphores are used to solve the producer-

consumer problem in operating systems. This ensures that producers and
consumers can access a shared buffer safely.

Semaphores are a valuable tool for synchronization in operating systems. They are
simple to use, efficient, and robust. However, they can be used to create deadlocks
and starvation.

Event Counters
Event counters are a type of performance counter that can be used to monitor the
activity of an operating system or application. Event counters are typically used to

Unit 3: Interprocess Communication 10

 measure the number of times an event occurs, such as the number of times a file is
opened or the number of times a process is created.
Event counters can be used to monitor a variety of different events, including:

File system activity: Event counters can be used to monitor the number of files
that are opened, closed, read, or written.

Process activity: Event counters can be used to monitor the number of

processes that are created, terminated, or suspended.

Network activity: Event counters can be used to monitor the number of network
packets that are sent or received.

Memory activity: Event counters can be used to monitor the amount of memory
that is allocated, freed, or used.

Event counters can be used to troubleshoot problems, identify performance

bottlenecks, and optimize the performance of an operating system or application.
There are two main types of event counters:

Hardware event counters: These event counters are implemented in the

hardware of the computer. They are typically more accurate than software event
counters, but they are also more expensive.

Software event counters: These event counters are implemented in the

software of the operating system. They are less accurate than hardware event
counters, but they are also less expensive.

Event counters can be used with a variety of different tools, including:

Performance Monitor: This is a tool that is included with Windows operating

systems. It can be used to monitor a variety of different performance counters,
including event counters.

Perfmon: This is a tool that is included with Linux operating systems. It can be
used to monitor a variety of different performance counters, including event
counters.

Wireshark: This is a tool that can be used to capture and analyze network
traffic. It can be used to monitor network event counters.

Event counters are a valuable tool for monitoring the activity of an operating system
or application. They can be used to troubleshoot problems, identify performance
bottlenecks, and optimize the performance of an operating system or application.

Unit 3: Interprocess Communication 11

 Monitors
Monitors are a synchronization mechanism that allows multiple processes to
coordinate access to shared resources. Monitors are typically implemented as a
special type of object that contains data structures and procedures. The procedures
in a monitor are called entry procedures, and they can only be executed by one
process at a time.

When a process enters a monitor, it acquires a lock on the monitor. This prevents
other processes from entering the monitor until the first process leaves. The first
process can then access the data structures in the monitor and execute the entry
procedures. When the process is finished, it releases the lock on the monitor,
allowing other processes to enter.

Monitors are a powerful tool for synchronization in operating systems. They are easy
to use and can be implemented in a variety of programming languages.

Here are some of the advantages of using monitors:

Easy to use: Monitors are a simple concept to understand and use. They can
be implemented in a variety of programming languages.

Efficient: Monitors are an efficient way to synchronize access to shared

resources. They do not waste CPU time by busy waiting.

Robust: Monitors are a robust way to synchronize access to shared resources.

They can be used to solve a variety of synchronization problems.

Here are some of the disadvantages of using monitors:

Not deadlock-free: Monitors can be used to create deadlocks. This is a problem

where two or more processes are waiting for each other to release a resource,
and they will never be able to continue.

Not starvation-free: Monitors can be used to create starvation. This is a

problem where one process is always waiting for a resource, and it will never be
able to get the resource.

Overall, monitors are a powerful tool for synchronization in operating systems. They
are simple to use, efficient, and robust. However, they can be used to create
deadlocks and starvation.

Here are some examples of how monitors are used in operating systems:

Mutual exclusion: Monitors are used to implement mutual exclusion in

operating systems. This ensures that only one process can access a critical

Unit 3: Interprocess Communication 12

 section at a time.

Producer-consumer problem: Monitors are used to solve the producer-

consumer problem in operating systems. This ensures that producers and
consumers can access a shared buffer safely.

Race conditions: Monitors can be used to prevent race conditions, which are
errors that can occur when two or more processes are accessing the same
resource at the same time and modifying it.

Monitors are a valuable tool for synchronization in operating systems. They are
simple to use, efficient, and robust. However, they can be used to create deadlocks
and starvation.

Message Passing
Message passing is a technique for communication between processes in a
concurrent system. In message passing, processes send and receive messages to
communicate with each other. Messages are typically small units of data, such as
integers or strings.

Message passing is a popular technique for communication between processes

because it is simple and efficient. Messages can be sent and received
asynchronously, which means that the sender and receiver of a message do not
have to be synchronized. This makes message passing well-suited for concurrent
systems, where multiple processes are running at the same time.
There are two main types of message passing:

Direct message passing: In direct message passing, processes send

messages directly to each other. This is the simplest type of message passing,
but it can be inefficient if there are many processes in the system.

Indirect message passing: In indirect message passing, processes send

messages to a message queue. The message queue then delivers the
messages to the appropriate processes. This is a more efficient way to send
messages in large systems, but it is more complex to implement.

Message passing is a powerful technique for communication between processes in a

concurrent system. It is simple, efficient, and well-suited for large systems.

Here are some of the advantages of using message passing:

Simple: Message passing is a simple concept to understand and implement.

Unit 3: Interprocess Communication 13

 Efficient: Message passing is an efficient way to communicate between
processes.

Flexible: Message passing is a flexible way to communicate between

processes.

Robust: Message passing is a robust way to communicate between processes.

Here are some of the disadvantages of using message passing:

Not deadlock-free: Message passing can be used to create deadlocks. This is

a problem where two or more processes are waiting for each other to send a
message, and they will never be able to continue.

Not starvation-free: Message passing can be used to create starvation. This is

a problem where one process is always waiting for a message, and it will never
be able to receive a message.

Overall, message passing is a powerful technique for communication between

processes in a concurrent system. It is simple, efficient, and flexible. However, it can
be used to create deadlocks and starvation.

Unit 3: Interprocess Communication 14