Process Synchronization in OS (Operating System)

When two or more process cooperates with each other, their order of execution must be
preserved otherwise there can be conflicts in their execution and inappropriate outputs
can be produced.

A cooperative process is the one which can affect the execution of other process or can
be affected by the execution of other process. Such processes need to be synchronized
so that their order of execution can be guaranteed.

The procedure involved in preserving the appropriate order of execution of cooperative

processes is known as Process Synchronization. There are various synchronization
mechanisms that are used to synchronize the processes

Race Condition

When more than one process is either running the same code or modifying the same
memory or any shared data, there is a risk that the result or value of the shared data
may be incorrect because all processes try to access and modify this shared resource.
Thus, all the processes race to say that my result is correct. This condition is called
the race condition. Since many processes use the same data, the results of the
processes may depend on the order of their execution.

Critical Section Problem in OS (Operating System)

Critical Section is the part of a program which tries to access shared resources. That
resource may be any resource in a computer like a memory location, Data structure,
CPU or any IO device.

In order to synchronize the cooperative processes, our main task is to solve the critical
section problem. We need to provide a solution in such a way that the following
conditions can be satisfied.

The following three requirements must be met by a solution to the critical section
problem:

 Mutual exclusion: If a process is running in the critical section, no other process

should be allowed to run in that section at that time.
 Progress: If no process is still in the critical section and other processes are
waiting outside the critical section to execute, then any one of the threads must
be permitted to enter the critical section. The decision of which process will enter
the critical section will be taken by only those processes that are not executing in
the remaining section.
 No starvation: Starvation means a process that keeps waiting forever to access
the critical section but never gets a chance. No starvation is also known as
Bounded Waiting.
o A process should not wait forever to enter inside the critical section.
o When a process submits a request to access its critical section, there
should be a limit or bound, which is the number of other processes that
are allowed to access the critical section before it.
  After this bond is reached, this process should be allowed to access the critical
section.

Semaphores

A semaphore is a signaling mechanism, and a process can signal a process that is

waiting on a semaphore.

Semaphores make use of the wait() and signal() functions for synchronization among the
processes.
Binary Semaphores

Binary Semaphores can only have one of two values: 0 or 1. Because of their capacity to
ensure mutual exclusion, they are also known as mutex locks.

 A single binary semaphore is shared between multiple processes.

 When the semaphore is set to 1, it means some process is working on its critical
section, and other processes need to wait, and if the semaphore is set to 0, that
means any process can enter the critical section.

Hence, whenever the binary semaphore is set to 0, any process can then enter its
critical section by setting the binary semaphore to 1. When it has completed its critical
section, it can reset the binary semaphore to 0, enabling another process to enter it.

Counting Semaphores

Counting Semaphores can have any value and are not limited to a certain area. They
can be used to restrict access to a resource that has a concurrent access limit.

Counting semaphore indicates that a process can access the resource if it has a value
greater than 0. If it is set to 0, no other process can access the resource

Bounded Buffer Problem

Bounded buffer problem, which is also called producer consumer
problem, is one of the classic problems of synchronization. Let's start by
understanding the problem here, before moving on to the solution and
program code.

Bounded buffer Problem Example

There is a buffer of n slots and each slot is capable of storing one unit of
data. There are two processes running,
namely, producer and consumer, which are operating on the buffer.
Bounded Buffer Problem(producer Consumer problem)

A producer tries to insert data into an empty slot of the buffer. A

consumer tries to remove data from a filled slot in the buffer. As you
might have guessed by now, those two processes won't produce the
expected output if they are being executed concurrently.

There needs to be a way to make the producer and consumer work in an

independent manner.

Now let's see the solutions to the above problem.

One solution of this problem is to use semaphores. The semaphores which

will be used here are:

 m, a binary semaphore which is used to acquire and release the lock.

 empty, a counting semaphore whose initial value is the number of slots

in the buffer, since, initially all slots are empty.

 full, a counting semaphore whose initial value is 0.

At any instant, the current value of empty represents the number of

empty slots in the buffer and full represents the number of occupied slots
in the buffer.

The Producer Operation

The pseudocode of the producer function looks like this:

