Classical problems of Synchronization with Semaphore Solution
The following problems of synchronization are considered as classical problems:
1. Bounded-buffer (or Producer-Consumer) Problem,
2. Dining-Philosphers Problem,
3. Readers and Writers Problem,
BOUNDED BUFFER PROBLEM
Bounded buffer problem, which is also called producer consumer problem, is one of the
classic problems of synchronization.
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.
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.
Producer Operation:
The pseudocode of the producer function looks like this:
do {
wait(empty); // wait until empty>0 and then decrement ‘empty’
wait(mutex); // acquire lock
/* perform the
insert operation in a slot */
signal(mutex); // release lock
signal(full); // increment ‘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.
Consumer Operation:
The pseudocode of the consumer function looks like this:
do {
wait(full); // wait until full>0 and then decrement ‘full’
wait(mutex); // acquire the lock
/* perform the remove operation
in a slot */
signal(mutex); // release the lock
signal(empty); // increment ‘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.
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 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 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);
Explaination:
• 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.
DINING PHILOSOPHERS PROBLEM (DPP)
The dining philosophers problem states that there are 5 philosophers sharing a circular table
and they eat and think alternatively. There is a bowl of rice for each of the philosophers and 5
chopsticks. A philosopher needs both their right and left chopstick to eat. A hungry philosopher
may only eat if there are both chopsticks [Link] a philosopher puts down their
chopstick and begin thinking again.
The dining philosopher is a classic synchronization problem as it demonstrates a large class of
concurrency control problems.
Solution of Dining Philosophers Problem
A solution of the Dining Philosophers Problem is to use a semaphore to represent a chopstick.
A chopstick can be picked up by executing a wait operation on the semaphore and released by
executing a signal semaphore.
The structure of the chopstick is shown below:
semaphore chopstick [5];
Initially the elements of the chopstick are initialized to 1 as the chopsticks are on the table and
not picked up by a philosopher.
The structure of a random philosopher i is given as follows:
do {
wait( chopstick[i] );
wait( chopstick[ (i+1) % 5] );
. .
. EATING THE RICE
.
signal( chopstick[i] );
signal( chopstick[ (i+1) % 5] );
. THINKING
} while(1);
In the above structure, first wait operation is performed on chopstick[i] and chopstick[ (i+1) %
5]. This means that the philosopher i has picked up the chopsticks on his sides. Then the eating
function is performed.
After that, signal operation is performed on chopstick[i] and chopstick[ (i+1) % 5]. This means
that the philosopher i has eaten and put down the chopsticks on his sides. Then the philosopher
goes back to thinking.
Difficulty with the solution
The above solution makes sure that no two neighboring philosophers can eat at the same time.
But this solution can lead to a deadlock. This may happen if all the philosophers pick their left
chopstick simultaneously. Then none of them can eat and deadlock occurs.
Some of the ways to avoid deadlock are as follows:
• There should be at most four philosophers on the table.
• An even philosopher should pick the right chopstick and then the left chopstick while
an odd philosopher should pick the left chopstick and then the right chopstick.
• A philosopher should only be allowed to pick their chopstick if both are available at
the same time.
Department of Computer Science
GOVERNMENT FIRST GRADE COLLEGE, MALUR
Monitors in Process Synchronization
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.
Syntax:
Condition Variables:
Two different operations are performed on the condition variables of the monitor.
Wait.
signal.
let say we have 2 condition variables
condition x, y; // Declaring variable
Wait operation
[Link]() : Process performing wait operation on any condition variable are
suspended. The suspended processes are placed in block queue of that condition
variable.
Note: Each condition variable has its unique block queue.
Signal operation
[Link](): When a process performs signal operation on condition variable, one of
the blocked processes is given chance.
If (x block queue empty)
// Ignore signal
Department of Computer Science
GOVERNMENT FIRST GRADE COLLEGE, MALUR
else
// Resume a process from block queue.
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.
• Some languages that do support monitors are Java,C#,Visual Basic,Ada and
concurrent Euclid.
Department of Computer Science
GOVERNMENT FIRST GRADE COLLEGE, MALUR
CRITICAL REGION:
• A Critical Region is a section of code that is always executed under mutual exclusion.
• Critical regions shift the responsibility for enforcing mutual exclusion from the
programmer to the compiler.
• They consist of two parts:
o A variable that must be accessed under mutual exclusion
o A new language statement that identifies a critical region in which the variable is
accessed.
If two processes A and B are in ready queue.
If CPU is executing process A and process B in wait state. <
If an interrupt occurs for process A, The operating system suspends the execution
Department of Computer Science
GOVERNMENT FIRST GRADE COLLEGE, MALUR
of the first process, and store the current information of process A in its PCB and
context to the second process namely process B.
In doing So, program counter from PCB of process B is loaded and the execution
can continue with the new process.
Syllabus::
Process Synchronization and deadlocks: The Critical Section Problem, Synchronization
hardware, Semaphores, Classical problems of synchronization, Critical regions, monitors.
UNIVERISTY QUESTIONS BASED ON ABOVE SYLLABUS:
Section A:
1. What is semaphores? Metion any two types of semaphores
2. What is race condition?
3. What is monitor?
4. What is critical section? Explain
5. Explain swap() operation in process synchronization.
6. Difference between binary and counting semaphores?
7. What is mutual exclution
Section B
1. Write a short note on critical region
2. What is semaphores? Explain any two types of semaphores
3. Explain dining philosopher’s problem in synchronization
4. Define critical section problem? What are the requirements for critical
section problem
5. Explain any one classical problem of synchronization
6. Write a brief note on Peterson’s algorithm
7. What is monitor? Explain in detail.
