The document discusses two synchronization problems: the producer-consumer problem and the readers-writers problem. The producer-consumer problem involves processes that share a fixed-size buffer, with one process producing items and putting them in the buffer while another process consumes items from the buffer. The readers-writers problem involves multiple reader processes that only read shared data and writer processes that can read and write shared data, requiring synchronization to prevent writers from interfering with readers. Solutions to both problems using semaphores and monitors are presented.

1. • PRODUCER AND CONSUMER PROBLEM
• READERS/WRITER PROBLEM
Submitted By,
Ambooj Yadav
&
Hina Firdaus
M.Tech CSE, 1st
year

2. What is the need of synchronization?
For getting shared access to resources (variables, buffers,
devices, etc.)
For interruptless communicating
Cases where cooperating processes need not
synchronize to share resources:
All processes are read only.
All processes are write only.
One process writes, all other processes read.

3. In synchronization we will discuss two problem
mainly:-
Producer and Consumer problem
Readers and writers problem

4. Problem and Consumer system:
It is a system where one system produce items that will be
used by other system.
Examples
shared printer, the printer here acts the consumer, and
the computers that produce the documents to be
printed are the consumers.
Sensors network, where the sensors here the producers,
and the base stations (sink) are the producers.

5. It is also called bounded buffer problem .
The producer-consumer problem illustrates the need for
synchronization in systems where many processes share a
resource.
In the problem, two processes share a fixed-size buffer.
One process produces information and puts it in the
buffer, while the other process consumes information
from the buffer.
These processes do not take turns accessing the buffer,
they both work concurrently.

6. Start by imagining an unbounded (infinite) buffer
Producer process writes data to buffer
 Writes to In and moves rightwards
Consumer process reads data from buffer
 Reads from Out and moves rightwards
 Should not try to consume if there is no data

7. Bounded buffer: size ‘N’
 Access entry 0… N-1, then “wrap around” to 0 again
Producer process writes data to buffer
 Must not write more than ‘N’ items more than consumer “ate”
Consumer process reads data from buffer
 Should not try to consume if there is no data

8. Pseudo code for Producer:
While(Items_number ==buffer size);
//waiting since the buffer is full
Buffer[i]=next_produced_item;
i=(i+1)%Buffer_size;
Items_number++;