do
{
// wait until empty > 0 and then decrement 'empty'
wait(empty);
// acquire lock
wait(mutex);

/* perform the insert operation in a slot */

// release lock
signal(mutex);
// increment 'full'
signal(full);
}
while(TRUE);

 Looking at the above code for a producer, we can see that a producer first
waits until there is atleast one empty slot.
  Then it decrements the empty semaphore because, there will now be one
less empty slot, since the producer is going to insert data in one of those
slots.

 Then, it acquires lock on the buffer, so that the consumer cannot access
the buffer until producer completes its operation.

 After performing the insert operation, the lock is released and the value
of full is incremented because the producer has just filled a slot in the
buffer.

The Consumer Operation

The pseudocode for the consumer function looks like this:

do
{
// wait until full > 0 and then decrement 'full'
wait(full);
// acquire the lock
wait(mutex);

/* perform the remove operation in a slot */

// release the lock

signal(mutex);
// increment 'empty'
signal(empty);
}
while(TRUE);

 The consumer waits until there is atleast one full slot in the buffer.

 Then it decrements the full semaphore because the number of occupied

slots will be decreased by one, after the consumer completes its
operation.

 After that, the consumer acquires lock on the buffer.

 Following that, the consumer completes the removal operation so that the
data from one of the full slots is removed.

 Then, the consumer releases the lock.

 Finally, the empty semaphore is incremented by 1, because the consumer

has just removed data from an occupied slot, thus making it empty.
Dining Philosophers Problem
 The dining philosopher's problem involves the allocation of limited
resources to a group of processes in a deadlock-free and starvation-
free manner.
 There are five philosophers sitting around a table, in which there are
five chopsticks/forks kept beside them and a bowl of rice in the
centre, When a philosopher wants to eat, he uses two chopsticks -
one from their left and one from their right. When a philosopher
wants to think, he keeps down both chopsticks at their original
place.

Consider there are five philosophers sitting around a circular dining table.
The dining table has five chopsticks and a bowl of rice in the middle as
shown in the below figure.

Dining Philosophers Problem

At any instant, a philosopher is either eating or thinking. When a

philosopher wants to eat, he uses two chopsticks - one from their left and
one from their right. When a philosopher wants to think, he keeps down
both chopsticks at their original place.

Now let's see the solutions to the above problem.

From the problem statement, it is clear that a philosopher can think for an
indefinite amount of time. But when a philosopher starts eating, he has to
stop at some point of time. The philosopher is in an endless cycle of
thinking and eating.

An array of five semaphores, stick[5], for each of the five chopsticks.

The code for each philosopher looks like:

while(TRUE)
{
wait(stick[i]);
/*
mod is used because if i=5, next
chopstick is 1 (dining table is circular)
*/
wait(stick[(i+1) % 5]);

/* eat */
signal(stick[i]);
 signal(stick[(i+1) % 5]);
/* think */
}

When a philosopher wants to eat the rice, he will wait for the chopstick at
his left and picks up that chopstick. Then he waits for the right chopstick
to be available, and then picks it too. After eating, he puts both the
chopsticks down.

But if all five philosophers are hungry simultaneously, and each of them
pickup one chopstick, then a deadlock situation occurs because they will
be waiting for another chopstick forever. The possible solutions for this
are:

 A philosopher must be allowed to pick up the chopsticks only if both

the left and right chopsticks are available.

 Allow only four philosophers to sit at the table. That way, if all the
four philosophers pick up four chopsticks, there will be one
chopstick left on the table. So, one philosopher can start eating and
eventually, two chopsticks will be available. In this way, deadlocks
can be avoided.

Readers Writer Problem

There is a shared resource which should be accessed by multiple processes.
There are two types of processes in this context. They
are reader and writer. Any number of readers can read from the shared
resource simultaneously, but only one writer can write to the shared
resource. When a writer is writing data to the resource, no other process can
access the resource. A writer cannot write to the resource if there are non
zero number of readers accessing the resource at that time.

The code for the writer process looks like this:

while(TRUE)

wait(w);

/* perform the write operation */

signal(w);

}
And, the code for the reader process looks like this:

while(TRUE)

//acquire lock

wait(m);

read_count++;

if(read_count == 1)

wait(w);

//release lock

signal(m);

/* perform the reading operation */

// acquire lock

wait(m);

read_count--;

if(read_count == 0)

signal(w);

// release lock

signal(m);