[concurrency-interest] Quest for the optimal queue

Martin Buchholz martinrb at google.com
Fri May 11 22:18:29 EDT 2012


If you remove the ability to remove from the middle via iterator.remove and
only allow single-threaded dequeue, some of the code can be simplified, and
the consumer should be much more efficient.  But I don't see a footprint
reduction.  Copy CLQ and hack away.  Only the next pointers have to be
volatile.

Martin

On Fri, May 11, 2012 at 8:00 AM, √iktor Ҡlang <viktor.klang at gmail.com>wrote:

> Hey guys,
>
> I'd like to explore alternatives to ConcurrentLinkedQueue, especially to
> get a bit lower latency and perhaps even lower mem usage.
>
> Behavior:
> No locks
> Unbounded
> Single consumer
> Multiple producers
>
> Operations:
>
> dequeue
> enqueue
> numberOfMessages // Would be nice to have as a constant, can be linear or
> simply not supported, doesn't really matter
> hasMessages // Just a Boolean if there's anything in there at all, only
> needs to return true if something has been put in that hasn't been pulled
> out yet
>
> Is there anything out there which is better than CLQ?
>
> Cheers,
>>
> --
> Viktor Klang
>
> Akka Tech Lead
> Typesafe <http://www.typesafe.com/> - The software stack for applications
> that scale
>
> Twitter: @viktorklang
>
>
> _______________________________________________
> 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/20120511/28fd28b3/attachment.html>


More information about the Concurrency-interest mailing list