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]
