On Sun, 2005-10-23 at 22:11 +0100, sebb wrote: > On 23/10/05, robert burrell donkin <[EMAIL PROTECTED]> wrote: > > On Sun, 2005-10-23 at 14:56 +0100, Stephen Colebourne wrote: > > > This looks interesting. I'll leave the pool comments to a pool > > > developer. However, could adding a lot more synchronoization could cause > > > other issues with locking and performance? > > > > probably. however, IMHO an object pool really needs to be thread safe. > > i've taken a quick look and think that perhaps it'd be better to fix any > > race conditions as the performance price that has to be paid for the > > design chosen. opinions? > > As Knuth put it "... premature optimization is the root of all evil". > And Jackson: > Rule 1. Don't do it > Rule 2. (for experts only). Don't do it yet - that is, not until you > have a perfectly clear and unoptimized solution. > > [From Bloch, Effective Java, Item 37] > > It's not only race conditions that might need to be fixed - > "Synchronization is required for reliable communication between > threads as well as for mutual exclusion." [Ibid, Item 48] > > He says that modern JVMs have much lower overheads for synchronisation > than the early releases, especially if the synchronisation is > uncontended, as would be the case for single-threaded access. > > So I'd suggest doing enough synch to ensure that the user can use all > the methods individually without needing to synchronise. Iterators > would likely still need external synch (except when running > single-threaded).
+1 BTW if any existing apache committers feel like helping out on any commons components then i'd be glad to propose karma - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
