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.

What is the Problem Statement?

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

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.
Here's a Solution
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

Dining Philosophers Problem

The dining philosophers problem is another classic synchronization problem which is used to
evaluate situations where there is a need of allocating multiple resources to multiple processes.

What is the Problem Statement?

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.

Here's the Solution

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.

 removed data from an occupied slot, thus making it empty.

What is Readers Writer Problem?

Readers writer problem is another example of a classic synchronization problem. There are many
variants of this problem, one of which is examined below.

The Problem Statement

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 writeris 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 Solution
From the above problem statement, it is evident that readers have higher priority than writer. If a
writer wants to write to the resource, it must wait until there are no readers currently accessing
that resource.
Here, we use one mutex m and a semaphore w. An integer variable read_count is used to
maintain the number of readers currently accessing the resource. The variable read_count is
initialized to 0. A value of 1 is given initially to m and w.
Instead of having the process to acquire lock on the shared resource, we use the mutex m to make
the process to acquire and release lock whenever it is updating the read_count variable.
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);
}
Here is the Code uncoded(explained)

 As seen above in the code for the writer, the writer just waits on the w semaphore until it gets a

chance to write to the resource.

 After performing the write operation, it increments w so that the next writer can access the

resource.

 On the other hand, in the code for the reader, the lock is acquired whenever the read_count is

updated by a process.

 When a reader wants to access the resource, first it increments the read_count value, then accesses

the resource and then decrements the read_count value.

 The semaphore w is used by the first reader which enters the critical section and the last reader

which exits the critical section.

 The reason for this is, when the first readers enters the critical section, the writer is blocked from

the resource. Only new readers can access the resource now.

 Similarly, when the last reader exits the critical section, it signals the writer using the w semaphore

because there are zero readers now and a writer can have the chance to access the resource.