commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [pool] synchronization issues in Pool
Date Mon, 24 Oct 2005 20:21:37 GMT
On Sun, 2005-10-23 at 22:11 +0100, sebb wrote:
> On 23/10/05, robert burrell donkin <robertburrelldonkin@blueyonder.co.uk> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message