[concurrency-interest] PooledLinkedBlockingQueue

Jean Morissette jean.morissette666@videotron.ca
Sun, 31 Oct 2004 11:30:32 -0500

Doug Lea wrote:
>>But, is-it possible to improve performance one step farther?  I am 
>>worried about memory allocation and garbage collection; maybe we can 
>>improve performance by reusing LinkedBlockingQueue.Node?
> I don't think this is a performance concern.  In micro-benchmarks,
> LinkedBlockingQueue usually has better concurrent scalability than
> ArrayBlockQueue, which doesn't do any dynamic allocation.
> It's hard to predict how well either of these will work in
> any given application, which is why we supply both. But I don't
> think that in-between solutions work out too well, although please
> feel free to prove to me otherwise :-)

I will try. :-)

Thus, in my PooledLinkedBlockingQueue implementation, methods 'offer' 
and 'put' get a Node from the pool if one is available, else we create a 
new one.  Method 'poll' and 'take' put the Node in the pool if it is not 

But, what could be the best structure and strategy to use for the pool? 
  I am worried that the pool become a bottleneck with synchronization. 
So, is-it possible to don't do any locking when using the pool?  Is the 
wait-free ConcurrentLinkedQueue a good choice?  Advices?