ConcurrentLinkedQueue
which is an unbounded multi-producer, multi-consumer queue which is further encumbered by the need to implement
the full range of Queue
methods.See: Description
Interface | Description |
---|---|
MessagePassingQueue<T> |
This is a tagging interface for the queues in this library which implement a subset of the
Queue
interface sufficient for concurrent message passing.Message passing queues provide happens before semantics to messages passed through, namely that writes made by the producer before offering the message are visible to the consuming thread after the message has been polled out of the queue. |
MessagePassingQueue.Consumer<T> | |
MessagePassingQueue.ExitCondition | |
MessagePassingQueue.Supplier<T> | |
MessagePassingQueue.WaitStrategy | |
QueueProgressIndicators |
This interface is provided for monitoring purposes only and is only available on queues where it is easy to
provide it.
|
ConcurrentLinkedQueue
which is an unbounded multi-producer, multi-consumer queue which is further encumbered by the need to implement
the full range of Queue
methods. In this package we offer a range of implementations:
Limited Queue methods support:
The queues implement a subset of the Queue
interface which is documented under the
MessagePassingQueue
interface. In particular Collection.iterator()
is not
supported and dependent methods from AbstractQueue
are also not supported such as:
Collection.remove(Object)
Collection.removeAll(java.util.Collection)
Collection.removeIf(java.util.function.Predicate)
Collection.contains(Object)
Collection.containsAll(java.util.Collection)
Memory layout controls and False Sharing:
The classes in this package use what is considered at the moment the most reliable method of controlling
class field layout, namely inheritance. The method is described in this post which also
covers why other methods are currently suspect.
Note that we attempt to tackle both active (write/write) and passive(read/write) false sharing case:
Use of sun.misc.Unsafe:
A choice is made in this library to utilize sun.misc.Unsafe for performance reasons. In this package we have two
use cases:
AtomicLongFieldUpdater
but choose not to.
AtomicReferenceArray
but
the extra reference chase and redundant boundary checks are considered too high a price to pay at this time.
Avoiding redundant loads of fields
Because a volatile load will force any following field access to reload the field value an effort is made to cache field values in local variables
where possible and expose interfaces which allow the code to capitalize on such caching. As a convention the local variable name will be the field
name and will be final.
Method naming conventions
The following convention is followed in method naming to highlight volatile/ordered/plain access to fields:
AtomicInteger.lazySet(int)
). Implies an ordering of
stores (StoreStore barrier before the store).
AtomicInteger.compareAndSet(int, int)
AtomicInteger.getAndSet(int)
AtomicInteger.getAndAdd(int)