[concurrency-interest] Quest for the optimal queue
viktor.klang at gmail.com
Sat May 12 07:26:46 EDT 2012
On May 12, 2012 12:52 PM, "Doug Lea" <dl at cs.oswego.edu> wrote:
> On 05/11/12 11:00, √iktor Ҡlang wrote:
>> I'd like to explore alternatives to ConcurrentLinkedQueue, especially to
>> bit lower latency and perhaps even lower mem usage.
> LinkedTransferQueue is often a bit faster than ConcurrentLinkedQueue,
> so you should give it a try.
>> No locks, Unbounded, Single consumer, Multiple producers
>> dequeue, enqueue, numberOfMessages, hasMessages
> In general, we can do better than CLQ/LTQ only by weakening
> some specs, including:
> * Relaxing strict FIFO guarantees
I only need fifo per enqueuer
> * Specializing for a single producer, single consumer, or both.
> * Relaxing guarantees about or not supporting blocking
No blocking is preferrable
> * Not supporting some Collection operations (in particular, as
> Martin noted, supporting arbitrary remove(element) forces
> very noticeable overhead on unrelated operations.)
> There are a number of good algorithms that make some of
> these tradeoffs (flat-combining, multi-lane, Lamport etc),
> including some used internally (like the fast task queues
> used inside ForkJoin). We haven't put any in j.u.c. mainly
> because they seem to fall outside of the scope of kinds of
> components that should ship with JDK. We ought to consider
> developing and releasing some in some other way.
Sounds great, I'd help out.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest