On 04/11/2013 07:06 AM, David Holmes wrote:
I find the spec for these rather confusing from a concurrency
perspective - this non-concurrent interface seems to be trying to
say too much about how a concurrent interface should specify
behaviour. Why does it need to say:
* In concurrent contexts, the default implementation may retry
* these steps when multiple threads attempt updates.
For default on Map I am starting to think that throwing that CME
rather than looping is the right choice. The retry behaviour seems to
be counter the basic behaviour of non-concurrent implementations. The
retry behaviour will just hide usage that's otherwise unsafe when
used with non-concurrent implementations.
The concurrent implementations don't use these defaults so there's no
problem switching to throwing CME.
Opinions?
I had assumed the loops only existed because you wanted to use them as
ConcurrentMap defaults too! If that is not the case then these methods
should not loop/retry but just throw CME, in my opinion.
That's better, yes. But then new methods (not part of existing
ConcurrentMap API) should be overriden with defaults that do the looping
in ConcurrentMap interface. We still want those methods to behave
atomically in ConcurrentMaps that don't implement their own atomic variants.
Regards, Peter
Thanks,
David
