Operating System - Monitors (Presentation)

1. REPORT ON MONITORS
 MUHAMMAD RAZA @2079
MUHAMMAD AMMAR @2055
QAMAR SHEERAZ @2076
AHMAD KHAN @2056
ZULQARNAIN ANSARI @2085
ADNAN KHAN @1941

2. MONITORS

3. MONITORS
INTERPROCESS COMMUNICATION (IPC) :
Processes frequently need to communicate
with other processes. In short, there is a
need for communication between processes,
preferably in a well-structured way not using
interrupts.

4. MONITORS
RACE CONDITIONS:
When two or more processes are reading
or writing some data and the final result
depends on who runs precisely when, are
called race conditions.

5. MONITORS
CRITICAL SECTION:
The part of the program where the shared
memory is accessed is called the critical
section.
If we could arrange matters such that no
two processes were ever in their critical
section at the same time, we could avoid
race conditions.

6. MONITORS
MUTUAL EXCLUSION:
When two or more processes want to
access the shared memory, shared
files, and shared everything else, is to
find some way to prohibit more than
one process from reading and writing
the shared data at the same time.

7. MONITORS
SEMAPHORES:
Semaphores are flag variables. It is an
integer type variables to count the number
of wakeups saved for future use.

8. MONITORS
SEMAPHORES:
Example:
#define N 100
Typedef int semaphore;
Semaphore mutex=1;
Semaphore empty=N;
Semaphore full=O;

9. MONITORS
SEMAPHORES:
producer()
{
int item;
While (true){
produce_item(&item); //Generate something in buffer
Down(empty); //decrement empty count
Down(mutex); //enter critical region
Enter_item(item); //put new item in buffer
up(mutex); //leave critical region
up(full); //increment count of full slots
}
}

10. MONITORS
SEMAPHORES:
consumer()
{
int item;
While (true){
Down(full); //decrement full count
Down(mutex); //enter critical region
remove item(&item); //take item from buffer
up(mutex); //leave critical region
up(empty); //increment count of empty slots
consume_item(item); //Do something with item
}
}
(THE PRODUCER CONSUMER PROBLEM USING SEMEPHORES)

11. MONITORS
MONITORS
Monitor is a collection of procedures,
variables,data structures that are all grouped
together in a special kind of module or
package.
Or
A high-level data abstraction tool that
automatically generates atomic operations on
a given data structure.

12. MONITORS
A monitor has:
 Shared data.
 A set of atomic operations on that data.
 A set of condition variables

13. MONITORS
Monitor example
Integer I;
Conditiion c
Procedure producer(x);
.
.
.
End;
Procedure consumer(x);
.
.
.
End;
End monitor

14. MONITORSMONITORS
Muhammad AmmarMuhammad Ammar #2055#2055
Explanation of MonitorsExplanation of Monitors

15. MONITORS
Explanation
Monitors are a programming language
construct, so the compiler knows they
are special and can handle calls to
monitor procedures differently from other
procedure calls.

16. MONITORS
Explanation
when a process calls a monitor
procedure then procedure will
check that either any process is
currently active or not.

17. MONITORS
Explanation
- If any process is currently active then
the monitor procedure will be suspended
until the process has left monitor.
- If no other process is using the monitor
then the monitor procedure will enter the
calling process.

18. MONITORS
Explanation
- The person who writing the monitor
procedure does not know, how the
compiler arranges for mutual exclusion.
- But monitor procedure provide an easy
way to overcome mutual exclusion.

19. MONITORS
Explanation
- It is not enough to achieve mutual exclusion
only. We also need a way for processes to
block when they cannot proceed .

20. MONITORS
Explanation
The solution for this is that when a
monitor procedure discovers that it
cannot continue ,it does a wait on some
condition.This action causes the calling
process to block.
- It also allows another process that
had been previously prohibited from
entering the monitor to enter now.

21. MONITORSMONITORS
Qamar SheerazQamar Sheeraz #2076#2076
Explanation of Monitors 2Explanation of Monitors 2

22. MONITORS
The producer consumer
problems with monitors:
The operations WAIT and
SIGNAL look similar to SLEEP
and WAKEUP, which saw earlier
had fatal race conditions.
SLEEP and WAKEUP failed
because while one process was
trying to go to SLEEP, the other

23. MONITORS
one was trying to make it up.
With Monitors, that cannot happen.
The automatic mutual exclusion
on monitor procedures guaranties
that if, say, the producer inside a
Monitor Procedure discovers that
the buffer is full, it will be able to

24. MONITORS
complete the WAIT OPERATION without
having to worry about the possibility that
the scheduler may switch to the consumer
just before the WAIT completes. The
consumer will not even be let into the
Monitor at all until the WAIT is finished
and Producer has been marked as no
longer run able

25. MONITORS
- Monitors make parallel programming
much less error-prone than with
Semaphores.
- Still they too have some drawbacks.
- Monitors are a programming language
concept.
- Some languages supports Monitors but C,
Pascal and most other languages do not
have Monitors.

26. MONITORS
- The languages which do not have
monitors, so it is unreasonable to expect
their compilers to enforce any mutual
exclusion rules.
- In fact, how could the compiler even know
which procedures were in monitors and
which were not?

