Java Support for enhancement

The concept of enhancement

Enhancement (English: Moniters, also known as a monitor) is a program structure in which multiple sub-programs (objects or modules) within a structure form mutually exclusive access to shared resources.
These shared resources are typically hardware devices or a bunch of variables. The tube is implemented at a point in time, with a maximum of one thread executing a subroutine in the process.
Compared with concurrent programming, which implements mutually exclusive access by modifying the data structure, the process implementation greatly simplifies the program design.
The process provides a mechanism by which a thread can temporarily discard mutually exclusive accesses, wait for certain conditions to be met, and regain execution to restore its mutex access.

A tube contains:

1. Multiple threads that can interact with each other and share resources
2. Multiple variables related to resource usage
3. A mutual exclusion lock
4. A invariant used to avoid race conditions

A process program obtains a mutex before running a thread until the completion thread or thread waits for a condition to be satisfied before discarding the mutex.
If the invariant is guaranteed by each executing thread before the mutex is discarded, all threads will not cause the race condition to be established.
When a thread executes a subroutine in a pipe, it is called an occupation (occupy) of that pipe. The implementation of the enhancement ensures that at a point in time, only one thread occupies the pipe. This is the nature of the mutex access of the tube.
When a thread calls a subroutine that is defined in a pipe, it must wait until there is no other thread in the execution of a subroutine in the process.
In a simple implementation of a pipe, the compiler automatically joins a private mutex for each of the pipe objects. The initial state of the mutex is unlocked,
At the entrance of each common subroutine of the tube, the mutex is unlocked, and the mutex is unlocked at the exit of each common subroutine in the pipe.

Condition variable (Condition Variable)

The process provides a convenient way to implement mutual exclusion, but this is not enough. We also need a way for threads to be blocked when they cannot continue running.
In producer-consumer issues, it is easy to put tests for buffer fills and buffer nulls into the process, but how can producers block when they discover that the buffer is full?
The workaround is to introduce the conditional variable (condition variables) and the related two actions: wait and signal.
When a tube process discovers that it cannot continue to run (for example, the producer discovers a buffer full), it performs a wait operation on a condition variable, such as the "fully".
This action causes the calling process to block itself, and it also calls another process that was previously outside the pipe to the pipe.
Another thread, such as a consumer, can wake up a sleeping partner process, which can be done by performing a signal on a condition variable that its partner is waiting for.
To avoid two active processes in the pipe, if there are several processes waiting on a condition variable, after performing a signal operation on the condition variable,
The system scheduler can only select one of these to make it resume running.

The thread may need to wait for a condition p to be true before it can continue execution. In a busy wait (busy waiting) loop
While not (P) does skip
Will cause all other processes to fail to enter the critical section so that the condition P is true and the process has a deadlock.
The workaround is the condition variable (condition variables). Conceptually, a condition variable is a thread queue, where the thread is waiting for a condition to become true.
Each condition variable c is associated with an assertion p_c. When a thread waits for a condition variable, the thread does not count as taking up the pipe, so that other threads can enter the pipe execution,
Changes the state of the tube, notifies the condition variable C that its associated assertion P_c is true in the current state.

There are therefore two main operations for conditional variables:
Wait C is called by a thread to wait for the assertion P_c to be satisfied after the thread resumes execution. When a thread hangs on the condition variable and waits, it is not considered to occupy the pipe.
Signal C (sometimes writing notify C) is called by a thread to indicate that the assertion P_c is now true.
When a notification (signal) is issued to a conditional variable that is waiting in a thread, there are at least two threads that will occupy the pipe: the thread that is notifying and a thread that is waiting for the notification.
Only one thread can occupy the pipe, so a selection must be made. Two theoretical systems lead to the realization of two different conditional variables:
A blocking condition variable (Blocking condition variables) that gives priority to the notified thread.
A non-blocking condition variable (nonblocking condition variables) that gives priority to the thread that notifies.

Implicit conditional variable Pipe-range

In the Java programming language, each object can be used as a pipe thread. Methods that require mutual exclusion must explicitly indicate the keyword synchronized. Code blocks can also be labeled with the keyword synchronized.
without explicit conditional variables , this enhancement in Java waits for the queue outside of the ingress queue , using separate conditions. All waiting threads enter this queue,
All notify and notify all operations are also applied to this queue. This method has been used by other programming languages, such as C #.

The synchronization method in Java is fundamentally different from other classic tubes:Java does not have an inline conditional variable . Conversely,Java provides two process wait and notify, respectively, and sleep and wakeup equivalent ,
However, when they are used in synchronous methods, they are not constrained by race conditions. Theoretically, the method wait can be interrupted, which itself is the code associated with the interrupt. Java requires an explicit representation of exception handling.

Java Support for enhancement