[concurrency-interest] LinkedBlockedQueue

Kasper Nielsen kav@kav.dk
Sat, 27 Sep 2003 10:52:11 +0200


> > I was looking at the toArray() methods in LinkedBlockingQueue
> 
> I think you misinterpreted this method. It does not extract 
> elements into the array; it copies them (as do all other 
> Collection.toArray methods).

I most certainly have.. And its not the first time I tend to forget that
this queue also has collection semantics and not just ordinary queue
semantics.

> I think this accounts for your confusion about questions 1-2.
> 
> I gather that what you are looking for is a non-existent method
>   <T> T[] drain(T[] array)
> and/or  
>   void drain(Collection<E> c, int maxElements)
> that drains (i.e., removes) up to maxElements elements into 
> an array or collection.  (It would need to be non-blocking, 
> poll-like rather than take-like, or else multiple drain's 
> could be starved out unless there were uniform fairness 
> guarantees across queues, which there aren't.  This is 
> analogous to why FairSemaphore supports acquire(n), but 
> non-guaranteed-fair Semaphore does not.)
> 
> Could you give a compelling use case or two showing why you 
> need something like this?  Can anyone else?

Can't speak for others, but I use queues to introduce an isolated
execution boundary in my application. The units of work enqueued on each
queue are small and fast to compute so I would like to process a big
batch (say 100-1000) of events each time. If I need to poll each single
element I would pay a penalty both in form of acquiring/releasing a lot
of locks and in form of a lot of switches between unrelated pieces of
code, thereby destroying the program locality (caching/ branch
predictors).

- Kasper