OPERATING SYSTEM

UNIT-2
Inter Process Communication (IPC)
 A process can be of two types:
i)Independent process.
ii)Co-operating process.
 An independent process is not affected by the execution of other processes
while a co-operating process can be affected by other executing processes.
 Though one can think that those processes, which are running independently,
will execute very efficiently, in reality, there are many situations when co-
operative nature can be utilized for increasing computational speed,
convenience, and modularity.
 Inter-process communication (IPC) is a mechanism that allows processes to
communicate with each other and synchronize their actions.
 The communication between these processes can be seen as a method of
co-operation between them. Processes can communicate with each other
through both:

1. Shared Memory
2. Message passing

Race Condition in Operating Systems (OS)

 The Race Condition is a condition which usually occurs in Multi Threading concept
which occurs in an Operating System.
 The Race Condition usually occurs at the case of Tube Light which has multiple
switches. This Tube Light with multiple switches is the biggest example for the Race
Condition which has occurred in Operating Systems.
 The Race Condition also occurs in the case of processes also. If we do not take care
of this Race Condition well then we might get stuck in a Deadlock too.
Examples of Race Condition:
Example 1: Tube Light ON and OFF
The Race Condition usually occurs at the case of Tube Light which has multiple switches.
This Tube Light with multiple switches is the biggest example for the Race Condition
which has occurred in Operating Systems.

Explanation

Consider a Tube Light, two switches. Let the two switches are connected to the Tube
Light and the Tube Light is in OFF State. Here, if on switch 1 the tube light gets switched
on. Then, if we on the switch 2 when switch 1 is in ON State, the Tube Light get switched
off. But, both the switched present are in ON State and the Tube Light is in OFF State.
Now, let us consider that the Tube Light is in OFF State and switch 1 and switch 2 are in
OFF State. Now, if we turn ON both the switches at a time then the Tube Light would be
ON State only. This is because of circuit breaker. One of the switch actions is tripped by
the circuit breaker present in the circuit. This is to prevent the functioning of switch going
irrelevant.

What if same condition is occurred in the computer? Here, the ON and OFF Conditions
gets replaced by Read and Write Operations. Here, the Tube Light is replaced with a
computer. Just imagine what happens if we are re writing the data on the computer while
the old data is being read. Because of this state, these conditions might occur:

1. Errors and Faults in Newly written data

2. Errors and Faults in Old written data
3. The Computer might gets crashed
4. The Data Corruption might occur.
5. The Data Stored might not be in order.

Race conditions result in inconsistent output and degrade our application's endurance
and confidence.

In operating systems, concurrency is achieved via threads. The capacity to carry out
many operations concurrently is known as concurrency. Concurrency is achieved in the
OS via threads. We may encounter circumstances where the threads processing the
shared data provide different results each time if many threads access shared data
without being synced with one another.
Race Conditions Identification or Detection in Operating
Systems (OS)
 The need for finding the Race Conditions is very important.
 If we fail to identify them, then we are going to lose so much data and data already
present is also going to go corrupt.
 So, it is very important for the user and the computer to find out the occurrence of
Race Condition in the Operating Systems (OS).
 Finding and detecting racial conditions is thought to be challenging.
 They are a semantic issue that might result from several potential coding errors.
 It is preferable to write code that avoids these issues from the outset.
 Tools for static and dynamic analysis are used by programmers to find race conditions.
Without starting the software, static testing tools scan everything.
 However, they tends to generate a lot of inaccurate reports.
 Although dynamic analysis methods provide fewer false positives, they could miss
race conditions that don't occur within the program itself.
 Data races, which happen when two threads simultaneously target the same memory
region and at least one of them performs a write operation, can occasionally result in
race conditions.
 Data races are simpler to spot than race conditions since they need particular
circumstances to manifest.
 Data race scenarios are kept an eye out for by tools like the Data Race Detector from
the Go Project.
 Race situations provide more significant issues and are more strongly related to
application semantics.

Race Condition in Critical Section Problem.

Critical Section Area

 The Critical Section Problem is a Code Snippet. This code snippet contains a few
variables.
 These variables can be accessed by a few processes. There is a condition for these
processes.
 The condition is that only one process can only enter the critical section.
 Remaining Processes which are interested to enter the critical section have to wait for
