Monitors in Operating System | OS Tutorials

In operating system Monitors are programming language constructs that supports both data access synchronization and control synchronization. A monitor type resembles a class in a language like C++ or Java.

Monitors in Operating System

Monitors has four aspects summarized as desribed below in table:

• A concurrent program creates monitor objects i.e. objects of a monitor type and uses them to perform operations on shared data and implement process synchronization using synchronization operations.
• 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 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.
• The compiler usually enforces mutual exclusion.
• Condition variables allow for blocking and unblocking.
  • cv.wait() blocks a process. The process is said to be waiting for (or waiting on) the condition variable cv.
  • cv.signal() (also called cv.notify) unblocks a process waiting for the condition variable cv. When this occurs, we need to still require that only one process is active in the monitor. This can be done in several ways:
    • on some systems the old process (the one executing the signal) leaves the monitor and the new one enters.
    • on some systems the signal must be the last statement executed inside the monitor.
    • on some systems the old process will block until the monitor is available again.
    • on some systems the new process (the one unblocked by the signal) will remain blocked until the monitor is available again.
• If a condition variable is signaled with nobody waiting, the signal is lost. Compare this with semaphores, in which a signal will allow a process that executes a wait in the future to no block.
• It has two methods, wait and signal that manipulate the calling process.

Monitor definitions

A Monitor is a collection of procedures, variables and data structures that are all grouped together in a special kind of module or package. Processes may call the procedures in a monitor whenever they want to, but they cannot directly access the monitor’s internal data structures from procedures declared outside the monitor.

Declaring Monitor: A Monitor can be declared as follows:

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;

In order to call a procedure of a monitor, it is necessary to give the name of the monitor as well as the name of the desired procedure, separating them by a dot:

monitorname.procname(.. actual parameters ...);

• Monitor have a important property that makes them useful for achieving mutual exclusion; only one process can be active in a monitor at an instant.
• When a process calls a monitor procedure, the first few instructions of the procedure will check to see if any other process is currently active within the monitor.
• If it is so, the calling process will be suspended until the other process has left the monitor. If no other process is using the monitor, the calling process may enter.

Problem with Monitors

• One main 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 a common memory.
• By putting the semaphores in the shared memory and protecting them with TSL or XCHG instructions, we can avoid races.
• When we go to a distributed system consisting of multiple CPUs each with its own private memory, connected by a local area network, these primitives become inapplicable.
• Hence, we observe that semaphores are too low level and monitors are not usable except in few languages. None of the primitive allow information exchange between machines. So something else is needed.

Monitor Implementation

• Monitors are implemented by using queues to keep track of the processes attempting to become active in the 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 thit have executed a condition variable wait operation. There is one such queue for each condition variable.
• The relative priorities of these queues determine the operation of the monitor implementation.

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

What is basic Difference Between Semaphore & Monitor in Operating System?

• The wait and signal operations on condition variables in a monitor are similar to P and V operations on counting semaphores.
• A wait statement can block a process’s execution, while a signal statement can cause another process to be unblocked. However, there are some differences between them.
• When a process executes a P operation, it does not necessarily block that process because the counting semaphore may be greater than zero.
• In contrast, when a wait statement is executed, it always blocks the process.
• When a task executes a V operation on a semaphore, it either unblocks a task waiting on that semaphore or increments the semaphore counter if there is no task to unlock.
• On the other hand, if a process executes a signal statement when there is no other process to unblock, there is no effect on the condition variable.
• Another difference between semaphores and monitors is that users awaken by a V operation, can resume execution without delay.
• Contrarily, users awaken by a signal operation are restarted only when the monitor is unlocked.
• In addition, a monitor solution is more structured than the one with semaphores because the data and procedures are encapsulated in a single module and that the mutual exclusion is provided automatically by the implementation.