Re: Concurrency question?
On 1/31/2015 10:51 PM, Knute Johnson wrote:
On 01/31/2015 12:42 PM, Eric Sosman wrote:
On 1/31/2015 2:20 PM, Volker Borchert wrote:
Knute Johnson wrote:
So I have a Map<Integer,String> [ ... ]
Do you see any holes in my logic? Any suggestions?
java.util.concurrent.ConcurrentHashMap<K,V>
That's fine if the consistency criterion involves only single
mappings. But if different mappings within the same Map must "agree"
(in some application-dependent sense), atomicity of individual updates
isn't good enough.
Only Knute knows for sure ...
When I first saw Volker's suggestion I thought, no I can't iterate over
the map without some other synchronization but I looked into the
ConcurrentHashMap docs and found;
"Similarly, Iterators, Spliterators and Enumerations return elements
reflecting the state of the hash table at some point at or since the
creation of the iterator/enumeration. They do not throw
ConcurrentModificationException. However, iterators are designed to be
used by only one thread at a time."
As subtle as his suggestion was, I think he may be on to something. I'm
going to think about it some more but Volker may have the simplest
solution.
Hmmm: I still don't think the table's own consistency guarantees are
necessarily strong enough for every application. For example, consider
a situation where the map expresses a "symmetric" relation where keys
and values are of the same type, and if A -> B then also B -> A. It
takes two operations to create the two mappings, and if the updating
thread gets interrupted between the two the fact that the reader sees
a consistent-from-the-table's-viewpoint state may be of small comfort.
So, again: I think it's up to you to figure out what "consistency"
means for your application. If ConcurrentHashMap's properties provide
what you need, wonderful! (And I thank you and Volker for teaching me
that its properties extend further than I'd thought!) But it's not
hard to imagine circumstances that require stronger guarantees than
CHM provides. "Only Knute knows for sure ..."
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM