performance of BlockingQueue (again)
I'm migrating from 1.4.2 through 5.0 to 6.0, and would like to use
the Collections classes. I'm torn, tho: my current implementation uses
a home-grown blocking queue where one writer and many readers process
"records". The readers currently sleep for a period of time if the queue is
empty. The loop condition is "while (queue.isClosed != true)". Also, a "read"
on a closed queue throws an exception. (I don't like the practice of in-band
signaling for end-of-data)
If I wanted to use the BlockingQueue classes, I would either have to use the
offer() and poll() methods (with the timeout/retry), or each reader would have
to check each object returned by "take()" to see if it's the poison token.
Is there any experience where the performance graphs cross, as to number
of reader threads and takes vs number of block/sleep/peek kind of polling
loop?
Why isn't there an elegant way to simply signal the blocking "take()" threads
and let them know there's no more data coming (like q.notify())?
Thanks for any insight and advice.
[1132 byte] By [
androsa] at [2007-11-27 9:25:49]
# 1
> Why isn't there an elegant way to simply signal the
> blocking "take()" threads
> and let them know there's no more data coming (like
> q.notify())?
What do you want the consumer threads to do if there is no more data coming? Probably just clean up after themselves, right?
I'd suggest using take() and interrupting the consumer threads if the producer wants to shut down.
# 2
Hi there.
>>
>> I'd suggest using take() and interrupting the consumer threads..
>>
Yes, I think that's what I said I'd like to do. If there are many threads waiting
on one queue, I'll need a mechanism to identify each thread, iterate over the
list, and signal each thread individually.
I was hoping that the lock in BlockingQueue could be used to signal the
blocked threads, thus avoiding the coding hassle of managing the threads,
their states, etc. It's not as simple as calling "queue.notifyall()" as I would
have hoped.
> > Why isn't there an elegant way to simply signal
> the
> > blocking "take()" threads
> > and let them know there's no more data coming
> (like
> > q.notify())?
>
> What do you want the consumer threads to do if there
> is no more data coming? Probably just clean up after
> themselves, right?
> I'd suggest using take() and interrupting the
> consumer threads if the producer wants to shut down.
# 3
> Yes, I think that's what I said I'd like to do. If
> there are many threads waiting
> on one queue, I'll need a mechanism to identify each
> thread, iterate over the
> list, and signal each thread individually.
Right, that could have been made easier.
But if you make sure that all your worker threads are members of the same dedicated thread group, you may simply call ThreadGroup.interrupt().
Or, you use a ThreadPoolExecutor and call shutdownNow()
