On 10/16/2013 07:26 AM, Paul Sandoz wrote:
On Oct 16, 2013, at 12:28 PM, David Holmes <david.hol...@oracle.com> wrote:
On 16/10/2013 8:03 PM, Paul Sandoz wrote:
HashMap.compute*/merge methods do not throw CME either. I suppose those
methods could and do so beyond that of only the entry under computation.
I think this really points to the fact that, for non-traversal, only
concrete implementations are capable of reliably detecting a CME and
therefore it's best to leave it up to those implementations should they
choose to do so.
Perhaps HashMap's implementations should throw CME?
Perhaps, seems to be going beyond the call of duty. My inclination is not to
bother. It becomes most relevant with forEach since the consumer will have
side-effects that might make it easier to unintentionally slip in a
modification to the map itself.
But the possibility of CME has to be allowed for in the spec of the
interfaced methods regardless.
A variant of this issue came up a year or so ago for
JDK8 ConcurrentHashMap.compute*/merge: What happens if
the lambda side-effects by modifying some other
map element? Because CHM (sometimes) uses fine-grained
locks, it is possible for two such operations from
different threads could cause a deadlock. We put in
wording saying that the methods are allowed to throw
exceptions in this case (rather than deadlock) but
they currently don't catch all such errors. Which seems
analogous to the non-concurrent case, so maybe similar
wording could be used at Map level.
CHM:
* @throws IllegalStateException if the computation detectably
* attempts a recursive update to this map that would
* otherwise never complete
Map?
* @throws IllegalStateException if the computation detectably
* attempts a secondary update to this map that would
* otherwise never complete or perform an inconsistent update
-Doug
