commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandy McArthur" <>
Subject Re: [pool] Any existing util.concurrent implementations?
Date Mon, 11 Sep 2006 23:07:07 GMT
Note: This thread previously lived on the Commons User list.

On 9/11/06, Holger Hoffstaette <> wrote:
> On Sat, 09 Sep 2006 22:53:00 -0400, Sandy McArthur wrote:
> > I have been following this plan for pool:
> > The current plan isn't
> > to require jdk 5 until Pool 3.0.
> OK. I don't agree but I guess that's my problem. ;-)
> However I think we can meet in the middle and make everyone happy, see
> below.
> > The code in svn for pool 2.0 implements the updated behavior but doesn't
> > have the performance characteristics I'm satisfied with on multi-cpu box.
> > (Current pool versions have the same performance bottle neck.) I got
> > stalled on reworking the code because of my wedding but I hope to start
> > moving forward again soon.
> Great, thanks for the update. I agree with all points on the roadmap for
> 2.0, especially the behavioral things like never having a null factory
> etc.
> Btw just curious how you test for lock contention etc.? I only know some
> JDK 1.5/1.6 features that measure the native locks and thread wait time
> but nothing for 1.4. I could provide test feedback on a shiny new
> dual-core Opteron.

I don't have any truly robust tests, just a series of micro-benchmarks
that try to simulate single threaded and multi-threaded access
patterns with fake-expensive poolable objects that I've run many times
on a single cpu, a hyper threaded cpu, and a quad xeon cpu servers. My
conclusion a few months ago was that  the serialization that happens
prevented the quad cpu server from delivering more than about 1.3
times the throughput of a single cpu server. I personally think it's
reasonable to expect a quad cpu server should give you at least a 3
times performance boost over a single cpu server.

> > While I have been working with Pool, there have been a number of people
> > who have submitted fast / non-blocking / unsynchronized pool
> > implementations but to achieve their speed they tend to ignore steps
> > needed to make a pool implementation thread-safe. There are many times
> > strict thread-safety isn't needed but I'm weary of including such code in
> > the official distribution.
> That sounds wrong - the whole idea behind lock-free/wait-free algorithms is
> that they are still thread-safe, yet with less unencessary synchronization
> and contention. If these contributions lead to a loss of thread safety for
> the pool they are just wrong, period. This stuff is hard and just removing
> synchronized statements because they work on someone's machine somewhere
> is a recipe for disaster.

Agreed, almost. If you don't need a pool with limits
(maxActive/maxIdle/etc) and don't care if getNumIdle() or getNumActive
are accurate then it is safe to strip away most all synchronization
for pure speed.

But thread-safe access to the backing idle object pool collection
isn't the main bottleneck despite that most people seem to look their
to make commons pool faster.

What slows the provided pool implementations down is the state
transitions poolable objects go through and the potential expense
activating or passivating poolable objects while keeping the limits in
check. For non-trivial poolable objects, which I assume all are, else
you wouldn't be pooling them, the pool spends most of it's time in the
activateObject, validateObject, and passivateObject methods. If those
can run in parallel then the total throughput of the pool increases
greatly, especially on multi-cpu servers. The problem is if you allow
activate, validate, and passivateObject methods to run in parallel it
gets much more complicated wether or not a poolable object that is
transitioning state will cause a limit to be exceeded.

For example pretty much every pool I've seen simply uses the internal
Collection's .size() method as the result of getNumIdle(). But without
full synchronization this isn't sufficient because a previously idle
poolable object isn't really active until activateObject is done. A
naive implementation will have a race condition that could allow too
many database connections be created or whatever else is being pooled.

> Anyway -
> since the roadmap for 2.0 indicates that JDK 1.4 is the target baseline it
> would IMHO be a wasted chance not to get best of both worlds -
> better data structures and readyness for JDK 1.5, yet run on JDK 1.4 to
> not cut off existing users. I therefore encourage you to consider the use
> of the backport concurrent library
> (
> It has a ASF-compatible license and some other Apache projects are
> adopting it too; the most recent example is MINA which had their own
> ThreadPool but *of course* struggled with the resulting and completely
> predictable bugs until last week.
> Using the backport would even enable the use of some highly cool stuff
> that is so far only in Mustang - mostly Deques which have significantly
> higher concurrency than single-lock Queues.
> Obviously producing a 'native' Tiger/Mustang version 3.0 from that will be
> trivial by simply fixing the package names.

I wasn't aware of backport-util-concurrent, I'll look into it.

> If you want to discuss this further please send me email or let's move
> this to commons-dev. I would love to help with the development. My main
> project is with the Mule ESB ( and we make
> extensive use of both commons-pool and the backport library; having both
> work together would benefit everybody, especially since we're still based
> on JDK 1.4 as well (with a possible move to 1.5 in 2007).
> Please let me know what you think or even better when and how I can start
> committing.. :)

Patches attached to a issue can be submitted as soon as you have them
ready, but you have to wait on a commiter to commit them. Then you
have to be asked to become a committer, accept, and then it takes a
some time and paper work to become official. You can read about it
Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message