Who will the join thread wake up?

Who will the join thread wake up?

I was asked this question on csdn and gave a detailed answer. However, the level of the questioner is different, and the ability to judge the correct answer is also different. He is not satisfied with my answer.
The reason why I wrote another article specifically for this is whether the topic should be clarified from this question.

1. What does join do?
Open the JDK source code and you can see that join is actually waiting for the end of the target thread:
Public final synchronized void join (long millis) throws interruptedexception {
Long Base = system. currenttimemillis ();
Long Now = 0;

If (millis <0 ){
Throw new illegalargumentexception ("timeout value is negative ");
}

If (millis = 0 ){
While (isalive ()){
Wait (0 );
}
} Else {
While (isalive ()){
Long Delay = millis-now;
If (delay <= 0 ){
Break;
}
Wait (Delay );
Now = system. currenttimemillis ()-base;
}
}
}

The other two parameters only initialize the parameters and merge them to call this method. If the join time is specified, it is specified in the wait of the target thread.
If no time is specified, wait will remain in the thread's lifetime.

In addition to the wait (time), the thread can be scheduled to wake up (Some people say this is called waking up), otherwise the current thread has been
While (isalive ()){
Wait (0 );
}
This code is implemented in the target thread for the current thread to call the target thread. Join (), so isalive () is of course the target thread.
That is, the current thread a calls thread B. Join (); then isalive () is thread B. This. isalive () is used in thread B. If it is used in thread
B. isalive (). Similarly, wait is the current thread waiting on the target thread object. So what is the current thread waiting?

Of course, it is waiting to be awakened by notify (all. Yes, but this is just a superficial phenomenon. What I want to talk about is the waiting condition.
The waiting condition determines who is calling the join thread (the current thread that I have been talking about above is actually not the current thread after the call)
Here, because the waiting condition is B. isalive (); When thread B is not alive, it will surely wake up thread a that calls the join method on it.

We can see the implementation of thread Exit:
Static void ensure_join (javathread * thread ){
Handle threadobj (thread, thread-> threadobj ());
Assert (threadobj. not_null (), "Java thread object must exist ");
Objectlocker lock (threadobj, thread );
Thread-> clear_pending_exception ();
Java_lang_thread: set_stillborn (threadobj ());
Java_lang_thread: set_thread_status (threadobj (), java_lang_thread: terminated );
Java_lang_thread: set_thread (threadobj (), null );
Lock. policy_all (thread );
Thread-> clear_pending_exception ();
}

This local method is called when the thread exits. In addition to finishing work, it will surely wake up all the threads of wait on this thread object. Because it is a local method,
In jdk src, we cannot see the thread that calls the join to wake up the thread that calls the join. However

In addition to wait expiration, the wait method is always waiting for the anti-condition of wait.

At the same time, the wake-up responsibility is also handed over to the thread that changes that condition, so if you want to see who is awakened by the thread in a wait, it depends on who is controlling this condition, if the thread that controls this condition never wakes up the thread that calls wait, it is a fatal design error.

Here, we know that join is actually wait, and a calls B. Wait (). Assume that:
While (B. isalive ()){
Wait (); // It is actually this. Wait (); A. Wait ();
}
Okay? Yes, but B needs to know who is waiting for the condition "B is not alive" when exiting, and then notifies this thread to wake up, because B wait () on its own instance (), therefore, B must call. y/All () can be awakened. If a is marked as waiting for this condition at the beginning, B cannot know that A is waiting for this condition, so a is wait on B's object, but if we control programming by ourselves, there is a global variable or data result to save the thread handle waiting for this condition, you can wake up in the thread that controls this condition, or a can wait on an unrelated third-party object, then, when the thread controlling this condition reaches the non-Wait condition, it calls y/all on this third-party object.

SoThe thread responsible for truly awakening the threads in join/Wait is the thread that can make the waiting condition invalid. The thread in wait actually waits for the anti-Wait condition.
Suppose there is a list object alist
While (alist. Size () <= 0 ){
Wait ();
}
Alist. removefisrt ();

We know the current line and the first element to get the list, but if there is no element in the list, we need wait. Who will wake it up? Of course, the element is added to the list.
Thread, so if there is a thread

Alist. Add (o); Be sure to call y/All (); otherwise it is a design error. As for who calls the Y/All (), it depends on the object on which the waiting thread is waiting.

Explain again the role of while (condition:

This is a multi-threaded version of the safe if (condition ).

In a multi-threaded environment, if only if () is used ():

If (alist. Size () <= 0) alist. Wait (); // if it is on the list object, wait is also a very good choice, because both add and remove operations
// The Common Object is list, which becomes a known object.
Alist. removefisrt ();
Thread a and thread B are all executed here. All are waiting for the alist. Size ()> 0 condition. Now thread C adds an element to it:
Alist. Add (O );
Alist. policyall ();

OK, threads A and B are all awakened. A correctly removes an object from alist after executing the wait () code. Switch to B and run B from the wait code.
Run, and the result alist has no elements. B said, Kao. If it is done, throw an exception. Wait condition judgment failed.

If it is a while (alist. size () <= 0) alist. wait (); then thread a is executed after wait () and then in a loop. Let's take a look at alist. size ()> 0, so directly execute
Removefirst, and then B executes it from wait and returns to the condition judgment. Let's take a look at alist. Size () <= 0. Oh, it's just a step slower. Let's wait.

The judgment conditions are properly controlled.

 

In addition, the threads in wait are not always awakened by the threads that control the loop conditions. For example, if you want to wait for someone now, the person will arrive at four o'clock, but now there are only two points. Now I want to go to bed, you ask your companions to wake you up. If you use

If (current time <four points)

I. Wait ();

Meet a person;

 

Before, not only your companions will wake you up. Maybe at, an alcoholic will come to wake you up. Then you will wake up and execute the following meet a person; however, because the time condition is not reached, the person is null, but if it is:

While (current time <four points)

I. Wait ();

Meet a person;

No matter how many people wake you up before the midpoint, you will check whether the time has reached four points. Only four points have allowed you to meet a person.

 

 

So it should be a habit to stick to the while (condition) for wait instead of if. Although if can work correctly occasionally (only one wait condition ).