Sandy, thanks for your reply.
On Sat, 09 Sep 2006 22:53:00 -0400, Sandy McArthur wrote: > I have been following this plan for pool: > http://wiki.apache.org/jakarta-commons/PoolRoadMap 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. > 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. 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 (http://dcl.mathcs.emory.edu/util/backport-util-concurrent/). 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. 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 (http://mule.codehaus.org/) 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.. :) regards, Holger --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
