/*

 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

 *

 * This code is free software; you can redistribute it and/or modify it

 * under the terms of the GNU General Public License version 2 only, as

 * published by the Free Software Foundation.  Oracle designates this

 * particular file as subject to the "Classpath" exception as provided

 * by Oracle in the LICENSE file that accompanied this code.

 *

 * This code is distributed in the hope that it will be useful, but WITHOUT

 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or

 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License

 * version 2 for more details (a copy is included in the LICENSE file that

 * accompanied this code).

 *

 * You should have received a copy of the GNU General Public License version

 * 2 along with this work; if not, write to the Free Software Foundation,

 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.

 *

 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA

 * or visit www.oracle.com if you need additional information or have any

 * questions.

 */

/*

 * This file is available under and governed by the GNU General Public

 * License version 2 only, as published by the Free Software Foundation.

 * However, the following notice accompanied the original version of this

 * file:

 *

 * Written by Doug Lea with assistance from members of JCP JSR-166

 * Expert Group and released to the public domain, as explained at

 */

package java.util.concurrent;

import java.util.AbstractQueue;

import java.util.Collection;

import java.util.Iterator;

import java.util.NoSuchElementException;

import java.util.Queue;

import java.util.concurrent.TimeUnit;

import java.util.concurrent.locks.LockSupport;

/**

 * An unbounded {@link TransferQueue} based on linked nodes.

 * This queue orders elements FIFO (first-in-first-out) with respect

 * to any given producer.  The <em>head</em> of the queue is that

 * element that has been on the queue the longest time for some

 * producer.  The <em>tail</em> of the queue is that element that has

 * been on the queue the shortest time for some producer.

 *

 * <p>Beware that, unlike in most collections, the {@code size}

 * method is <em>NOT</em> a constant-time operation. Because of the

 * asynchronous nature of these queues, determining the current number

 * of elements requires a traversal of the elements.

 *

 * <p>This class and its iterator implement all of the

 * <em>optional</em> methods of the {@link Collection} and {@link

 * Iterator} interfaces.

 *

 * <p>Memory consistency effects: As with other concurrent

 * collections, actions in a thread prior to placing an object into a

 * {@code LinkedTransferQueue}

 * <a href="package-summary.html#MemoryVisibility"><i>happen-before</i></a>

 * actions subsequent to the access or removal of that element from

 * the {@code LinkedTransferQueue} in another thread.

 *

 * <p>This class is a member of the

 * <a href="{@docRoot}/../technotes/guides/collections/index.html">

 * Java Collections Framework</a>.

 *

 * @since 1.7

 * @author Doug Lea

 * @param <E> the type of elements held in this collection

 */

