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

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?

Thanks
Jean