Are FastArrayList/FastHashMap broken (unthreadsafe)

[christopher marshall <ox...@hotmail.com>]

I have just been looking through the source code to the classes 
org.apache.commons.collections.FastHashMap and 
org.apache.commons.collections.FastArrayList - these classes seem totally 
broken to me because they are designed for use within a multi-threaded 
environment but are not threadsafe within the definition of the Java memory 
model.

I accept that presumably these classes have been pored over by minds 
superior to my own, but here is my reasoning:

Firstly, the internal "fast" boolean is not volatile, hence 2 separate 
Threads may be of a different opinion as to whether the Map/List is running 
in fast mode or not (If a primitive variable is non-volatile, the JVM is 
entirely free to read the value from Thread-local memory).

Secondly, even if 2 threads agree that the Map/List is running in fast mode, 
the Java memory model doesn't guarantee that non-synchronized changes will 
be visible across multiple Threads (because synchronization acts as a 
"main-memory barrier"). Since access to the Map/List via the get() method is 
not synchronized in fast mode, but will be to the put()/add() methods, it 
isn't clear that a Thread performing just reads will see changes an 
arbitrary amount of time after they have actually happened.

The version I have is Commons-Collections 2.0.

Thanks,

P.S. Apologies if this is directed at the wrong mailing list - this is my 
first contribution.

Chris Marshall

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Are FastArrayList/FastHashMap broken (unthreadsafe)

["Michael A. Smith" <ma...@apache.org>]

On Fri, 17 May 2002, christopher marshall wrote:
> I have just been looking through the source code to the classes 
> org.apache.commons.collections.FastHashMap and 
> org.apache.commons.collections.FastArrayList - these classes seem totally 
> broken to me because they are designed for use within a multi-threaded 
> environment but are not threadsafe within the definition of the Java memory 
> model.

They're not *totally* broken.  Just not really thread safe in highly 
optimized runtimes.  

> I accept that presumably these classes have been pored over by minds 
> superior to my own, but here is my reasoning:
>
> Firstly, the internal "fast" boolean is not volatile, hence 2 separate 
> Threads may be of a different opinion as to whether the Map/List is running 
> in fast mode or not (If a primitive variable is non-volatile, the JVM is 
> entirely free to read the value from Thread-local memory).

This is a known issue.  Even with the volatile keyword, it's not thread
safe.  See: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7924

> Secondly, even if 2 threads agree that the Map/List is running in fast mode, 
> the Java memory model doesn't guarantee that non-synchronized changes will 
> be visible across multiple Threads (because synchronization acts as a 
> "main-memory barrier"). Since access to the Map/List via the get() method is 
> not synchronized in fast mode, but will be to the put()/add() methods, it 
> isn't clear that a Thread performing just reads will see changes an 
> arbitrary amount of time after they have actually happened.

If you don't think the fix for bug 7924 will solve this issue, then file a 
separate bug for it.  

> P.S. Apologies if this is directed at the wrong mailing list - this is my 
> first contribution.

This is the right place...

regards,
michael



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>