Monitor (computer science)

A monitor in computer science is a programming language concept for the synchronization of accesses temporally interleaved or parallel running processes or threads on commonly used data structures or resources. Inconsistent states of the data structures are avoided without programmers having to use synchronization primitives such as B. have to use semaphores explicitly. A mutual exclusion for access to the shared data structure is achieved by providing a compiler for the translation of a program part that has been marked by the programmer with elements of the programming language as a monitor, which inserts appropriate synchronization primitives. The concept is z. B. realized by the programming languages Ada , Modula , Concurrent Pascal or Java .

The monitor concept

When processes (or threads) run in parallel or at different times, situations arise in which data structures or resources that are shared by the processes can get into inconsistent states unless they are mutually excluded . Synchronization primitives such as semaphores are used to prevent multiple processes from changing the commonly used data structures at the same time or somehow interlinked in time. Provided they are used correctly by the programmer, these primitives guarantee that only one process can change the data structure within a period of time. However, since the correct application is made more difficult by the properties of the synchronization primitives, CAR Hoare in 1974 and Per Brinch Hansen in 1975 developed a synchronization device on a higher level of abstraction, the monitor.

A monitor is a module (an abstract data type , a class ) in which the data shared by processes and their access procedures (or methods) are combined into a single unit. Access procedures with critical sections of the data are specially marked as monitor operations. Access procedures without critical sections can also be offered by the module.

The monitor operations are carried out with mutual exclusion without the need to note synchronization instructions in the program code. A programmer can thus concentrate on the functionality of the module and ignore the synchronization problem. When used, a monitor automatically ensures that its monitor operations are only ever carried out by one process. If a process A calls a monitor operation while this or another monitor operation is already being carried out by a process B, then process A is blocked. Mutual exclusion, blocking and unblocking of a process are achieved by means of synchronization primitives that are inserted when the monitor is translated.

A monitor is often viewed as a space in which only one actor (process) can be accommodated. If other actors want to enter the monitor room, they have to wait until space has become free in the monitor room.

Condition synchronization

Cooperation situations (e.g. producer / consumer problem ) in which a process determines during the execution of a monitor operation that the data structure is in a state that does not make further execution appear sensible can be done with the monitor of the form described not be treated. Without further synchronization mechanisms, the process would have to end the monitor operation and exit the monitor. He then has to call the operation again later to check whether the status is the one expected this time. This amounts to an undesirable multiple checking and waiting.

Monitors therefore offer a way of synchronizing activities within the monitor. In the design of the monitor and its operations, conditions are defined which may or may not be true. Conditions by means of condition variables representing (condition variables). Two operations are defined on condition variables : wait () and signal () . When a process during execution of a monitoring operation on a condition variable b , the operation wait () calls, the process is blocked and inserted outside of the monitor in a queue for this condition variable. Since there is no longer any process active in the monitor, another process can enter the monitor from the outside and carry out a monitor operation. The blocked process is deblocked, if another process, the operation during the execution of a monitoring operation signal () on the condition variables b calls. If no process is waiting at the condition variable b when signal () is called, the call has no effect.

A monitor, which has the ability to synchronize conditions, consists of a closed unit of data and procedures. It often has an implicit lock variable and a queue (the monitor queue) and any number of condition variables. A further queue is assigned to each condition variable.

Structure of a monitor with condition synchronization

If a process from the queue for the condition variable is unblocked by means of a signal on a condition variable, it could continue the execution of the monitor operation at the point at which it issued the wait , if the signaling process was not still in the monitor. Two forms of treatment for this situation have been developed.

Hoare type

When the signal is called, a check is made as to whether the queue of the condition variable contains processes. If this is not empty, the signaling process is blocked and entered in the monitor queue. A process from the condition variable queue is unblocked. The signaling process is therefore i. d. Usually continued after the unblocked process has left the monitor. Hoare monitors are also called Signal and Wait .

Mesa type

In addition to the Hoare type, there is also the Mesa monitor type, which was developed by a group at Xerox in the late 1970s . In contrast to the Hoare type, signal does not block the signaling process. This is always continued. instead, signal moves a process from the condition variable queue to the monitor queue. Mesa-type monitors are also called signal-and-continue monitors (for example: signal and continue).

Monitors in Java

In Java every object basically has monitoring capabilities. Methods of a class that implement critical sections on attributes are to be identified as monitor operations using the synchronized keyword :

class Something {
   private SomeType sharedData;

   public synchronized void fct1 (...) {
      ...
   }
   public synchronized void fct2 (...) {
      ...
   }
}

Each object of the class then acts as a monitor for its attributes. Calls to synchronized methods from multiple threads on the same object are executed with mutual exclusion: at any given time, at most one thread accesses the object attributes as part of a synchronized method.

The Java language does not provide for any condition variables. The following methods are defined in the Object class for condition synchronization:

wait ()
blocks the calling thread and releases the monitor - the object whose synchronized method it is currently executing.
notify ()
unblocks (any) a thread blocked on this monitor; this can continue as soon as the monitor is free. (This behavior is not "fair" in the sense of fairness .)
notifyAll ()
unblocks all threads blocked on this monitor; they can continue to run as soon as the monitor is free.

Because of the missing condition variables, an unblocked thread has to check the condition it is waiting for again - it may not yet be valid or it may have been invalidated again by faster threads.