Monitors

Semaphores can be very useful for solving concurrency problems, but only if programmers use them properly. If even one process fails to abide by the proper use of semaphores, either accidentally or deliberately, then the whole system breaks down. For this reason a higher-level language construct has been developed, called monitors.

Monitor Usage

• A monitor is essentially a class, in which all data is private, and with the special restriction that only one method within any given monitor object may be active at the same time. An additional restriction is that monitor methods may only access the shared data within the monitor and any data passed to them as parameters. i.e. they cannot access any data external to the monitor.

In order to fully realize the potential of monitors, one additional new data type, known as a condition can be defined.

• A variable of type condition has only two legal operations, wait and signal. i.e. if X was defined as type condition, then legal operations would be X.wait( ) and X.signal( )
• The wait operation blocks a process until some other process calls signal, and adds the blocked process onto a list associated with that condition.
• The signal process does nothing if there are no processes waiting on that condition. Otherwise it wakes up exactly one process from the condition's list of waiting processes.

·           But now there is a potential problem - If process P within the monitor issues a signal that would wake up process Q also within the monitor, then there would be two processes running simultaneously within the monitor, violating the exclusion requirement.

·           Accordingly there are two possible solutions to this dilemma:

Signal and wait - When process P issues the signal to wake up process Q, P then waits, either for Q to leave the monitor or on some other condition.

Signal and continue - When P issues the signal, Q waits, either for P to exit the monitor or for some other condition.