Monitor (synchronization)

A monitor in the computer science is a programming -language concept for synchronization of accesses temporally interleaved or parallel running processes or threads on shared data structures or resources. Inconsistent states of the data structures are avoided, as must explicitly use eg semaphore without programmer synchronization primitives. A mutual exclusion for accesses to the shared data structure is achieved by a compiler during the translation of a program part, which was marked by the programmer with elements of the programming language as a monitor, appropriate synchronization primitives inserts. The concept is realized, for example, of the programming languages Ada, Modula, Concurrent Pascal or Java.

The monitor concept

For parallel or time- toothed flow of processes (or threads) are situations in which data structures or resources that are shared among processes, can get into inconsistent states, if not a mutual exclusion is made. Synchronization primitives such as semaphores are used to exclude the possibility that multiple processes simultaneously or interleaved in time somehow change the shared data structures. Correct use by programmers assumed these primitives guarantee that only one process accesses altering within a period to the data structure. Since the correct application but is complicated by characteristics of the synchronization primitives, developed in 1974 CAR Hoare and Per Brinch Hansen 1975 located somewhere on a higher abstraction level synchronization means the monitor.

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

The monitor operations are executed under mutual exclusion without synchronization in the program code instructions must be written down. A programmer can therefore focus on the functionality of the module and can be ignored, the synchronization problem. When using a monitor automatically self that his monitor operations are run by only one process. If a process A call a monitor operation, during this or any other monitor operation is already running a process B, then process A is blocked. Mutual exclusion, blocking and unblocking a process are obtained by means of synchronization primitives, which are inserted in translation of the monitor.

A monitor is often seen as a space where there is room in which only one actor (process). Want more actors in the monitor room, so they have to wait until space has become vacant in the monitor room.

Condition synchronization

Cooperation situations ( see, eg, producer / consumer problem ) in which a process during execution of a monitor operation detects that the data structure is in a state that does not makes this worthwhile a further embodiment, can use the monitor as described or are not treated. Without further synchronization mechanisms would the process stop the monitor operation and exit the monitor. He must then later call the operation to check whether the state is the expected time. This amounts to an unwanted multiple inspection and maintenance.

Monitors therefore provide a way of synchronizing activities within the monitor. In the design of the monitor and its operations conditions are defined, which are fulfilled or not. Conditions are represented by means of condition variables. On condition variables are defined two operations: wait () and signal (). When a process during execution of a monitor operation on a condition variable b invokes the operation wait ( ), the process is blocked and inserted outside the monitor in a queue for this condition variable. Since no process in the monitor is active, another process to enter and run a monitor operation the monitor from the outside. The blocked process is deblocked if another process calls the operation signal () to the condition during the execution of a variable b monitor operation. If at the time of the call to signal () no process on the condition variable b is waiting, the call has no effect.

A monitor that has the ability to condition the synchronization, consists of a closed unit of data and procedures. Often it has an implicit lock variable, and a queue ( the queue monitor ) as well as any number of condition variables. Each condition variable is assigned to another queue.

Construction of monitors with condition synchronization

If by signal on a condition variable, a process from the queue unblocked for condition variables, so this could be the design of the monitor operation to the point where he wait that dispatched, continue, if not the signaling process would still be in the monitor. Two forms of treatment of this situation have been developed.

Hoare type

When signal- call checks whether the queue condition variable contains processes. If it is not empty, the signaling process is blocked and entered in the monitor queue. A process from the queue condition variable is unblocked. The signaling process is thus continued typically after the deblocked process has left the monitor. Hoare monitors are also called signal and Wait.

Mesa - type

In addition to the Hoare - type, there is the Mesa - monitor type, developed in the late 1970s by a group at Xerox. In contrast to the Hoare - type signal does not block the signaling process. This will always continue. signal lined up instead a process of the queue of the condition variable in the monitor queue. Mesa type monitors are also signal - and-continue Monitors ( about: signal and proceed ) called.

Monitors in Java

In Java, every object has in principle on monitor capabilities. Methods of a class that implement critical sections on attributes are synchronized by means of the keyword to be designated as monitor operations:

Class Something { private SomeType shared data; synchronized public void FCT1 ( ... ) { ... } synchronized public void fct2 ( ... ) { ... } } Each object of the class will then act as a monitor for its attributes. Views of synchronized methods on the same object from multiple threads are executed under mutual exclusion: at any time uses more than one thread within a synchronized method on the object attributes.

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

Wait () block the calling thread and returns the monitor - the object whose synchronized method he is performing - free.
Notify () deblocked ( any ) a blocked thread on this monitor; this can continue to run if 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 if the monitor is free.

Because of the lack of condition variables must be a deblocked thread the condition for which he waits to check again - they could not yet be valid or already have been invalidated by faster threads again.