the process to complete its work and then enter the critical section.
 The portion of a piece of code that is performed by many threads is considered in
critical section of a code.
 The critical section area is vulnerable to a race condition because various outputs from
concurrently running threads potentially result in different orders of execution.
Critical Section Representation

The Problem is occurred when the Bank Account works at the same time. Due, to this
multiple accessing data gets corrupted.

What is Mutual Exclusion in OS?

 Mutual exclusion also known as Mutex is a unit of code that avert
contemporaneous access to shared resources.
 Mutual exclusion is concurrency control’s property that is installed for the objective of
averting race conditions.
 In simple words, it's a condition in which a thread of execution does not ever get
involved in a critical section at the same time as a concurrent thread of execution so
far using the critical section.
 This critical section can be a period for which the thread of execution uses the
shared resource which can be defined as a data object, that different concurrent
threads may attempt to alter (where the number of concurrent read operations
allowed is two but on the other hand two write or one read and write is not allowed,
as it may guide it to data instability).
 Mutual exclusion in OS is designed so that when a write operation is in the process
then another thread is not granted to use the very object before the first one has
done writing on the critical section after that releases the object because the rest of
the processes have to read and write it.

Why is Mutual Exclusion Required?

 An easy example of the importance of Mutual Exclusion can be envisioned by
implementing a linked list of multiple items, considering the fourth and fifth need
removal.
 The deletion of the node that sits between the other two nodes is done by modifying
the previous node’s next reference directing the succeeding node.
 In a simple explanation, whenever node “i” wants to be removed, at that moment
node “ith - 1” 's next reference is modified, directing towards the node “ith + 1”.
 Whenever a shared linked list is in the middle of many threads, two separate nodes
can be removed by two threads at the same time meaning the first thread modifies
node “ith - 1” next reference, directing towards the node “ith + 1”, at the same time
second thread modifies node “ith” next reference, directing towards the node “ith +
2”.
 Despite the removal of both achieved, linked lists required state is not yet attained
because node “i + 1” still exists in the list, due to node “ith - 1” next reference still
directing towards the node “i + 1”.
 Now, this situation is called a race condition. Race conditions can be prevented by
mutual exclusion so that updates at the same time cannot happen to the very bit
about the list.

Necessary Conditions for Mutual Exclusion

There are four conditions applied to mutual exclusion, which are mentioned
below :

 Mutual exclusion should be ensured in the middle of different processes

when accessing shared resources. There must not be two processes
within their critical sections at any time.
 Assumptions should not be made as to the respective speed of the
unstable processes.
 The process that is outside the critical section must not interfere with
another for access to the critical section.
 When multiple processes access its critical section, they must be
allowed access in a finite time, i.e. they should never be kept waiting in a
loop that has no limits.

Example of Mutual Exclusion

There are many types of mutual exclusion, some of them are

mentioned below :

 Locks :
It is a mechanism that applies restrictions on access to a resource when
multiple threads of execution exist.
 Recursive lock :
It is a certain type of mutual exclusion (mutex) device that is locked
several times by the very same process/thread, without making a
deadlock. While trying to perform the "lock" operation on any mutex may
 fail or block when the mutex is already locked, while on a recursive
mutex the operation will be a success only if the locking thread is the
one that already holds the lock.
 Semaphore :
It is an abstract data type designed to control the way into a shared
resource by multiple threads and prevents critical section problems in a
concurrent system such as a multitasking operating system. They are a
kind of synchronization primitive.
 Readers writer (RW) lock :
It is a synchronization primitive that works out reader-writer problems. It
grants concurrent access to the read-only processes, and writing
processes require exclusive access. This conveys that multiple threads
can read the data in parallel however exclusive lock is required for
writing or making changes in data. It can be used to manipulate access
to a data structure inside the memory.

Hardware Solutions
Here are some hardware solutions to the mutual exclusion problem in
operating systems (OS):
1. Disable interrupts:
 On single-processor systems, this is the simplest solution to achieve mutual exclusion.
 It prevents interrupt service routines from running, which prevents a process from being
preempted.
 However, disabling interrupts limits what software can do inside a critical section.
2. Test-and-set instruction:
 This hardware-based approach performs an atomic test-and-set operation on a shared
memory location.
 It allows only one thread to modify the value at a time.