public class LinkedTransferQueue<E> extends AbstractQueue<E>

    implements TransferQueue<E>, java.io.Serializable {

    private static final long serialVersionUID = -3223113410248163686L;

    /*

     * *** Overview of Dual Queues with Slack ***

     *

     * Dual Queues, introduced by Scherer and Scott

     * (http://www.cs.rice.edu/~wns1/papers/2004-DISC-DDS.pdf) are

     * (linked) queues in which nodes may represent either data or

     * requests.  When a thread tries to enqueue a data node, but

     * encounters a request node, it instead "matches" and removes it;

     * and vice versa for enqueuing requests. Blocking Dual Queues

     * arrange that threads enqueuing unmatched requests block until

     * other threads provide the match. Dual Synchronous Queues (see

     * Scherer, Lea, & Scott

     * http://www.cs.rochester.edu/u/scott/papers/2009_Scherer_CACM_SSQ.pdf)

     * additionally arrange that threads enqueuing unmatched data also

     * block.  Dual Transfer Queues support all of these modes, as

     * dictated by callers.

     *

     * A FIFO dual queue may be implemented using a variation of the

     * Michael & Scott (M&S) lock-free queue algorithm

     * (http://www.cs.rochester.edu/u/scott/papers/1996_PODC_queues.pdf).

     * It maintains two pointer fields, "head", pointing to a

     * (matched) node that in turn points to the first actual

     * (unmatched) queue node (or null if empty); and "tail" that

     * points to the last node on the queue (or again null if

     * empty). For example, here is a possible queue with four data

     * elements:

     *

     *  head                tail

     *    |                   |

     *    v                   v

     *    M -> U -> U -> U -> U

     *

     * The M&S queue algorithm is known to be prone to scalability and

     * overhead limitations when maintaining (via CAS) these head and

     * tail pointers. This has led to the development of

     * contention-reducing variants such as elimination arrays (see

     * Moir et al http://portal.acm.org/citation.cfm?id=1074013) and

     * optimistic back pointers (see Ladan-Mozes & Shavit

     * http://people.csail.mit.edu/edya/publications/OptimisticFIFOQueue-journal.pdf).

     * However, the nature of dual queues enables a simpler tactic for

     * improving M&S-style implementations when dual-ness is needed.

     *

     * In a dual queue, each node must atomically maintain its match

     * status. While there are other possible variants, we implement

     * this here as: for a data-mode node, matching entails CASing an

     * "item" field from a non-null data value to null upon match, and

     * vice-versa for request nodes, CASing from null to a data

     * value. (Note that the linearization properties of this style of

     * queue are easy to verify -- elements are made available by

     * linking, and unavailable by matching.) Compared to plain M&S

     * queues, this property of dual queues requires one additional

     * successful atomic operation per enq/deq pair. But it also

     * enables lower cost variants of queue maintenance mechanics. (A

     * variation of this idea applies even for non-dual queues that

     * support deletion of interior elements, such as

     * j.u.c.ConcurrentLinkedQueue.)

     *

     * Once a node is matched, its match status can never again

     * change.  We may thus arrange that the linked list of them

     * contain a prefix of zero or more matched nodes, followed by a

     * suffix of zero or more unmatched nodes. (Note that we allow

     * both the prefix and suffix to be zero length, which in turn

     * means that we do not use a dummy header.)  If we were not

     * concerned with either time or space efficiency, we could

     * correctly perform enqueue and dequeue operations by traversing

     * from a pointer to the initial node; CASing the item of the

     * first unmatched node on match and CASing the next field of the

     * trailing node on appends. (Plus some special-casing when

     * initially empty).  While this would be a terrible idea in

     * itself, it does have the benefit of not requiring ANY atomic

     * updates on head/tail fields.

     *

     * We introduce here an approach that lies between the extremes of

     * never versus always updating queue (head and tail) pointers.

     * This offers a tradeoff between sometimes requiring extra

     * traversal steps to locate the first and/or last unmatched

     * nodes, versus the reduced overhead and contention of fewer

     * updates to queue pointers. For example, a possible snapshot of

     * a queue is:

     *

     *  head           tail

     *    |              |

     *    v              v

     *    M -> M -> U -> U -> U -> U

     *

     * The best value for this "slack" (the targeted maximum distance

     * between the value of "head" and the first unmatched node, and

     * similarly for "tail") is an empirical matter. We have found

     * that using very small constants in the range of 1-3 work best

     * over a range of platforms. Larger values introduce increasing

     * costs of cache misses and risks of long traversal chains, while

     * smaller values increase CAS contention and overhead.

     *

     * Dual queues with slack differ from plain M&S dual queues by

     * virtue of only sometimes updating head or tail pointers when

     * matching, appending, or even traversing nodes; in order to

     * maintain a targeted slack.  The idea of "sometimes" may be

     * operationalized in several ways. The simplest is to use a

     * per-operation counter incremented on each traversal step, and

     * to try (via CAS) to update the associated queue pointer

     * whenever the count exceeds a threshold. Another, that requires

     * more overhead, is to use random number generators to update

     * with a given probability per traversal step.

     *

     * In any strategy along these lines, because CASes updating

     * fields may fail, the actual slack may exceed targeted

     * slack. However, they may be retried at any time to maintain

     * targets.  Even when using very small slack values, this

     * approach works well for dual queues because it allows all

     * operations up to the point of matching or appending an item

     * (hence potentially allowing progress by another thread) to be

     * read-only, thus not introducing any further contention. As

     * described below, we implement this by performing slack

     * maintenance retries only after these points.

     *

     * As an accompaniment to such techniques, traversal overhead can

     * be further reduced without increasing contention of head

     * pointer updates: Threads may sometimes shortcut the "next" link

     * path from the current "head" node to be closer to the currently

     * known first unmatched node, and similarly for tail. Again, this

     * may be triggered with using thresholds or randomization.

     *

     * These ideas must be further extended to avoid unbounded amounts

     * of costly-to-reclaim garbage caused by the sequential "next"

     * links of nodes starting at old forgotten head nodes: As first

     * described in detail by Boehm

     * (http://portal.acm.org/citation.cfm?doid=503272.503282) if a GC

     * delays noticing that any arbitrarily old node has become

     * garbage, all newer dead nodes will also be unreclaimed.

     * (Similar issues arise in non-GC environments.)  To cope with

     * this in our implementation, upon CASing to advance the head

     * pointer, we set the "next" link of the previous head to point

     * only to itself; thus limiting the length of connected dead lists.

     * (We also take similar care to wipe out possibly garbage

     * retaining values held in other Node fields.)  However, doing so

     * adds some further complexity to traversal: If any "next"

     * pointer links to itself, it indicates that the current thread

     * has lagged behind a head-update, and so the traversal must

     * continue from the "head".  Traversals trying to find the

     * current tail starting from "tail" may also encounter

     * self-links, in which case they also continue at "head".

     *

     * It is tempting in slack-based scheme to not even use CAS for

     * updates (similarly to Ladan-Mozes & Shavit). However, this

     * cannot be done for head updates under the above link-forgetting

     * mechanics because an update may leave head at a detached node.

     * And while direct writes are possible for tail updates, they

     * increase the risk of long retraversals, and hence long garbage

     * chains, which can be much more costly than is worthwhile

     * considering that the cost difference of performing a CAS vs

     * write is smaller when they are not triggered on each operation

     * (especially considering that writes and CASes equally require

     * additional GC bookkeeping ("write barriers") that are sometimes

     * more costly than the writes themselves because of contention).

     *

     * *** Overview of implementation ***

     *

     * We use a threshold-based approach to updates, with a slack

     * threshold of two -- that is, we update head/tail when the

     * current pointer appears to be two or more steps away from the

     * first/last node. The slack value is hard-wired: a path greater

     * than one is naturally implemented by checking equality of

     * traversal pointers except when the list has only one element,

     * in which case we keep slack threshold at one. Avoiding tracking

     * explicit counts across method calls slightly simplifies an

     * already-messy implementation. Using randomization would

     * probably work better if there were a low-quality dirt-cheap

     * per-thread one available, but even ThreadLocalRandom is too

     * heavy for these purposes.

     *

     * With such a small slack threshold value, it is not worthwhile

     * to augment this with path short-circuiting (i.e., unsplicing

     * interior nodes) except in the case of cancellation/removal (see

     * below).

     *

     * We allow both the head and tail fields to be null before any

     * nodes are enqueued; initializing upon first append.  This

     * simplifies some other logic, as well as providing more

     * efficient explicit control paths instead of letting JVMs insert

     * implicit NullPointerExceptions when they are null.  While not

     * currently fully implemented, we also leave open the possibility

     * of re-nulling these fields when empty (which is complicated to

     * arrange, for little benefit.)

     *

     * All enqueue/dequeue operations are handled by the single method

     * "xfer" with parameters indicating whether to act as some form

     * of offer, put, poll, take, or transfer (each possibly with

     * timeout). The relative complexity of using one monolithic

     * method outweighs the code bulk and maintenance problems of

     * using separate methods for each case.

     *

     * Operation consists of up to three phases. The first is

     * implemented within method xfer, the second in tryAppend, and

     * the third in method awaitMatch.

     *

     * 1. Try to match an existing node

     *

     *    Starting at head, skip already-matched nodes until finding

     *    an unmatched node of opposite mode, if one exists, in which

     *    case matching it and returning, also if necessary updating

     *    head to one past the matched node (or the node itself if the

     *    list has no other unmatched nodes). If the CAS misses, then

     *    a loop retries advancing head by two steps until either

     *    success or the slack is at most two. By requiring that each

     *    attempt advances head by two (if applicable), we ensure that

     *    the slack does not grow without bound. Traversals also check

     *    if the initial head is now off-list, in which case they

     *    start at the new head.

     *

     *    If no candidates are found and the call was untimed

     *    poll/offer, (argument "how" is NOW) return.

     *

     * 2. Try to append a new node (method tryAppend)

     *

     *    Starting at current tail pointer, find the actual last node

     *    and try to append a new node (or if head was null, establish

     *    the first node). Nodes can be appended only if their

     *    predecessors are either already matched or are of the same

     *    mode. If we detect otherwise, then a new node with opposite

     *    mode must have been appended during traversal, so we must

     *    restart at phase 1. The traversal and update steps are

     *    otherwise similar to phase 1: Retrying upon CAS misses and

     *    checking for staleness.  In particular, if a self-link is

     *    encountered, then we can safely jump to a node on the list

     *    by continuing the traversal at current head.

     *

     *    On successful append, if the call was ASYNC, return.

     *

     * 3. Await match or cancellation (method awaitMatch)

     *

     *    Wait for another thread to match node; instead cancelling if

     *    the current thread was interrupted or the wait timed out. On

     *    multiprocessors, we use front-of-queue spinning: If a node

     *    appears to be the first unmatched node in the queue, it

     *    spins a bit before blocking. In either case, before blocking

     *    it tries to unsplice any nodes between the current "head"

     *    and the first unmatched node.

     *

     *    Front-of-queue spinning vastly improves performance of

     *    heavily contended queues. And so long as it is relatively

     *    brief and "quiet", spinning does not much impact performance

     *    of less-contended queues.  During spins threads check their

     *    interrupt status and generate a thread-local random number

     *    to decide to occasionally perform a Thread.yield. While

     *    yield has underdefined specs, we assume that might it help,

     *    and will not hurt in limiting impact of spinning on busy

     *    systems.  We also use smaller (1/2) spins for nodes that are

     *    not known to be front but whose predecessors have not

     *    blocked -- these "chained" spins avoid artifacts of

     *    front-of-queue rules which otherwise lead to alternating

     *    nodes spinning vs blocking. Further, front threads that

     *    represent phase changes (from data to request node or vice

     *    versa) compared to their predecessors receive additional

     *    chained spins, reflecting longer paths typically required to

     *    unblock threads during phase changes.

     *

     *

     * ** Unlinking removed interior nodes **

     *

     * In addition to minimizing garbage retention via self-linking

     * described above, we also unlink removed interior nodes. These

     * may arise due to timed out or interrupted waits, or calls to

     * remove(x) or Iterator.remove.  Normally, given a node that was

     * at one time known to be the predecessor of some node s that is

     * to be removed, we can unsplice s by CASing the next field of

     * its predecessor if it still points to s (otherwise s must

     * already have been removed or is now offlist). But there are two

     * situations in which we cannot guarantee to make node s

     * unreachable in this way: (1) If s is the trailing node of list

     * (i.e., with null next), then it is pinned as the target node

     * for appends, so can only be removed later after other nodes are

     * appended. (2) We cannot necessarily unlink s given a

     * predecessor node that is matched (including the case of being

     * cancelled): the predecessor may already be unspliced, in which

     * case some previous reachable node may still point to s.

     * (For further explanation see Herlihy & Shavit "The Art of

     * Multiprocessor Programming" chapter 9).  Although, in both

     * cases, we can rule out the need for further action if either s

     * or its predecessor are (or can be made to be) at, or fall off

     * from, the head of list.

     *

     * Without taking these into account, it would be possible for an

     * unbounded number of supposedly removed nodes to remain

     * reachable.  Situations leading to such buildup are uncommon but

     * can occur in practice; for example when a series of short timed

     * calls to poll repeatedly time out but never otherwise fall off

     * the list because of an untimed call to take at the front of the

     * queue.

     *

     * When these cases arise, rather than always retraversing the

     * entire list to find an actual predecessor to unlink (which

     * won't help for case (1) anyway), we record a conservative

     * estimate of possible unsplice failures (in "sweepVotes").

     * We trigger a full sweep when the estimate exceeds a threshold

     * ("SWEEP_THRESHOLD") indicating the maximum number of estimated

     * removal failures to tolerate before sweeping through, unlinking

     * cancelled nodes that were not unlinked upon initial removal.

     * We perform sweeps by the thread hitting threshold (rather than

     * background threads or by spreading work to other threads)

     * because in the main contexts in which removal occurs, the

     * caller is already timed-out, cancelled, or performing a

     * potentially O(n) operation (e.g. remove(x)), none of which are

     * time-critical enough to warrant the overhead that alternatives

     * would impose on other threads.

     *

     * Because the sweepVotes estimate is conservative, and because

     * nodes become unlinked "naturally" as they fall off the head of

     * the queue, and because we allow votes to accumulate even while

     * sweeps are in progress, there are typically significantly fewer

     * such nodes than estimated.  Choice of a threshold value

     * balances the likelihood of wasted effort and contention, versus

     * providing a worst-case bound on retention of interior nodes in

     * quiescent queues. The value defined below was chosen

     * empirically to balance these under various timeout scenarios.

     *

     * Note that we cannot self-link unlinked interior nodes during

     * sweeps. However, the associated garbage chains terminate when

     * some successor ultimately falls off the head of the list and is

     * self-linked.

     */

    /** True if on multiprocessor */

    private static final boolean MP =

        Runtime.getRuntime().availableProcessors() > 1;

    /**

     * The number of times to spin (with randomly interspersed calls

     * to Thread.yield) on multiprocessor before blocking when a node

     * is apparently the first waiter in the queue.  See above for

     * explanation. Must be a power of two. The value is empirically

     * derived -- it works pretty well across a variety of processors,

     * numbers of CPUs, and OSes.

     */

    private static final int FRONT_SPINS   = 1 << 7;

    /**

     * The number of times to spin before blocking when a node is

     * preceded by another node that is apparently spinning.  Also

     * serves as an increment to FRONT_SPINS on phase changes, and as

     * base average frequency for yielding during spins. Must be a

     * power of two.

     */

    private static final int CHAINED_SPINS = FRONT_SPINS >>> 1;

    /**

     * The maximum number of estimated removal failures (sweepVotes)

     * to tolerate before sweeping through the queue unlinking

     * cancelled nodes that were not unlinked upon initial

     * removal. See above for explanation. The value must be at least

     * two to avoid useless sweeps when removing trailing nodes.

     */

    static final int SWEEP_THRESHOLD = 32;

    /**

     * Queue nodes. Uses Object, not E, for items to allow forgetting

     * them after use.  Relies heavily on Unsafe mechanics to minimize

     * unnecessary ordering constraints: Writes that are intrinsically

     * ordered wrt other accesses or CASes use simple relaxed forms.

     */

    static final class Node {

        final boolean isData;   // false if this is a request node

        volatile Object item;   // initially non-null if isData; CASed to match

        volatile Node next;

        volatile Thread waiter; // null until waiting

        // CAS methods for fields

        final boolean casNext(Node cmp, Node val) {

            return UNSAFE.compareAndSwapObject(this, nextOffset, cmp, val);

        }

        final boolean casItem(Object cmp, Object val) {

            // assert cmp == null || cmp.getClass() != Node.class;

            return UNSAFE.compareAndSwapObject(this, itemOffset, cmp, val);

        }

        /**

         * Constructs a new node.  Uses relaxed write because item can

         * only be seen after publication via casNext.

         */

        Node(Object item, boolean isData) {

            UNSAFE.putObject(this, itemOffset, item); // relaxed write

            this.isData = isData;

        }

        /**

         * Links node to itself to avoid garbage retention.  Called

         * only after CASing head field, so uses relaxed write.

         */

        final void forgetNext() {

            UNSAFE.putObject(this, nextOffset, this);

        }

        /**

         * Sets item to self and waiter to null, to avoid garbage

         * retention after matching or cancelling. Uses relaxed writes

         * because order is already constrained in the only calling

         * contexts: item is forgotten only after volatile/atomic

         * mechanics that extract items.  Similarly, clearing waiter

         * follows either CAS or return from park (if ever parked;

         * else we don't care).

         */

        final void forgetContents() {

            UNSAFE.putObject(this, itemOffset, this);

            UNSAFE.putObject(this, waiterOffset, null);

        }

        /**

         * Returns true if this node has been matched, including the

         * case of artificial matches due to cancellation.

         */

        final boolean isMatched() {

            Object x = item;

            return (x == this) || ((x == null) == isData);

        }

        /**

         * Returns true if this is an unmatched request node.

         */

        final boolean isUnmatchedRequest() {

            return !isData && item == null;

        }

        /**

         * Returns true if a node with the given mode cannot be

         * appended to this node because this node is unmatched and

         * has opposite data mode.

         */

        final boolean cannotPrecede(boolean haveData) {

            boolean d = isData;

            Object x;

            return d != haveData && (x = item) != this && (x != null) == d;

        }

        /**

         * Tries to artificially match a data node -- used by remove.

         */

        final boolean tryMatchData() {

            // assert isData;

            Object x = item;