[concurrency-interest] generalise computeIfAbsent() for ConcurrentMap

Rémi Forax forax at univ-mlv.fr
Wed Jun 20 10:04:51 EDT 2012


On 06/20/2012 03:49 PM, Doug Lea wrote:
> On 06/20/12 09:17, Alex Lam S.L. wrote:
>> Hi there,
>>
>> I am happily trying out the new computeIfAbsent() at the moment - it
>> saves a lot of headache for instance when I have to do an extra get()
>> before putIfAbsent() just because the potentially duplicated value
>> would create too much memory pressure.
>>
>> In same places however I do use the other ConcurrentMap
>> implementation, i.e. ConcurrentSkipListMap. I notice that
>> computeIfAbsent() is implemented explicitly for ConcurrentHashMap
>> instead; even the mapping functions are under ConcurrentHashMap
>> instead of the ConcurrentMap interface.
>>
>> Any reasons why this cannot be done for ConcurrentSkipListMap as well?
>> Or have I been doing something wrong altogether?
>>
>
> I was pretty sure something like this mail would come eventually :-)
>
> It's not too hard (easier than CHM) to implement this for
> ConcurrentSkipListMap (which is our only other j.u.c ConcurrentMap).
> This should and hopefully will be done before JDK8.
> But to cover this commonality at the level of interfaces, we'd
> need to introduce a new interface that extends ConcurrentMap.
> The thought of introducing an intrinsically-awkward-name
> just for the sake of two methods is not very appealing though.
> (BTW, upcoming jdk8 "defenders" will not help with this in covering
> other non-j.u.c ConcurrentMaps, since there is no conceivable
> default implementation.) So at the moment I'm thinking that
> having both our ConcurrentMaps support the computeifAbsent
> and recompute methods without adding interface is OK until we
> find some more compelling reason to add a new interface.

There is a possible default which is to throw an 
UnsupportedOperationException
saying that there is no default.

>
> -Doug

Rémi



More information about the Concurrency-interest mailing list