[concurrency-interest] Quest for the optimal queue

√iktor Ҡlang 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
get a
>> 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
>>
>> Operations:
>> 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.

Check

> * 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.)

Check

>
> 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.

Cheers,
V

>
> -Doug
>
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120512/77ac66ff/attachment.html>


More information about the Concurrency-interest mailing list