Condition's await-signal process (RPM)

The previous article combed the Condtion, which focuses on the process, online to see this article is very thin introduction. Worth learning. Specially reproduced here.

Reprint Please specify source: Http://blog.csdn.net/luonanqin

Reprint Path: http://blog.csdn.net/bohu83/article/details/51107870

On a reentrantlock of the lock-unlock process, today this talk about condition await-signal process.

Condition class Diagram:

• The condition interface contains multiple await methods and two notification methods
• Conditionobject implements the condition interface, which is the inner class of Abstractqueuedsynchronizer
• The Newcondition method of Reentrantlock Returns the condition object associated with a lock instance

Like the release queue, the condition queue is also a virtual queue, and each node is associated with Nextwaiter. Because condition node will be released to release node to unblock, so there is no need to prevwaiter, this is explained below.

The approximate whole process is:

The thread that calls await will enter a condition queue. Each time the thread that calls signal starts to find the condition node in the release queue from Firstwaiter, The thread that calls signal then executes the release method at await or unlock to be able to unblock it. The normal process is simpler relative to Lock-unlock, but it is more complex for interrupt handling.

Let's take a look at the process of calling await () to blocking

, the process can be divided into three steps:

1. New condition node wrapper thread, join condition queue
2. Frees the lock occupied by the current thread
3. Block Current thread

Before blocking the current thread, determine if condition node is in the release queue. If there is no need to block, can directly participate in the lock competition. The key code is as follows:

AbstractQueuedSynchronizer.ConditionObject.class

Final BooleanIsonsyncqueue (node node) {//When entering the condition queue, Waitstatus is definitely condition, and if another thread calls Signal,node it is removed from the condition queue and the condition state is cleared when removed. //from removing to entering the release queue, the middle of this period of time Prev is bound to be null, so return false, the parkif(Node.waitstatus = = Node.condition | | node.prev = =NULL)  return false; //when another thread enters the release queue, it establishes a relationship with the previous node, so if Next exists, the description must be in the release queueif(Node.next! =NULL)//If has successor, it must is on queuereturn true; /** Node.prev can is non-null, but not yet on queue because * the CAS-to-place it on queue can fail.  So we had to * traverse from tail to make sure it actually made it. It * 'll always be near the tail in calls to this method, and * unless the CAS failed (which is unlikely), it W      Ill is * there, so we hardly ever traverse much. */  //It is possible that node just last entered the release queue, so it is tail, and its next must be null, so we need to look forward from the end of the teamreturnfindnodefromtail (node); }  

signal ()The flowchart signal method is simpler, starting with Firstwaiter, and finding a node that is not canceled in the release queue. However, even if the node that was found at the beginning is not canceled, it may be canceled when it is queued, so the code does a bit of special handling of the situation. I have explained the code in terms of my own understanding of the following:  

AbstractQueuedSynchronizer.ConditionObject.class

Final Booleantransferforsignal (node node) {/** If cannot change waitstatus, the node has been cancelled. */  //If the change waitstatus fails, the description has been canceled and no need to enter the release queue again. External re-loop to find a condition Node//What if the change Waitstatus succeeds, but then it is canceled? It doesn't matter, although it has already entered the release queue, but the Unpark operation in the release method skips the canceled node. The check here is just to reduce unnecessary work when Unparkif(!compareandsetwaitstatus (node, node.condition, 0))  return false; /** Splice onto queue and try to set waitstatus of predecessor to * indicate this thread is (probably) waitin G. If cancelled or * Attempt to set Waitstatus fails, wake-to-resync (in which * case the waitstatus can is T      Ransiently and harmlessly wrong). */  //P is the precursor to this nodeNode P=Enq (node); intWS =P.waitstatus; //here the effect of setting waitstatus can only occur when the thread is canceled, then the Cancelacquire method is called to set Waitstatus to cancel, but it is not a CASif(ws > 0 | |!)compareandsetwaitstatus (P, WS, node.signal))  Locksupport.unpark (Node.thread); return true; }  

As we can see, the signal method simply modifies node to the state and does not wake the thread. To wake up node after the modified state, one is to call await () again, and one is to call unlock (). Both methods perform the release method internally to unblock node in the release queue, as I explained in the previous article. Below I put the call await ()The process of the thread being unblocked is also drawn: The above is the detailed flow of await and signal. Signalall and signal are like, the interior is to add all the node in the condition queue to the release queue, that's all.

Then there is time I will put some interrupt processing also with the flowchart description issued.

Condition's await-signal process (RPM)