[concurrency-interest] Concurrency-interest Digest, Vol 53, Issue 5

Cleber Muramoto cleber at nightcoders.com.br
Thu Jun 11 16:05:11 EDT 2009

> I would expect that one of the following scenarios to be true (for the
> contents of the map) after this code runs:
>    Map("first" -> true, "second" -> true)
>    Map("second" -> true)
>    Map()
> However, upon inspection of ConcurrentHashMap, it seems to me that the
> following scenario might also be true:
>    Map("first" -> true) ???
> This seems surprising because "first" gets put before "second", so if
> "second" is cleared, then surely "first" should be cleared too.
I think this may happen because clear acquires the locks individually, so it
first acquire the lock for the segment that would hold "first" before
"first" is put and the lock
for "second" after second is "put".

> If my interpretation of ConcurrentHashMap is correct, are there are other
> concurrent collections that provide such a "snapshot" view?
> Could ConcurrentHashMap be wrapped with a ReadWriteLock, where
> single-element operations (get, put, etc) acquire the read lock and
> whole-collections operations (map, filter, clear, etc) acquire the write
> lock? How badly would this hurt performance in the no-writers case?

Cliff's Click nonBlockingHashMap provides snapshot views.

Also, according to the doc it is "fully interoperable with
Hashtable", so you should either view Map() or Map("second" -> true).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090611/b9cfd113/attachment.html>

More information about the Concurrency-interest mailing list