User:Dangan249/sandbox

Monitor Construct
In parallel programming, to overcome thread collisions, monitor construct allows programmers to easily specify critical conditions that require mutual exclusion. The old use of semaphores and mutexes in protecting shared resources tends to leads to unmaintainable codes. In contrast, monitors are a more enhanced version of semaphores. They allow a thread to release its  mutual exclusive right while waiting for a specific conditional variable to signal other threads to enter the monitor.

History
Dijkstra first introduced the concept of monitors, but it was not until Sir C.A.R Hoare published his paper "Monitor: An Operating System Structuring Concept" in Communications of the ACM in 1974 that monitors have become a popular synchronization tool for parallel programming.

The initial approach of using mutex locks and semaphore to synchronize process or thread action and prevent memory conflict requires programmers to write complex and occasionally codes that are difficult to maintain. Furthermore, processes’ deadlock and starvation not only happen rarely but they are also scheduled randomly. Therefore, it is impossible to repeat the error case and debug codes. For example, without time constraints, a buggy program’s processes will never run into infinite waiting. This is why the monitor was invented to simplify the coordination between multiple threads.

A monitor construct remains as a high-level abstraction object that correctly synchronizes multiple threads when accessing shared resources. With its implicit mutual exclusion property, a monitor ensures that only one executing thread has access to shared variables and functions that change the variables’ states.

To coordinate more complex and conditional constraints over crucial methods, the monitor employs conditional variables that require a thread to signal a wait call if conditions are not true at the moment. For example, when two threads are simultaneously trying to delete the same element from a queue, we can utilize a conditional variable to signal whether or not a thread occupies the queue.

Shared Variables
Shared variables include any share resources that must be protected with mutual exclusion. Only one thread can alter the state of a variable at a time. Failing to control the changes in the states of these variables could cause fatal errors. For example, if two threads are trying to delete the last element of the list, even with the proper conditions to check for the empty list, the threads may by pass through the checking states and then begin switching. This will seriously crash the program.

Procedure
A monitor contains a finite number of operations that could change its shared variables. A single thread with exclusive access to the monitor requests these procedures sequentially.

Conditional Variables
These special types of variables exist as the backbone of any monitor. They restrict the call to the monitor’s procedure with complex coordinating rules specified by users. Compared to shared variables, multiple threads can perform a wait or receive a signal from a single conditional variable.

Wait, Signal, and Broadcast
Wait, signal, and broadcast are three conditional variable's operations that a thread can call upon when it is inside the monitor. After a wait call, a thread will be placed in the variable’s waiting queue. Several threads can volunteer to wait on the same queue until they receive a signal from the conditional variable. Moreover, broadcast function signals all the threads in the waiting queue at the same time so the most important one has access to the monitor.

Generic Pseudo-code of a Monitor
Hoare sketches the backbone code of his theory:

The example of an implementation of a monitor in C is shown in the Fig. 1 to the right. Although the standard C library does not explicitly support monitor, Hoare proves that they can be utilized to implement monitor construct with correct property.

Conclusion
Monitors with conditional variables significantly simplify parallel programming to allow for more complex synchronization. Hoare asserts the most important characteristic of a monitor to be “that only one program at a time actually succeeds in entering a monitor procedure, and any subsequent call must be held up until the previous call has been completed”.

Switching from old technologies to monitor enhances the reliability of applications. Moreover, programmers can implement the concept with both C and  Java. Despite the fact that it takes a large amount of resources to rewrite C applications, the new codes produce faster and more modular programs. With Java, the process is fast and easy since the language already provides the Synchronized class to build monitor. The outcome of this transformation separates concurrent codes from other parts of the programs to achieve more complex synchronization.