3. Swap Algorithm:
 This algorithm uses two boolean variables, lock and key, to regulate mutual exclusion of
processes.
4. Unlock and lock Algorithm:
 This algorithm uses three boolean variables, lock, key, and waiting[i], for each process to
regulate mutual exclusion.

Turn Variable in Operating System

 The turn variable is defined as a synchronization mechanism that is
implemented in the user mode.
 The turn variable is also known as the Strict Alternation Approach. It is a
synchronization mechanism that is implemented for synchronizing two
processes.
 For synchronization, it makes use of a variable known as the turn variable.
 This approach is used only when working with two processes.

What is the Need for Turn Variable?

 The need for a turn variable arises due to the problem of the lock variable.
 In the lock variable approach, the process is able to enter into the critical
section only when the lock variable is set to 1.
 In the lock variable approach, more than one process has a lock variable
value of 1 at the same time.
 Due to such conditions, the lock variable is not able to guarantee mutual
execution.
 Therefore, there comes a need for a turn variable.

Features of Turn Variable

 Mutual exclusion: Mutual exclusion does not allow more than one process to
access the same shared resource at the same time. Turn variable ensures
mutual exclusion property.
 Progress: The turn variable does not guarantee progress. It follows the
alteration approach strictly.
 Portability: The turn variable is implemented in user mode and does not
require any kind of special instruction from the operating system. Therefore it
provides portability.
 Bounded waiting: Each process gets the chance, once a previous process is
executed the next process gets the chance therefore turn variable ensures
bounded waiting.
 Deadlock: The turn variable is free from deadlock. Only one process is in
a critical section at a time. Once the turn value is updated the next process
goes into the critical section.

Analysis of Strict Alternation approach

Let's analyze Strict Alternation approach on the basis of four requirements.
Mutual Exclusion
The strict alternation approach provides mutual exclusion in every case. This procedure
works only for two processes. The pseudo code is different for both of the processes. The
process will only enter when it sees that the turn variable is equal to its Process ID
otherwise not Hence No process can enter in the critical section regardless of its turn.

Progress
Progress is not guaranteed in this mechanism. If Pi doesn't want to get enter into the
critical section on its turn then Pj got blocked for infinite time. Pj has to wait for so long for
its turn since the turn variable will remain 0 until Pi assigns it to j.

Portability
The solution provides portability. It is a pure software mechanism implemented at user
mode and doesn't need any special instruction from the Operating System.

Peterson's Solution in OS
 Peterson's solution is a classic solution to the critical section problem.
 The critical section problem ensures that no two processes change or
modify a resource's value simultaneously.
 For example, let int a=5, and there are two processes p1 and p2 that
can modify the value of a. p1 adds 2 to a a=a+2 and p2 multiplies a with
2, a=a*2.
 If both processes modify the value of a at the same time, then a value
depends on the order of execution of the process.
 If p1 executes first, a will be 14; if p2 executes first, a will be 12.
 This change of values due to access by two processes at a time is the
cause of the critical section problem.
 The section in which the values are being modified is called the critical
section.
 There are three sections except for the critical sections: the entry
section,exit section, and the reminder section.

i) The process entering the critical region must pass the entry region in
which they request entry to the critical section.
ii) The process exiting the critical section must pass the exit region.
iii) The remaining code left after execution is in the remainder section.

Peterson's solution provides a solution to the following problems:

 It ensures that if a process is in the critical section, no other process

must be allowed to enter it. This property is termed mutual exclusion.
 If more than one process wants to enter the critical section, the process
that should enter the critical region first must be established. This is
termed progress.
 There is a limit to the number of requests that processors can make to
enter the critical region, provided that a process has already requested
to enter and is waiting. This is termed bounding.
 It provides platform neutrality as this solution is developed to run in
user mode, which doesn't require any permission from the kernel.

Example of Peterson’s Solution

Peterson's solution finds applications and examples of different problems in

Operating Systems.

 The producer-consumer problem can be solved using Peterson's

solution. Learn more about how synchronization is maintained
in producer-consumer problems.
  The logic used in a semaphore is similar to Peterson's solution.
The semaphores are used to solve many problems in OS.
 The most suited example is the usage of Peterson's solution in the
critical section problem.

Advantages of Peterson’s Solution

 Peterson's solution allows multiple processes to share and access a