27. MONITORSMONITORS
Ahmad KhanAhmad Khan #2056#2056
PRODUCER-CONSUMER PROBLEMPRODUCER-CONSUMER PROBLEM
WITH MONITORSWITH MONITORS

28. MONITORS
Monitor ProducerConsumer
condition full, empty;
integer count;
Procedure enter;
Begin
if count = N then wait(full);
Enter_item;
Count := count + 1;
If count = 1 then signal(empty);
End;

29. MONITORS
Procedure remove;
Begin
If count = 0 then wait(empty);
remove_item;
Count = count - 1;
If count = N - 1 then signal(full);
end
Count := 0;
End monitor;

30. MONITORS
Procedure producer;
Begin
While true do
Begin
produce_item;
ProducerConsumer.enter;
End
End;

31. MONITORS
Procedure consumer;
Begin
While true do
Begin
ProducerConsumer.remove;
Consume_item;
End
End;
( The producer-consumer problem with monitors. The
buffer has N slots. )

32. MONITORSMONITORS
Zulqarnain AnsariZulqarnain Ansari #2085#2085
USING SEMAPHORES IMPLEMENTINGUSING SEMAPHORES IMPLEMENTING
MONITORSMONITORS

33. MONITORS
Using Semaphores to Implement
Monitors:
- If the Operating System provides Semaphores
as a basic feature, any Compiler ( which
supports Monitor ) writer can easily implement
Monitors in his Language.
- Associated with each Monitor is a binary
Semaphore.

34. MONITORS
Using Semaphores to Implement
Monitors :
- Mutex, initially 1, to control entry to the
Monitor, and an additional Semaphore ,
initially 0, per condition variable.
- If Monitor is currently in use, the Process
will block.

35. MONITORS
Using Semaphores to Implement Monitors:
- On leaving the process does an UP mutex to
permit a waiting process to enter.
- e.g, Consider the Producer-Consumer problem
again. The mutex semaphore guarantees that
each process has exclusive access to the
monitor for its critical section.

36. MONITORS
Using Semaphores to Implement Monitors:
- Suppose the consumer start 1st
and discovers
that there is no work for it in the buffer .It does a
WAIT EMPTY ,which causes an up on mutex
and DOWN on empty. The consumer goes to
sleep, and the producer is allowed to enter as
soon as it wants to.

37. MONITORS
Using Semaphores to Implement
Monitors:
- When the producer discovers that count is
1, it will do signal empty to wake up the
Consumer.
- At this point both Producer and Consumer
are active in the Monitor.
- But since one of our rules of programming

38. MONITORS
Using Semaphores to Implement
Monitors:
with monitors is that after doing SIGNAL a
process must leave the MONITOR
immediately, no harm is done.

39. MONITORSMONITORS
Adnan KhanAdnan Khan #1941#1941
USING MONITORS TO IMPLEMENTUSING MONITORS TO IMPLEMENT
SEMAPHORESSEMAPHORES ANDAND MESSAGESMESSAGES

40. MONITORS
-Semaphores are Flag variables .
-Boolean type (True or False).
-MESSAGES
Problem with monitors, and also with semaphores, is
that they were designed for solving the mutual exclusion
problem on one or more CPUs that all have access to
common memory.
But when we talk about the Distributed system
consisting of multiple CPUs,each with its own private
memory ,connected by a LAN.

41. MONITORS
-CONCLUSION
Semaphores are too low level and monitors are not
usable except few programming languages .
Furthermore none of the primitives provide for
information exchange between machines.
-So some thing there was to be needed and that was
-MESSAGE PASSING.
This method of interprocess communication uses
two primitives SEND and RECEIVE,which are like
semaphores and unlike monitors.And are system calls.

42. MONITORS
Using Monitors to Implement Semaphores and Messages:
Implementing semaphores and messages using monitors follows
roughly the same pattern.
But ,in simpler,because Monitors r a higher level construct than
Semaphores.
IMPLEMENTATION OF SEMAPHORES
To implement Semaphores,we need a counter and Link List for
each semaphore to be implemented, as well as a condition variable
per process.
-When a DOWN is done,the caller checks (inside the monitor)to see
if the counter for that semaphores is greater than zero,And if it is ,th
e counter is decremented and the caller exits the Monitor.

43. MONITORS
IMPLEMENTATION OF SEMAPHORES
-If counter is zero,the caller adds its own process no to link list
and does a WAIT on its condition variable.
When
UP is done on a Semaphore,
-The caller incrrements the counter (inside the monitor)and
then checks to see if the link list is having any entries.
If the list has entries,the caller removes one of them and
generates SIGNAL on the conditon variable for that process.
In a more sophisticated implementation,each process puts
its priority on the list along with its process no ,so that the highest
priority process would be awakened 1st
.

44. MONITORS
IMPLEMENTATION OF MESSAGES:
-Implementing messages using Monitors is
essentially the same as with semaphores,except
that instead of Semaphore per process we have
a conditon variable per process.
-The mailbox structures are the same for
both implementations.