Module com.conversantmedia.disruptor
Package com.conversantmedia.util.concurrent

Class DisruptorBlockingQueue<E>

  • All Implemented Interfaces:
    ConcurrentQueue<E>, Serializable, Iterable<E>, Collection<E>, BlockingQueue<E>, Queue<E>
    public final class DisruptorBlockingQueue<E>
extends MultithreadConcurrentQueue<E>
implements Serializable, Iterable<E>, Collection<E>, BlockingQueue<E>, Queue<E>
    This is a lock free blocking queue that implements a fixed length queue backed by a ring buffer. Access to the ring buffer is sequenced by iterating a pair of atomic sequence numbers. One is for the head and another for the tail. When a particular thread would like to append to the queue, it obtains the sequence number for the tail. When the thread is ready to commit changes, a machine compare and set is used to prove that the sequence number matches the expected value. In other words, no other thread has modified the sequence. If the sequence number does not match, the operation fails. If the sequence number matches expectation the thread can continue to operate on the queue's ring buffer without contention. This check cleverly avoids any synchronization thus the moniker "lock free." The lack of synchronization results in significant performance advantages. For consumers, access to the back of the ring is controlled by a memory barrier mechanism, namely the "volatile" keyword. Spin locks are employed to ensure the ring tail cursor is up to date prior to updating it. Once the ring cursor is updated, the reader/consumer can be assured that there is data available to read. The consumer thread then employs a mechanism similar to the producer to validate access to the ring. A sequence number for the head of the ring is obtained and when the reader would like to commit the change to the buffer it uses the machine compare and set to prove that no other thread has modified the ring in the interim. This pattern of access is roughly an order of magnitude faster than ArrayBlockingQueue. It is roughly 2x faster than LinkedTransferQueue for similar operations/conditions. Given that LinkedTransferQueue is "state of the art" in terms of Java performance, it is clear that the Disruptor mechanism offers advantages over other strategies. The only memory allocation in this object occurs at object creation and in the clone and drainTo methods. Otherwise, no garbage collection will ever be triggered by calls to the disruptor queue. The drainTo method implements an efficient "batch" mechanism, and may be used to safely claim all of the available queue entries. Drain will not perform as well when it is dealing with contention from other reader threads. Overall the disruptor pattern is weak in dealing with massive thread contention, however efforts have been made to deal with that case here. As always, one should test their intended strategy.
    Author:
    John Cairns <john@2ad.com> Date: 4/25/12 Time: 12:00 PM
    See Also:
    Serialized Form

    • Field Detail

      • queueNotFullCondition

        protected final com.conversantmedia.util.concurrent.Condition queueNotFullCondition

      • queueNotEmptyCondition

        protected final com.conversantmedia.util.concurrent.Condition queueNotEmptyCondition

    • Constructor Detail

      • DisruptorBlockingQueue

        public DisruptorBlockingQueue​(int capacity)

        Construct a blocking queue of the given fixed capacity.

        Note: actual capacity will be the next power of two larger than capacity.
        Parameters:
        capacity - maximum capacity of this queue

      • DisruptorBlockingQueue

        public DisruptorBlockingQueue​(int capacity,
                              SpinPolicy spinPolicy)

        Construct a blocking queue with a given fixed capacity

        Note: actual capacity will be the next power of two larger than capacity. Waiting locking may be used in servers that are tuned for it, waiting locking provides a high performance locking implementation which is approximately a factor of 2 improvement in throughput (40M/s for 1-1 thread transfers) However waiting locking is more CPU aggressive and causes servers that may be configured with far too many threads to show very high load averages. This is probably not as detrimental as it is annoying.
        Parameters:
        capacity - - the queue capacity, suggest using a power of 2
        spinPolicy - - determine the level of cpu aggressiveness in waiting

      • DisruptorBlockingQueue

        public DisruptorBlockingQueue​(int capacity,
                              Collection<? extends E> c)

        Construct a blocking queue of the given fixed capacity

        Note: actual capacity will be the next power of two larger than capacity.

        The values from the collection, c, are appended to the queue in iteration order. If the number of elements in the collection exceeds the actual capacity, then the additional elements overwrite the previous ones until all elements have been written once.
        Parameters:
        capacity - maximum capacity of this queue
        c - A collection to use to populate inital values