Condition's await-signal process

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

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.classfinal Boolean Isonsyncqueue (node node) {//When entering the condition queue,    Waitstatus must be condition, and if the other thread calls Signal,node, it will be removed from the condition queue and the condition state will be cleared when removed.        From removing to entering the release queue, the middle of this period of time prev must be null, so still return false, that is, park if (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, it must be in the release queue if (Node.next! = null)//If have successor, it must be    On queue return 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 wil     l AM * There, so we hardly ever traverse much. *///Maybe the node has just entered the release queue, so it is tail, and next is bound to be null, so you need to look forward from the tail to return Findnodefromtail (node);}

signal ()Flow chart



The signal method is simpler, starting with Firstwaiter, to find a node that has not been canceled and puts it 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.classfinal Boolean Transferforsignal (node node) {/* * If cannot chan     GE Waitstatus, the node has been cancelled. *//If change waitstatus fails, the description has been canceled and no need to enter the release queue again. External re-loop find a condition Node//If change waitstatus succeeds, but what happens after 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 the unnecessary work if Unpark (!compareandsetwaitstatus (node, node.condition, 0)) return false; /* * Splice onto queue and try to set waitstatus of predecessor to * indicate, this thread is (probably) waiting. If cancelled or * Attempt to set Waitstatus fails, wake-to-resync (in which * case the waitstatus can is Transi     ently and harmlessly wrong).    *///P is the node's precursor node P = ENQ (node);    int ws = P.waitstatus; Here the effect of setting waitstatus is only possible when the thread is canceled, then the Cancelacquire method is called to set Waitstatus to cancel, but it is not CAs if (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 ()After the thread has been unblocked, the process also draws a bit:


These are the detailed procedures for 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.

Resources:

How to understand condition http://www.liuinsect.com/2014/01/27/how_to_understand_condition/

Condition's await-signal process