Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news.swapon.de!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: Concurrency question? Date: Sun, 01 Feb 2015 09:24:12 -0500 Organization: A noiseless patient Spider Lines: 50 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sun, 1 Feb 2015 14:23:46 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="bd4e1cba8d8592bec5d5ed9e4537fbfd"; logging-data="3736"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19I7oPqJ4Y8tu6Mq3/j+MUU" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 In-Reply-To: Cancel-Lock: sha1:MUpdVnxBowP+HIUK8umxcXWlAFc= Xref: csiph.com comp.lang.java.programmer:30983 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 [ ... ] >>>> >>>> Do you see any holes in my logic? Any suggestions? >>> >>> java.util.concurrent.ConcurrentHashMap >> >> 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