resource without conflict between the resources.
 Every process gets a chance of execution.
 It is simple to implement and uses simple and powerful logic.
 It can be used in any hardware as it is completely software dependent
and executed in the user mode.
 Prevents the possibility of a deadlock.

Disadvantages of Peterson’s Solution

 The process may take a long time to wait for the other processes to
come out of the critical region. It is termed as Busy waiting.
 This algorithm may not work on systems having multiple CPUs.
 The Peterson solution is restricted to only two processes at a time.

Producer Consumer Problem

Before knowing what is Producer-Consumer Problem we have to know
what are Producer and Consumer.

 In operating System Producer is a process which is able to produce

data/item.
 Consumer is a Process that is able to consume the data/item
produced by the Producer.
 Both Producer and Consumer share a common memory buffer. This
buffer is a space of a certain size in the memory of the system which is
used for storage. The producer produces the data into the buffer and the
consumer consumes the data from the buffer.

So, what are the Producer-Consumer Problems?

1. Producer Process should not produce any data when the shared buffer
is full.
2. Consumer Process should not consume any data when the shared
buffer is empty.
3. The access to the shared buffer should be mutually exclusive i.e at a
time only one process should be able to access the shared buffer and
make changes to it.

Solution For Producer Consumer Problem

To solve the Producer-Consumer problem three semaphores variable are

used :

Semaphores are variables used to indicate the number of resources

