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. Then the code needs to be carefully examined to see how the remaining mutable fields are used in order to make the classes thread-safe. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
