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).


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]

Reply via email to