available in the system at a particular time. semaphore variables are used
to achieve `Process Synchronization.

Full

The full variable is used to track the space filled in the buffer by the
Producer process. It is initialized to 0 initially as initially no space is filled by
the Producer process.

Empty

The Empty variable is used to track the empty space in the buffer. The
Empty variable is initially initialized to the BUFFER-SIZE as initially, the
whole buffer is empty.

Mutex

Mutex is used to achieve mutual exclusion. mutex ensures that at any

particular time only the producer or the consumer is accessing the buffer.

Mutex - mutex is a binary semaphore variable that has a value of 0 or 1.

We will use the Signal() and wait() operation in the above-mentioned

semaphores to arrive at a solution to the Producer-Consumer problem.

Signal() - The signal function increases the semaphore value by 1.

Wait() - The wait operation decreases the semaphore value by 1.

Semaphores
 A semaphore is a special kind of synchronization data that can be used only
through specific synchronization primitives.
 When a process performs a wait operation on a semaphore, the operation
checks whether the value of the semaphore is >0.
 If so, it decrements the value of the semaphore and lets the process
continue its execution; otherwise, it blocks the process on the semaphore.
 A signal operation on a semaphore activates a process blocked on the
semaphore if any, or increments the value of the semaphore by 1.
 Due to these semantics, semaphores are also called counting semaphores.
 The initial value of a semaphore determines how many processes can get
past the wait operation.
Semaphores are of two types:
1. Binary Semaphore –
This is also known as a mutex lock. It can have only two values – 0 and 1.
Its value is initialized to 1. It is used to implement the solution of critical
section problems with multiple processes.
2. Counting Semaphore –
Its value can range over an unrestricted domain. It is used to control access
to a resource that has multiple instances.

Limitations :
1. One of the biggest limitations of semaphore is priority inversion.
2. Deadlock, suppose a process is trying to wake up another process that is not
in a sleep state. Therefore, a deadlock may block indefinitely.
3. The operating system has to keep track of all calls to wait and signal the
semaphore.

Advantages of Semaphores:
 A simple and effective mechanism for process synchronization
 Supports coordination between multiple processes
 Provides a flexible and robust way to manage shared resources.
 It can be used to implement critical sections in a program.
 It can be used to avoid race conditions.
Disadvantages of Semaphores:
 It Can lead to performance degradation due to overhead associated with
wait and signal operations.
 Can result in deadlock if used incorrectly.
 It was proposed by Dijkstra in 1965 which is a very significant technique to
manage concurrent processes by using a simple integer value, which is
known as a semaphore. A semaphore is simply an integer variable that is
shared between threads. This variable is used to solve the critical section
problem and to achieve process synchronization in the multiprocessing
environment.
 It can cause performance issues in a program if not used properly.
 It can be difficult to debug and maintain.
 It can be prone to race conditions and other synchronization problems if not
used correctly.
 It can be vulnerable to certain types of attacks, such as denial of service
attacks.

Event Counters
 The Event Counters tab of the ACS Resources screen displays the event counters
for each customer. Each event counter is maintained separately.

 Event counters simply count an event. They may be accessed at runtime and can be
used, for example, for televoting. Counters can be queried in real-time on the
Statistics Chart screen.

 It is not possible to delete an event counter that is currently in use by a compiled

control plan. Editing an event counter will cause all compiled control plans that use
that record to be recompiled.

 The ACS system administrator allocates customers a maximum number of counters

on the Edit Customer Resource Limits screen. Users of sufficient privilege (level 4
and above) may add, delete, and rename their event counters within that limit.

Adding Event Counters

Follow these steps to add a new event counter.

1. On the Event Counters tab, click New.

Result: The New Event Counter screen is displayed.
2. In the Counter field, enter the name of the event counter.
Note: Event counter names must be unique for that customer, that is, two customers
may have counters called 'Stats1', but a customer may not have two counters called
'Stats1'.
3. Click Save.
Result: The details are saved and you return to the Event Counters tab.

Editing Event Counters

Follow these steps to edit an existing event counter.

1. On the Event Counters tab, select from the table the event counter record to edit.
2. Click Edit.
Result: The Edit Event Counter screen is displayed.
3. Change the details as required.
4. Click Save.
Result: The changes are saved to the database.

Deleting Event Counters

Follow these steps to delete an existing event counter.

1. On the Event Counters tab, select the event counter to delete.

2. Click Delete.
Result: The Confirm Delete prompt is displayed
3. Click OK.
Result: The event counter is removed from the database.

Monitors
1. A monitor is essentially a module that encapsulates a shared resource and
provides access to that resource through a set of procedures. The
procedures provided by a monitor ensure that only one process can access
the shared resource at any given time, and that processes waiting for the
resource are suspended until it becomes available.

2. Monitors are used to simplify the implementation of concurrent programs by

providing a higher-level abstraction that hides the details of synchronization.
Monitors provide a structured way of sharing data and synchronization
information, and eliminate the need for complex synchronization primitives
such as semaphores and locks.
3. The key advantage of using monitors for process synchronization is that they
provide a simple, high-level abstraction that can be used to implement
complex concurrent systems. Monitors also ensure that synchronization is
encapsulated within the module, making it easier to reason about the
correctness of the system.

 The monitor is one of the ways to achieve Process synchronization.

 The monitor is supported by programming languages to achieve mutual
exclusion between processes. For example Java Synchronized methods.
 Java provides wait() and notify() constructs.

1. It is the collection of condition variables and procedures combined together

in a special kind of module or a package.
2. The processes running outside the monitor can’t access the internal variable
of the monitor but can call procedures of the monitor.
3. Only one process at a time can execute code inside monitors.

Advantages of Monitor
 Monitors have the advantage of making parallel programming easier and
less error prone than using techniques such as semaphore.

Disadvantages of Monitor
 Monitors have to be implemented as part of the programming language .
 The compiler must generate code for them.
 This gives the compiler the additional burden of having to know what
operating system facilities are available to control access to critical sections
in concurrent processes.

Message Passing
 So message passing means how a message can be sent from one end to
the other end.
 Either it may be a client-server model or it may be from one node to another
node.
 The formal model for distributed message passing has two timing models
one is synchronous and the other is asynchronous.
The fundamental points of message passing are:
1. In message-passing systems, processes communicate with one another by
sending and receiving messages over a communication channel. So how the
arrangement should be done?
2. The pattern of the connection provided by the channel is described by some
topology systems.
3. The collection of the channels are called a network.
4. So by the definition of distributed systems, we know that they are
geographically set of computers. So it is not possible for one computer to
directly connect with some other node.
5. So all channels in the Message-Passing Model are private.
6. The sender decides what data has to be sent over the network. An example
is, making a phone call.
7. The data is only fully communicated after the destination worker decides to
receive the data. Example when another person receives your call and starts
to reply to you.
8. There is no time barrier. It is in the hand of a receiver after how many rings
he receives your call. He can make you wait forever by not picking up the
call.
9. For successful network communication, it needs active participation from
both sides.

Message Passing Model

Algorithm:
1. Let us consider a network consisting of n nodes named p0, p1, p2……..pn-
1 which are bidirectional point to point channels.

2. Each node might not know who is at another end. So in this way, the
topology would be arranged.
3. Whenever the communication is established and whenever the message
passing is started then only the processes know from where to where the
message has to be sent.
Advantages of Message Passing Model :
1. Easier to implement.
2. Quite tolerant of high communication latencies.
3. Easier to build massively parallel hardware.
4. It is more tolerant of higher communication latencies.
5. Message passing libraries are faster and give high performance.

Disadvantages of Message Passing Model :

1. Programmer has to do everything.
2. Connection setup takes time that’s why it is slower.
3. Data transfer usually requires cooperative operations which can be difficult
to achieve.
4. It is difficult for programmers to develop portable applications using this
model because message-passing implementations commonly comprise a
library of subroutines that are embedded in source code. Here again, the
programmer has to do everything on his own.

Reader Writer Problem in OS

 The Reader-Writer Problem is a classic synchronization issue in operating
systems (OS) and concurrent programming.
 It revolves around the challenge of managing shared resources,
specifically a data structure or a section of code, that is accessed by
multiple threads.
 The problem arises when balancing the need for simultaneous access by
multiple readers against exclusive access for a single writer to ensure data
consistency and integrity.
 Various solutions such as locks, semaphores, and other synchronization
mechanisms have been proposed to tackle this issue efficiently.

How the Reader-Writer Problem is OS Handled?

 In order to handle the problem, it must be ensured that no concurrent

processes cause any form of data inconsistency in the operating system.

 The reader-writer problem in os can be assumed as follows:-

 There are multiple processes that can be either readers and writers with a
shared resource between them, let us suppose it as a file or a database.

 In case there are two processes with both trying to access the resource
simultaneously at the same instance.

 Although it does not matter how many readers can access it

simultaneously, it must be kept in mind that only one writer can write it at a
time.

Various Cases of Reader-Writer Problem

There are certain cases that I must look forward to understanding the reader-
writer problem in OS and how it impacts the data inconsistency problem that
must be avoided.

Case One
Two processes cannot be allowed to write into shared data parallelly thus they
must wait to get access to write into it.

Case Two
Even if one process is writing on data and the other is reading then also they
cannot be allowed to have the access to shared resources for the reason that
a reader will be reading an incomplete value in this case.
Case Three
The other similar scenario where one process is reading from the data and
another writing on it, on the shared resource, it cannot be allowed. Because
the writer updates some data that is not available to the reader. The solution
being that the writer completes successfully and gives access.

Case Four
In the case that both processes are reading the data then sharing of
resources among both the processes will be allowed as it is a case free from
any such anomaly because reading does not modify the pre-existing data.

The Solution to the Problem

 In order to solve the problem, we maintain three variables, namely, mutex,

semaphore, and readCount.

 Mutex makes the process to release and acquire a lock when the
readCount is being updated.

 The lock is acquired when the readCount is updated and decremented

back after it has done performing the operation.

 The writer waits for the semaphore until it is its turn to write and increments
for other processes to write.

 The idea remains to use semaphores when a reader enters the critical
section up until it exits the critical section such that no writer can enter in
between as it can cause data inconsistency.

 A semaphore is used to prevent writers from accessing the resource while

there are one or more readers accessing it.

DINING PHILOSOPHERS PROBLEM

 The dining philosopher's problem is the classical problem of
synchronization which says that Five philosophers are sitting around a
circular table and their job is to think and eat alternatively.
 A bowl of noodles is placed at the center of the table along with five
chopsticks for each of the philosophers.
 To eat a philosopher needs both their right and a left chopstick.
 A philosopher can only eat if both immediate left and right chopsticks of
the philosopher is available.
 In case if both immediate left and right chopsticks of the philosopher are
not available then the philosopher puts down their (either left or right)
chopstick and starts thinking again.

The solution of the Dining Philosophers Problem

The steps for the Dining Philosopher Problem solution using semaphores
are as follows
1. Initialize the semaphores for each fork to 1 (indicating that they are available).
2. Initialize a binary semaphore (mutex) to 1 to ensure that only one philosopher
can attempt to pick up a fork at a time.
3. For each philosopher process, create a separate thread that executes the
following code:
While true:
 Think for a random amount of time.
 Acquire the mutex semaphore to ensure that only one philosopher can
attempt to pick up a fork at a time.
 Attempt to acquire the semaphore for the fork to the left.

 If successful, attempt to acquire the semaphore for the fork to the right.
 If both forks are acquired successfully, eat for a random amount of time and
then release both semaphores.
 If not successful in acquiring both forks, release the semaphore for the fork
to the left (if acquired) and then release the mutex semaphore and go back
to thinking.
4. Run the philosopher threads concurrently.

 By using semaphores to control access to the forks, the Dining Philosopher

Problem can be solved in a way that avoids deadlock and starvation.
 The use of the mutex semaphore ensures that only one philosopher can
attempt to pick up a fork at a time, while the use of the fork semaphores
ensures that a philosopher can only eat if both forks are available.
 Overall, the Dining Philosopher Problem solution using semaphores is a
classic example of how synchronization mechanisms can be used to solve
complex synchronization problems in concurrent programming.
Drawback of dining philosophers problem
 The main challenge in the dining philosophers’ problem is preventing
deadlocks.
 Deadlock occurs when each philosopher picks up one chopstick and is waiting
indefinitely for the other chopstick.
 This situation leads to a system-wide halt, and no philosopher can make
progress.
 Resolving the deadlock issue while allowing all philosophers to eat without
starvation requires careful synchronization and resource allocation.

Deadlock System model

A deadlock occurs when a set of processes is stalled because each process is
holding a resource and waiting for another process to acquire another resource.
In the diagram below, for example, Process 1 is holding Resource 1 while
Process 2 acquires Resource 2, and Process 2 is waiting for Resource 1.

System Model :
 For the purposes of deadlock discussion, a system can be modeled as a
collection of limited resources that can be divided into different categories and
allocated to a variety of processes, each with different requirements.
 Memory, printers, CPUs, open files, tape drives, CD-ROMs, and other
resources are examples of resource categories.
 By definition, all resources within a category are equivalent, and any of the
resources within that category can equally satisfy a request from that
category. If this is not the case (i.e. if there is some difference between the
resources within a category), then that category must be subdivided further.
For example, the term “printers” may need to be subdivided into “laser
printers” and “color inkjet printers.”
 Some categories may only have one resource.
 The kernel keeps track of which resources are free and which are allocated,
to which process they are allocated, and a queue of processes waiting for this
resource to become available for all kernel-managed resources. Mutexes or
wait() and signal() calls can be used to control application-managed resources
(i.e. binary or counting semaphores. )
 When every process in a set is waiting for a resource that is currently assigned
to another process in the set, the set is said to be deadlocked.

Principles of Deadlock
A deadlock situation on a resource can arise if and only if all of the following conditions
hold simultaneously in a system:

 Mutual exclusion: At least one resource must be held in a non-shareable mode. Otherwise,
the processes would not be prevented from using the resource when necessary. Only one
process can use the resource at any given instant of time.
 Hold and wait or resource holding: a process is currently holding at least one resource
and requesting additional resources which are being held by other processes.
 No preemption: a resource can be released only voluntarily by the process holding it.
 Circular wait: each process must be waiting for a resource which is being held by another
process, which in turn is waiting for the first process to release the resource. In general,
there is a set of waiting processes, P = {P1, P2, …, PN}, such that P1 is waiting for a
resource held by P2, P2 is waiting for a resource held by P3 and so on until PN is waiting for
a resource held by P1.
 These four conditions are known as the Coffman conditions from their first
description in a 1971 article by Edward G. Coffman, Jr.
 While these conditions are sufficient to produce a deadlock on single-instance
resource systems, they only indicate the possibility of deadlock on systems having
multiple instances of resources.

Deadlock Characterization
 A deadlock happens in operating system when two or more processes need some
resource to complete their execution that is held by the other process.
 A deadlock occurs if the four Coffman conditions hold true. But these conditions are not
mutually exclusive. They are given as follows −

Mutual Exclusion

 There should be a resource that can only be held by one process at a time.
 In the diagram below, there is a single instance of Resource 1 and it is held by Process 1
only.

Hold and Wait

 A process can hold multiple resources and still request more resources from other
processes which are holding them.
 In the diagram given below, Process 2 holds Resource 2 and Resource 3 and is
requesting the Resource 1 which is held by Process 1.

No Preemption

 A resource cannot be preempted from a process by force. A process can only release a
resource voluntarily.
 In the diagram below, Process 2 cannot preempt Resource 1 from Process 1.
 It will only be released when Process 1 relinquishes it voluntarily after its execution is
complete.
Circular Wait

 A process is waiting for the resource held by the second process, which is waiting for the
resource held by the third process and so on, till the last process is waiting for a resource
held by the first process.
 This forms a circular chain. For example: Process 1 is allocated Resource2 and it is
requesting Resource 1.
 Similarly, Process 2 is allocated Resource 1 and it is requesting Resource 2. This forms
a circular wait loop.

Methods for handling Deadlock

1. Deadlock Ignorance
 Deadlock Ignorance is the most widely used approach among all the mechanism.

 This is being used by many operating systems mainly for end user uses.
 In this approach, the Operating system assumes that deadlock never occurs. It
simply ignores deadlock.
 This approach is best suitable for a single end user system where User uses the
system only for browsing and all other normal stuff.

2. Deadlock prevention
 Deadlock happens only when Mutual Exclusion, hold and wait, No preemption and
circular wait holds simultaneously.
 If it is possible to violate one of the four conditions at any time then the deadlock can
never occur in the system.
 The idea behind the approach is very simple that we have to fail one of the four
conditions but there can be a big argument on its physical implementation in
the system.

i) Mutual Exclusion
 Mutual section from the resource point of view is the fact that a resource can never be used
by more than one process simultaneously which is fair enough but that is the main reason
behind the deadlock.
 If a resource could have been used by more than one process at the same time then the
process would have never been waiting for any resource.

ii) Spooling
 For a device like printer, spooling can work. There is a memory associated with the printer
which stores jobs from each of the process into it.
 Later, Printer collects all the jobs and print each one of them according to FCFS.
 By using this mechanism, the process doesn't have to wait for the printer and it can continue
whatever it was doing. Later, it collects the output when it is produced.
Although, Spooling can be an effective approach to violate mutual exclusion but it suffers from
two kinds of problems.

1. This cannot be applied to every resource.

2. After some point of time, there may arise a race condition between the processes to get
space in that spool.

iii) Hold and Wait

 Hold and wait condition lies when a process holds a resource and waiting for some other
resource to complete its task.
 Deadlock occurs because there can be more than one process which are holding one
resource and waiting for other in the cyclic order.
 However, we have to find out some mechanism by which a process either doesn't hold any
resource or doesn't wait.
 That means, a process must be assigned all the necessary resources before the execution
starts. A process must not wait for any resource once the execution has been started.
 The problem with the approach is:

1. Practically not possible.

2. Possibility of getting starved will be increases due to the fact that some process may hold
a resource for a very long time.

3. Deadlock avoidance
 In deadlock avoidance, the operating system checks whether the system is in safe
state or in unsafe state at every step which the operating system performs.
 The process continues until the system is in safe state. Once the system moves to
unsafe state, the OS has to backtrack one step.
 In simple words, The OS reviews each allocation so that the allocation doesn't cause
the deadlock in the system.

4. Deadlock detection and recovery

 This approach let the processes fall in deadlock and then periodically check whether
deadlock occur in the system or not.
 If it occurs then it applies some of the recovery methods to the system to get rid of
deadlock.

 In single instanced resource types, if a cycle is being formed in the system then
there will definitely be a deadlock.
 On the other hand, in multiple instanced resource type graph, detecting a cycle is
not just enough.
Preempt the resource

 We can snatch one of the resources from the owner of the resource (process) and
give it to the other process with the expectation that it will complete the execution and
will release this resource sooner.
 Well, choosing a resource which will be snatched is going to be a bit difficult.

Rollback to a safe state

 System passes through various states to get into the deadlock state. The operating
system can roll back the system to the previous safe state.
 For this purpose, OS needs to implement check pointing at every state.

Kill a process

 Killing a process can solve our problem but the bigger concern is to decide which
process to kill.
 Generally, Operating system kills a process which has done least amount of work until
now.

Kill all process

 This is not a suggestible approach but can be implemented if the problem becomes
very serious.
 Killing all process will lead to inefficiency in the system because all the processes will
execute again from starting.