Cool ... this looks like a much better solution to the problem that FastHashMap tried to solve. And I trust the implementors of this library a *heck* of a lot more than I trust myself (I wrote FastHashMap originally) to get all the nitpicky details right.
Craig On Mon, 20 Dec 2004 10:17:11 +1300, Jason Lea <[EMAIL PROTECTED]> wrote: > > Craig McClanahan wrote: > > >This is *exactly* where the problem lies. If one looks inside the > >implementation of HashMap, one sees that there are times when the > >internal data structures are being modified, and are in a potentially > >inconsistent state that would corrupt a read operation happening on a > >simultaneously executing thread. If you are accessing a HashMap with > >read and write operations on multiple threads, the only safe thing to > >do is lock all the reads, as well as all the writes. > > > > > If someone were to attempt a change, I imagine using something like > (http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/ConcurrentReaderHashMap.html) > ConcurrentReaderHashMap or ConcurrentHashMap would be good starting > point to avoid these locking problems. One problem would be dependency > (either using java.util.concurrent for J2SE 5.0 or > EDU.oswego.cs.dl.util.concurrent for earlier Java versions) > > -- > Jason Lea > > -- > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.296 / Virus Database: 265.6.0 - Release Date: 2004-12-17 > > -- > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.296 / Virus Database: 265.6.0 - Release Date: 2004.12.17 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
