Monitor(karthika)

INTRODUCTION A primary aim of an operating system is to share a computer installation among many programs making unpredictable demands upon its resources. A primary tusk of its designer is therefore to construct resource allocation (or scheduling) algorithms for resources of various kinds (main store, drum store, magnetic tape handlers, consoles, etc.). In order to simplify his task, he should try to construct separate schedulers for each class of resource. Each scheduler will consist of a certain amount of local administrative data, together with some procedures and functions which are called byprograms wishing to acquire and release resources. Such a collection of associated data and procedures is known as a monitor; and a suitable notation can be based on the class notalion of

AIM: Monitors were developed in the 1970s to make it easier to avoid deadlocks. WHAT IS MONITOR …….?: >>A monitor is a collection of procedures, variables, and data structures grouped together. >>Processes can call the monitor procedures but cannot access the internal data structures. >>Only one process at a time may be be active in a monitor. >>Active in a monitor means in ready queue or CPU with the program counter somewhere in a monitor method. >>A monitor is a language construct. >>Compare this with semaphores, which are usually an OS construct.

SYNTAX: monitorname: monitor begin ... declarations of data local to the monitor; procedure procname ( formal parameters . . .); begin ... procedure body ... end; ... declarations of other procedures local to the monitor; ... initialization of local data of the monitor ... end; >>The compiler usually enforces mutual exclusion. >>Condition variables allow for blocking and unblocking.

In order to call a procedure of a monitor, it is necessary to give the name of the monitor as well as thename of the desired procedure, separating them by a dot: monitorname.procname(.. actual parameters ...); In an operating system it is sometimes desirable to declare several monitors with identical structureand behavior, for example to schedule two similar resources. In such cases, the declaration shown above. will be preceded by the word class, and the separate monitors will be declared lo belong to this 1. Introduction monitor 1, monitor 2: classname; Thus the structure of a class of monitors is identical to that described for a data representation in [13],except for addition of the basic word monitor. Brinch-Hansen uses the word shared for the same purpose

An example: Dining Philosophers 5 philosophers sit at a round table with 5 plates of rice and 5 chopsticks. 2 chopsticks are require to eat. Each philosopher is in one of the states: >>Thinking >>Hungry >>Eating

Dining Philosophers >>Look at code for almost solving this using monitor pseudocode. >>Note that this "solution" allows starvation.

Monitor Implementation >>Monitors are implemented by using queues to keep track of the processes attempting to become active int he monitor. >>To be active, a monitor must obtain a lock to allow it to execute the monitor code. >>Processes that are blocked are put in a queue of processes waiting for an unblocking event to occur. >>These are the queues that might be used:

The entry queue contains processes attempting to call a monitor procedure from outside the monitor.Each monitor has one entry queue. The signaller queue contains processes processes that have executed a notify operation.Each monitor has at most one signaller queue. In some implementations, a notify leaves the process active and no signaller queue is needed. The waiting queue contains processes that have been awakened by a notify operation.Each monitor has one waiting queue. Condition variable queues contain processes that have executed a condition variable wait operation.There is one such queue for each condition variable. The relative priorities of these queues determines the operation of the monitor implementation.

The queues associated with a monitor that does not have a signaller queue. The lock becomes available when the active process executes a wait or leaves the monitor.

One modern language that uses monitors is Java. Each object has its own monitor. Methods are put in the monitor using the synchronized keyword. Each monitor has one condition variable. The methods on the condition variables are: wait() , notify() , and notifyAll() . Since there is only one condition variable, the condition variable is not explicitly specified.

Goal of OS: is to share resources amongst many programs.Separate schedulers should be created for each class of resource.Each scheduler contains local data + procedures that programs may use to acquire and release resources. � Such a collection of data + procedures is a monitor. � Only one program may enter a procedure of a monitor at a given time. Hence, only one program may modify local data of the monitor at a given time. � If more than one program attempts to enter at the same time, only one will succeed, and the remaining programs will remain on a queue.

EXAMPLE As the simplest example of a monitor, we will design a scheduling algorithm for a single resource,which is dynamically acquired and releasecd by an unknown number of customer processes by calls on procedures procedure acquire; procedure release; A variable (1) busy: Boolean Determines whether or not the resource is in use. If an attempt is made to acquire the resource when it is busy, the attempting program must be delayed by waiting on a variable nonbusy:condition which is signalled by the next subsequent release. The initial value of busy is false. These design decisions lead to the following code for the monitor:

