Date post: | 21-Mar-2017 |
Category: |
Devices & Hardware |
Upload: | zulqarnain-ansari |
View: | 90 times |
Download: | 0 times |
REPORT ON MONITORS
MUHAMMAD RAZA @2079 MUHAMMAD AMMAR @2055QAMAR SHEERAZ @2076AHMAD KHAN @2056ZULQARNAIN ANSARI @2085ADNAN KHAN @1941
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.
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.
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.
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.
MONITORS
SEMAPHORES:
Semaphores are flag variables. It is an integer type variables to count the number of wakeups saved for future use.
MONITORS
SEMAPHORES:
Example:#define N 100Typedef int semaphore;Semaphore mutex=1;Semaphore empty=N;Semaphore full=O;
MONITORS
SEMAPHORES:
producer(){
int item;While (true){
produce_item(&item); //Generate something in bufferDown(empty); //decrement empty countDown(mutex); //enter critical regionEnter_item(item); //put new item in bufferup(mutex); //leave critical regionup(full); //increment count of full slots
}}
MONITORS
SEMAPHORES:
consumer(){
int item;While (true){
Down(full); //decrement full countDown(mutex); //enter critical regionremove item(&item); //take item from bufferup(mutex); //leave critical regionup(empty); //increment count of empty slotsconsume_item(item); //Do something with item
}}(THE PRODUCER CONSUMER PROBLEM USING SEMEPHORES)
MONITORSMONITORS
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.
MONITORS
A monitor has:
Shared data. A set of atomic operations on that data. A set of condition variables
MONITORS
Monitor exampleInteger I;Conditiion c
Procedure producer(x);...End;Procedure consumer(x);...End;
End monitor
MONITORSMONITORS
Muhammad Ammar Muhammad Ammar #2055#2055
Explanation of MonitorsExplanation of Monitors
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.
MONITORS
Explanation
when a process calls a monitor procedure then procedure will check that either any process is currently active or not.
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.
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.
MONITORS
Explanation
- It is not enough to achieve mutual exclusion only. We also need a way for processes to block when they cannot proceed .
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.
MONITORSMONITORS
Qamar SheerazQamar Sheeraz #2076#2076
Explanation of Monitors 2Explanation of Monitors 2
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
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
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
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.
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?
MONITORSMONITORS
Ahmad KhanAhmad Khan #2056#2056
PRODUCER-CONSUMER PROBLEM PRODUCER-CONSUMER PROBLEM WITH MONITORSWITH MONITORS
MONITORS
Monitor ProducerConsumercondition 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;
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;
MONITORS
Procedure consumer;Begin
While true doBegin
ProducerConsumer.remove;Consume_item;
EndEnd;( The producer-consumer problem with monitors. The
buffer has N slots. )
MONITORSMONITORS
Zulqarnain Ansari Zulqarnain Ansari #2085#2085
USING SEMAPHORES IMPLEMENTING USING SEMAPHORES IMPLEMENTING MONITORSMONITORS
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.
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.
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.
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.
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
MONITORS
Using Semaphores to Implement Monitors:with monitors is that after doing SIGNAL a process must leave the MONITOR immediately, no harm is done.
MONITORSMONITORS
Adnan Khan Adnan Khan #1941#1941
USING MONITORS TO IMPLEMENT USING MONITORS TO IMPLEMENT SEMAPHORESSEMAPHORES AND AND MESSAGESMESSAGES
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.
MONITORS
-CONCLUSIONSemaphores 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.
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 SEMAPHORESTo 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.
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.