peger at automotive.com
Thu Oct 6 20:08:33 EDT 2005
> Patrick Eger wrote:
> >>PS. Doug Lea is obviously incommunicado right now .
> No, but Joe and David have handled this so well that I have
> nothing to add :-)
> ... except to say that ThreadPoolExecutor handles as many
> variants as we can support without hurting performance or
> adding too much for any given mode of use. It sounds like
> your application might escape the boundaries. Except that I'd
> be surprised if a simple cahchedThreadPool was measurably
> worse that what you are doing.
The problem with cachedThreadPool() for our use was that the synchronous
handoff / lack of queuing makes us unable to smoothe out transient
request bursts, and lack of MAX size on the pool means potential
resource exhaustion. I couldn't see a way around the SynchronousQueue
> Bounding to thousands of threads on a 2 or 4way machine is
> not much different than not bounding at all.
Unbounded would likely work as well if threads were cheaper than they
are. Alas, we are only able to allocate a few thousand threads per JVM
maximum, and we need it to be shared dynamically among 10-20 separate
PS As an aside, are there any known issues with the old "oswego" package
thread pools (since the new JDK5 memory model)? I seem to remember
these giving us the desired charateristics, though i'd hate to switch
back and will more likely attempt some modification of the Mustang
sources as previously mentioned.
Again, thanks a bunch for everybody's help on this.
More information about the Concurrency-interest