: single resource: monitor begin busy:Boolean; nonbusy:condition; procedure acquire; begin if busy then nonbusy.wait; busy := true end; procedure release; begin busy := false; nonbusy.signal end; busy := false; comment inital value; end single resource;

: NOTES In designing a monitor, it seems natural to design the procedure headings, the data, the conditions,and the procedure bodies, in that order. All subsequent examples will be designed in this way. 2. The acquire procedure does not have to retest that busy has gone false when it resumes after its wait, since the release procedure has guaranteed that this is so; and as mentioned before, no otherprogram can intervene between the signal and the continuation of exactly one waiting program. 3. If more than one program is waiting on a condition, we postulate that the signal operation will reactivate the longest waiting program. This gives a simple neutral queuing discipline which ensurcs that every waiting program will eventually get its turn. 4. The single resource monitor simulates a Boolcan semaphore [7] with acquire and release used forP and V respectively. This is a simple proof that the monitor/condition concepts are not in principle less powerful than semaphores, and that they can be used for all the same purposes.

Examples: The paper provides several other examples of using monitors and condition variables to solve common synchronization problems to prove their utility. � Some of these problems are buffer allocation, disk head scheduling, and multiple readers/writers to a file. Note of interest: � Every class in Java defines a monitor. � A synchronized method in a class becomes a monitor procedure . � Every object is allocated its own mutex, and that mutex is locked whenever a thread enters a synchronized method. � The class as a whole is also allocated its own mutex, and that mutex is locked whenever a static synchronized method is called. � Every Java object also has a condition variable associated with it.

� When wait() or signal() are called in a method, the wait or signal takes place on the condition variable associated with the object. � Wait() and signal() calls can only be made in synchronized methods. � The wait() method in the class Object is overloaded, and has a version that takes an integer, but this is different than the priority wait extension that Hoare suggests. � In addition, I do not believe that the Java scheduler guarantees that when signal is called a thread that had previously called wait immediately runs, but I could be wrong about this.

What problems do monitors solve? >> Mutual exclusion >>Encapsulation of data >>Compiler can automatically scan program text for some types of synchronization bugs >>Synchronization of shared data access simplified vs. semaphores and locks >>Good for problems that require course granularity >>Invariants are guaranteed after waits Theoretically, a process that waits on a condition doesn’t have to retest the condition when it is awakened.

What remains problematic? >>No way to check dynamically allocated shared data >>Signals are as error prone as with other synchronization mechanisms >>Deadlock can still happen in monitor code >>Programmer can still screw up >>Monitors are available in very few languages

Volatile memory : Volatile memory also known as volatile storage , is computer memory that requires power to maintain the stored information, unlike non-volatile memory which does not require a maintained power supply. It has been less popularly known as temporary memory . Non-volatile memory nonvolatile memory , NVM or non-volatile storage , in the most basic sense, is computer memory that can retain the stored information even when not powered. Examples of non-volatile memory include read-only memory , flash memory , most types of magnetic computer storage devices (e.g. hard disks , floppy disks , and magnetic tape ), optical discs , and early computer storage methods such as paper tape and punched cards . Non-volatile memory is typically used for the task of secondary storage , or long-term persistent storage. The most widely used form of primary storage today is a volatile form of random access memory (RAM), meaning that when the computer is shut down, anything contained in RAM is lost. Unfortunately, most forms of non-volatile memory have limitations that make them unsuitable for use as primary storage. Typically, non-volatile memory either costs more or performs worse than volatile random access memory.

Stable storage : is a classification of computer data storage technology that guarantees atomicity [ disambiguation needed ] for any given write operation and allows software to be written that is robust against some hardware and power failures. To be considered atomic, upon reading back a just written-to portion of the disk, the storage subsystem must return either the write data or the data that was on that portion of the disk before the write operation. Most computer disk drives are not considered stable storage because they do not guarantee atomic write: an error could be returned upon subsequent read of the disk where it was just written to in lieu of either the new or prior data.

Conclusions Monitors are a synchronization mechanism A higher level, easier to use abstraction, better encapsulation than semaphores, etc. Monitors still suffer from various problems Let’s take a look at working model that addresses some of those issues! (Suzanne’s presentation)

Monitor(karthika)

More Related Content

What's hot (20)

Viewers also liked (6)

Similar to Monitor(karthika) (20)

More from Nagarajan (17)

Recently uploaded (20)

Monitor(karthika)