Wait queue node class.
The wait queue is a variant of a "CLH" (Craig, Landin, and Hagersten) lock
queue. CLH locks are normally used for spinlocks. We instead use them for
blocking synchronizers, but use the same basic tactic of holding some of
the control information about a thread in the predecessor of its node. A
"status" field in each node keeps track of whether a thread should block. A
node is signalled when its predecessor releases. Each node of the queue
otherwise serves as a specific-notification-style monitor holding a single
waiting thread. The status field does NOT control whether threads are
granted locks etc though. A thread may try to acquire if it is first in the
queue. But being first does not guarantee success; it only gives the right
to contend. So the currently released contender thread may need to rewait.
To enqueue into a CLH lock, you atomically splice it in as new tail. To
dequeue, you just set the head field.
+------+ prev +-----+ +-----+
head | | <---- | | <---- | | tail
+------+ +-----+ +-----+
Insertion into a CLH queue requires only a single atomic operation on
"tail", so there is a simple atomic point of demarcation from unqueued to
queued. Similarly, dequeing involves only updating the "head". However, it
takes a bit more work for nodes to determine who their successors are, in
part to deal with possible cancellation due to timeouts and interrupts.
The "prev" links (not used in original CLH locks), are mainly needed to
handle cancellation. If a node is cancelled, its successor is (normally)
relinked to a non-cancelled predecessor. For explanation of similar
mechanics in the case of spin locks, see the papers by Scott and Scherer at
http://www.cs.rochester.edu/u/scott/synchronization/
We also use "next" links to implement blocking mechanics. The thread id for
each node is kept in its own node, so a predecessor signals the next node
to wake up by traversing next link to determine which thread it is.
Determination of successor must avoid races with newly queued nodes to set
the "next" fields of their predecessors. This is solved when necessary by
checking backwards from the atomically updated "tail" when a node's
successor appears to be null. (Or, said differently, the next-links are an
optimization so that we don't usually need a backward scan.)
Cancellation introduces some conservatism to the basic algorithms. Since we
must poll for cancellation of other nodes, we can miss noticing whether a
cancelled node is ahead or behind us. This is dealt with by always
unparking successors upon cancellation, allowing them to stabilize on a new
predecessor.
CLH queues need a dummy header node to get started. But we don't create
them on construction, because it would be wasted effort if there is never
contention. Instead, the node is constructed and head and tail pointers are
set upon first contention.
Threads waiting on Conditions use the same nodes, but use an additional
link. Conditions only need to link nodes in simple (non-concurrent) linked
queues because they are only accessed when exclusively held. Upon await, a
node is inserted into a condition queue. Upon signal, the node is
transferred to the main queue. A special value of status field is used to
mark which queue a node is on.
Thanks go to Dave Dice, Mark Moir, Victor Luchangco, Bill Scherer and
Michael Scott, along with members of JSR-166 expert group, for helpful
ideas, discussions, and critiques on the design of this class.