java-Preliminary Understanding-14th-inter-thread communication-wait-wake mechanism

I. INTRODUCTION

In the output just now, it is the same continuous output. Now we want the output to be output once per input.

Before you enter, make sure that there is data in the resource. If we have data, we need to define more variables in the resource to mark if there is any data in it.

In other words, the data inside the resource is output.

There is no data in the default resource. Enter the execution right, the first to determine whether there is data in the resources, if not, enter the data inside. Once the data has been entered, the flag variable is tagged with the data already in the resource. Since the input thread also holds the input, it enters the data inside, but the flag variable is checked before the input, and it doesn't make sense to have the input thread run again. At this point, we need the input thread to stop. We are not sure how long it will take to stop, but one thing is certain that the output thread can wake up when it takes the data out.

After the input thread has identified the data, it loses execution and execution (the CPU no longer executes it) and freezes. Frozen state we learned two ways before, one is sleep, the other is wait,

There is nothing in the resources, we can not output, nothing flag is false. For false, I do not need output, I will wait, flag for false,! Flag=true, enter the IF statement to execute Wait ().

After the right-end output waits, it wakes up the input thread on the left side. After the flag is set to False, the input thread wakes up before the next wait (possibly the output thread). Similarly, when the input thread enters data, Flase is set to true, and the output thread is awakened, so that it takes the data and wakes each other up.

Said so much, is to complete the input once, output once the demand.

What we are going to talk about is the very important mechanism that is used in multithreading communication-waiting for the wake-up mechanism.

Two. Wait for wake-up mechanism

Nitify or Notifyall is for the thread to be eligible for execution and is now ready to add these actions to the original program,

Before entering data, be sure to wait for it if it is true. If it is not true, the input data is entered, and when it is finished, flag is changed to true, and the output thread is woken up. When we notify, will the other party execute it? Not necessarily, there may not be a waiting state. The other side does not wait, we wake up is meaningless, but our empty wake can exist. If at this time to have the right to execute, before the input to judge, this is true, and then wait.

The output is the same.

If all the threads wait, then there is no operation, need Notifyall,

A program of a class inside, we can write a lot of synchronization, such as have a synchronization, B synchronization, c synchronization, there are three locks, a lock, B lock, C lock. You are waiting in the a lock, I take the B-lock notify useful? Useless. So, wait,notify is used to manipulate threads, and to be blunt is to monitor thread state, and once the state has changed, they must explicitly change the locked thread. Because the characteristics of the lock is not in the synchronization of multiple threads, in other words, these four threads belong to the brother of this lock, is to me to run, is to me to run, I this lock in the face of the thread to operate, the other lock method can I do? This is not going to work. So, when you use the method, you have to be clear about your own locks. In the end you are wait which locked thread, if you are wait is a locked thread, you can only use a lock notify to wake up a locked thread.

The reason is clear, where is the concrete manifestation? Now look at the program, wait and notify in the same block of code, you should identify the lock they belong to, for R This lock calls the wait method, the thread comes in, the R lock's thread is changed state by the R lock Wait method, then you can only use the R lock notify to wake up.

This is the need to be clear about different locks.

The same is true for another thread, where flag is an attribute in the R object and does not have anything to do with locks.

Now let's go to the API and see if the wait method has something like that.

The thread class in the Java.lang package, in the method introduction of the thread class, did not find the wait method.

The wait method is not a method in the thread class, and wait is used to manipulate the threads in the synchronization, it is not actually the threading method, very strange. It can actually be used to show that it holds this method. It does not, find his father,

Why is the wait method defined in the object class? Not defined in the thread class?

Point to the object class, but there is a wait method,

In fact, the wait method calls the Wait (0) method,

The so-called monitor, is this lock R. The thread on the specified monitor is being manipulated because of wait. Thread into R, r to monitor the thread. Because R is an area that belongs to, this thread is running on the lock of R, this wait is the method that is loaded on the monitor of Operation R, we also call it the Monitor method.

What does a monitor do? for monitoring threads. Where is the thread being monitored? R puts a single thread into a synchronous block of code while controlling other threads from entering the synchronized code block, which is a bit of a monitoring implication.

The wait set in is called the thread pool. Which thread pool does it put in? If there are two thread pools in the program, enter the R thread pool. ( I think it's possible to get into their own, how to determine ?) )

For example, look at the following, if there are two simultaneous code blocks at the same time, the respective locks are in a and r,a in the thread wait,r, but a wait thread in a should stay in the pool where A is located. Here, one is a thread pool, the other is the thread pool of r, otherwise how to differentiate.

How to differentiate the thread pool, according to the lock.

These methods are the way to operate the lock thread.

Now that the wait,notify wake-up mechanism has been added, can the interval input and output be achieved?

After reviewing the wait method, it is found that using it will cause an exception to be processed. For exceptions, you can declare that you can capture, but only here, because the Run method is not declared.

This anomaly also occurs in the Sleep method, with both sleep and wait having a common feature. They all allow the thread to freeze, and a method like this can throw a thread exception, and it will be discussed later.

After modifying the program, the result is no problem.

Essence: Constantly in the sign of the switch, in doing the mutual waiting and awakening action.

java-Preliminary Understanding-14th-inter-thread communication-wait-wake mechanism