The document discusses classical synchronization problems including the producer-consumer problem (both bounded and unbounded buffer scenarios), the reader-writer problem, and the dining philosopher problem. It describes the mechanics of each problem, including processes, semaphores, and solutions to prevent deadlocks. Additionally, it introduces monitors as a tool for concurrency management, emphasizing their structure and implementation rules.

1. Classical problem of
Synchronization
• Producer-Consumer with an unbounded
buffer
• Producer-Consumer with a bounded buffer
• Reader-Writer problem
• Dining Philosopher problem

2. Producer-Consumer with an unbounded buffer:-
• A buffer of unbounded capacity is set aside to smooth
the speed difference between producer and consumer.
•A producer must be the first process to run in order to
provide the first item.
• A consumer process may run whenever there is more
than one item in the buffer produced but not yet
consumed.
•Producer may run at any time without restriction.

3. Variable produced: semaphore;
Process producer
begin
While true do
begin
produce
place_in_buffer
signal (produced)
other _producer _ processing
end (while)
End (producer)

4. Process consumer
begin
While true do
begin
wait (produced)
take _from _buffer
consume
other _consumer _ processing
end (while)
End (consumer)

5. Producer-Consumer with a bounded buffer
Process producer
begin
While true do
begin
wait (mayproduced)
pitem :=produce
wait (pmutex)
buffer [ in ]:=pitem
in:=in+1
signal(pmutex)
signal (mayconsume)
other _producer _ processing
end (while)
End (producer)

6. Process consumer
begin
While true do
begin
wait (mayconsumed)
wait(cmutex)
citem := buffer [ out ]
out :=out +1
signal (cmutex)
signal (mayproduce)
other _consumer_processing
end (while)
End (consumer)

7. Reader/Writer problem
Readcount:integer
mutex,write:semaphore (binary)
Process reader
Begin
While true do
begin
wait (mutex)
readercount := readercount + 1;
if readercount = 1 then wait(write)
Signal(mutex)
……[read]……
Wait(mutex)
readercount := readercount -1;
if readercount =0 then signal(write)
Signal(mutex)
Other processing
End{while}; end {reader}

8. Process writer
Begin
While true do
begin
wait (write)
….[writes]……
Signal(write)
Other processing
end {while};
end {writer}

9. Dining Philosopher problem
• The dining philosophers problem is summarized
as five philosophers sitting at a table doing one of
two things: eating or thinking.
• While eating, they are not thinking, and while
thinking, they are not eating. The five philosophers
sit at a circular table with a large bowl of rice in the
center.
• A chopstick is placed in between each pair of
adjacent philosophers, and as such, each
philosopher has one chopstick to his left and one
chopsticks to his right.
• it is assumed that a philosopher must eat with two
chopsticks. Each philosopher can only use the
chopsticks on his immediate left and immediate
right.
• The philosophers never speak to each other,
which creates a dangerous possibility of deadlock
when every philosopher holds a left fork and waits
perpetually for a right fork (or vice versa).

10. Solution :-
do {
wait (chopstick [i]);
wait (chopstick [ ( i+1 ) % 5 ]);
// eat
signal (chopstick [i]);
signal (chopstick [ ( i+1 ) % 5 ] );
//think
}while (true);
1. Allow at most four philosopher to be sitting simultaneously
2. Allow philosopher to pick up her chopsticks if both chopsticks are
available
3. Odd philosopher picks up first left and then right chopstick

11. What is a monitor?
• A collection of data and procedures
• High level of data abstraction tool that automatically
generates atomic operations on a given data structure
• A monitor has
 Shared data
 A set of atomic operations on that data
 A set of condition variables

12. Why monitors?
• Concurrency has always been an OS issue
– Resource allocation is necessary among competing
processes
– Timer interrupts
• Existing synchronization mechanisms
(semaphores, locks) are subject to hard-to-find
• Reduce probability of errors

13. Monitor Implementation
• Each monitor has one lock. Acquire lock when
begin a monitor operation, and release lock
when operation finishes

14. Rules to Follow with Monitors
• Any process can call a monitor procedure at
any time
• But only one process can be inside a monitor
at any time (mutual exclusion)
• No process can directly access a monitor’s
local variables (data encapsulation)
• A monitor may only access its local variables