commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: [POOL2] thread-safety issues
Date Tue, 13 Dec 2011 20:25:39 GMT
On 13/12/2011 19:12, sebb wrote:
> I've added some Javadoc to classes to indicate which ones are supposed
> to be thread-safe and which are not.
> 
> AFAICT, there remain 2 classes to be dealt with, ie
> 
> GenericKeyedObjectPool (GKOP)
> and
> GenericObjectPool (GOP)
> 
> GKOP is not currently thread-safe, as there are several mutable
> variables that aren't always accessed using synch.
> Adding volatile to these would fix the safe publication issue, but
> might not fix all thread-safety issues.
> This depends on how exactly the code uses the variables.
> If the code relies on the variable not changing between references,
> then the code is not thread-safe.
> 
> GOP is not thread-safe either, as the field evictionIterator is not volatile.
> Adding volatile would ensure safe publication, but the field is
> accessed multiple times - and may be reset to null.
> As far as I can tell, the evict() method is not thread-safe because of
> the way it changes the field.
> I suspect the code will need to use some synchronisation. Of course
> the same applies to GKOP.
> 
> Making all the configuration items final and removing the setters - as
> discussed previously - will make it much easier to make the classes
> thread-safe.
> I think that's the next stage.

-1. That makes use with DBCP and JNDI much, much harder.

Lets fix the thread safety issues, being careful to avoid adding syncs
unless we absolutely have to.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message