[concurrency-interest] Asynchronous-nature of ConcurrentLinkedQueue
ben_manes at yahoo.com
Tue May 18 19:06:19 EDT 2010
In the few cases where I've needed a fast count on a CLQ, I didn't need to maintain it as expensively as performing an increment/decrement per queue operation. Generally there was some usage characteristic, such as a single thread draining the queue, that allowed me to reduce the contention on the counter. Its actually quite nice having the flexibility to choose how to manage the performance of the count when it actually matters.
From: Gregg Wonderly <gergg at cox.net>
To: Doug Lea <dl at cs.oswego.edu>
Cc: concurrency-interest at cs.oswego.edu
Sent: Tue, May 18, 2010 3:28:17 PM
Subject: Re: [concurrency-interest] Asynchronous-nature of ConcurrentLinkedQueue
Doug Lea wrote:
> On 05/18/10 08:03, Kai Meder wrote:
>> reading the Java-Docs of ConcurrentLinkedQueue I wonder what the
>> "asynchronous nature" mentioned in the size()-doc is?
>> "Beware that, unlike in most collections, this method is NOT a
>> constant-time operation. Because of the asynchronous nature of these
>> queues, determining the current number of elements requires an O(n)
>> traversal. "
> Because insertion and removal operations can occur concurrently
> (even while you are asking about the size), you generally
> don't want to ask about the size (although isEmpty is usually
> still useful). But if you do ask, the queue
> will provide an answer by counting up the elements. The
> answer it returns might not have much bearing to the actual
> number of elements upon return of the method.
And I guess I am always curious why there is no "counter" associated with the
queue length. It would provide the same "rough" estimate as the "traversal"
without the repeated overhead would it not?
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest