RFR: 8004518 & 8010122 : Default methods on Map

[Peter Levart]

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