9. Pseudo code for Consumer:
while (Items_number == 0 ;
// do nothing since the buffer is empty
Consumed _item= buffer[j];
j = (j + 1) % Buffer_size;
Items_number--;

10. A number of applications:
 Data from bar-code reader consumed by device driver
 Data in a file you want to print consumed by printer spooler,
which produces data consumed by line printer device driver
 Web server produces data consumed by client’s web browser
Thought questions: where’s the bounded buffer?

11. Solving with semaphores
We’ll use two kinds of semaphores
We’ll use counters to track how much data is in the
buffer
One counter counts as we add data and stops the producer if
there are N objects in the buffer
A second counter counts as we remove data and stops a
consumer if there are 0 in the buffer
Idea: since general semaphores can count for us, we
don’t need a separate counter variable
Why do we need a second kind of semaphore?
We’ll also need a mutex semaphore

12. Shared: Semaphores mutex, empty, full;
Init: mutex = 1; /* for mutual exclusion*/
empty = N; /* number empty buf entries */
full = 0; /* number full buf entries */
Producer
do {
. . .
// produce an item in nextp
. . .
P(empty);
P(mutex);
. . .
// add nextp to buffer
. . .
V(mutex);
V(full);
} while (true);
Consumer
do {
P(full);
P(mutex);
. . .
// remove item to nextc
. . .
V(mutex);
V(empty);
. . .
// consume item in nextc
. . .
} while (true);

13. Monitor: object with a set of monitor procedures and
only one thread may be active (i.e. running one of the
monitor procedures) at a time

14. Compiler automatically inserts lock and unlock
operations upon entry and exit of monitor procedures

15. Two condition variables
has_empty: buffer has at
least one empty slot
has_full: buffer has at
least one full slot
nfull: number of filled
slots
Need to do our own
counting for condition
variables

17. Semaphores are sticky: they have memory,
sem_post() will increment the semaphore counter,
even if no one has called sem_wait()
Condition variables are not: if no one is waiting for a
signal(), this signal() is not saved
 Despite the difference, they are as powerful

18. Wait(s) and signal(s) are scattered among several
processes therefore it is difficult to understand their effect.
Usage must be correct in all the processes.
One bad process or one program error can kill the whole
system.

19. R
R
R
W

20. A data set is shared among a number of concurrent
processes
Readers – only read the data set; they do not
perform any updates
Writers – can both read and write.
Many threads share an object in memory
Some write to it, some only read it
Only one writer can be active at a time
Any number of readers can be active
simultaneously

21. One issue we need to settle, to clarify problem
statement.
Suppose that a writer is active and a mixture of readers
and writers now shows up. Who should get in next?
Or suppose that a writer is waiting and an endless of
stream of readers keeps showing up. Is it fair for them
to become active?
We’ll favor a kind of back-and-forth form of
fairness:
Once a reader is waiting, readers will get in next.
If a writer is waiting, one writer will get in next.

22. Example: making an airline reservation
 When you browse to look at flight schedules the web site is acting
as a reader on your behalf
 When you reserve a seat, the web site has to write into the
database to make the reservation
 a web server cache needs to quickly serve the same static page for
many thousands of requests. Occasionally however an author may
decide to update the page.

23. The structure of a Readers-writers process using mutex:
Shared variables: Semaphore mutex, wrl;
integer rcount;
Init: mutex = 1, wrl = 1, rcount = 0;
Writer
do {
P(wrl);
. . .
/*writing is performed*/
. . .
V(wrl);
}while(TRUE);
Reader
do {
P(wrl);
. . .
/*Reading is performed*/
. . .
V(wrl);
}while(TRUE);

24. The structure of a reader process using semaphore:
do {
P(mutex);
rcount++;
if (rcount == 1)
P(wrl);
V(mutex);
. . .
/*reading is performed*/
. . .
P(mutex);
rcount--;
if (rcount == 0)
V(wrl);
V(mutex);
}while(TRUE);

25. If there is a writer
 First reader blocks on wrl
 Other readers block on mutex
Once a reader is active, all readers get to go through
 Trick question: Which reader gets in first?
The last reader to exit signals a writer
 If no writer, then readers can continue
If readers and writers waiting on wrl, and writer exits
 Who gets to go in first?
Why doesn’t a writer need to use mutex?

26. Why doesn’t a
writer need to use
mutex?

27. If readers are active, no writer can enter
The writers wait doing a P(wrl)
While writer is active, nobody can enter
Any other reader or writer will wait
But back-and-forth switching is buggy:
Any number of readers can enter in a row
Readers can “starve” writers
With semaphores, building a solution that has the
desired back-and-forth behavior is really, really
tricky!
We recommend that you try, but not too hard…

28. readers-writers : monitor; begin
readercount : integer;
busy : boolean;
OKtoread, OKtowrite : condition;
procedure startread;
Begin
if busy then OKtoread.wait;
readercount := readercount + 1;
OKtoread.signal; (* Once one reader can start, they all can *)
end startread;
procedure endread;
begin readercount := readercount - 1;
if readercount = 0 then OKtowrite.signal;
end endread;

29. procedure startwrite;
begin
if busy OR readercount != 0 then OKtowrite.wait;
busy := true;
end startwrite;
procedure endwrite;
begin busy := false;
if OKtoread.queue then OKtoread.signal
else OKtowrite.signal;
end endwrite;
begin (* initialization *)
readercount := 0;
busy := false;
end;
end readers-writers;

30. For proper sychronization, reader processes must call
the startread procedure before accessing the file
(shared resource) and call the endread when the read
is finished.
Likewise, writer processes must call startwrite before
modifying the file and call endwrite when the write is
finished.
The monitor uses the boolean variable busy to
indicate whether a writer is active (i.e., accessing the
file) and readercount to keep track of the number of
active readers.

31. A writer, on invoking startwrite, proceeds only when
no other writer or readers are active.
 In summary, the reader's priority monitor, while not
permitting a new writer to start when there is a reader
waiting, permits any number of readers to proceed, as
long as there is at least one active reader.