Along those lines, you might want to check out the backport of JSR 166
(java.util.concurrent):
http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent/
And perhaps specifically ConcurrentHashMap:
http://tinyurl.com/6c98r
Craig McClanahan wrote:
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
--
Kris Schneider <mailto:[EMAIL PROTECTED]>
D.O.Tech <http://www.dotech.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
