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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
