peter.kovacs.1.0rc at gmail.com
Mon Jan 8 08:04:35 EST 2007
Thank you for your reply and pointing me to your "port". Wow...I am
surprised to see how elegantly this behavior can be achieved. (Being a
newbie to util.concurrent, I am often amazed how well this package is
designed; how elegantly one can use it.) I would definitely consider
replacing my tentative counter-based hacking with this one.
I am intrigued by your final remark, however. You say: "if you produce
work more quickly than you consume it over an extended period of time,
you will eventually run out of something, somewhere, unless you
throttle." My purpose with having the producer block when a limited
number of threads are fully utilized is just to suspend producing. Oh
I guess I see: do you mean by "throttling" that there is an (not
necessarily justified) overhead with handling rejected tasks (and task
Thanks a lot
On 1/8/07, Holger Hoffstätte <holger at wizards.de> wrote:
> Peter Kovacs wrote:
> > I would like to use some kind of ThreadPool executor for execution
> > which blocks when the maximum number of threads in the pool is reached
> > and all threads are utilized.
> As Joe pointed out this existed in the Doug Lea's original concurrent
> library, and since I needed it for backwards compatbility I "ported" it
> (accidentally for use with the backport lib too):
> test case:
> Feel free to use it any way you want; if you have questions drop me a line.
> That being said, waiting for the pool/queue only works for certain amounts
> of work and producer/consumer ratios: if you produce work more quickly
> than you consume it over an extended period of time, you will eventually
> run out of something, somewhere, unless you throttle.
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest