> > 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. Insofar as Java code is supposed to be cross-platform, the fact that the code isn't really thread safe in highly optimized runtimes really does mean it's totally broken. Furthermore, the code won't work in non-highly optimized runtimes either. The instructions that clone the internal collection and the instructions that store the reference to the clone can be done or percieved out-of-order because of optimizing compilers or processor pipelines. A thread invoking a read operation might raise all sorts of unexpected RuntimeExceptions because the clone() of a write operation hasn't finished yet. In theory this could happen even on single-processor JIT environments (though to be fair I've only ever tested the code on single-processor 386-based chips, where everything seems to work just fine). > ... > If you don't think the fix for bug 7924 will solve this issue, then file a > separate bug for it. It's a separate issue, and there should be a separate bug. However, there is no way to fix the bug: The Fast collection classes cannot behave as advertised and be cross-platform, given the current Java Memory Model. -Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
