[concurrency-interest] generalise computeIfAbsent() for ConcurrentMap

Alex Lam S.L. alexlamsl at gmail.com
Wed Jun 20 10:56:13 EDT 2012


(My earlier reply seems too cryptic, now that I read over it again.)

The implementation below would cause map() to be called even if a
value has been put into place after the initial get() but before
putIfAbsent(), which seems to contradict the behaviour from what I can
understand.


Alex.



On Wed, Jun 20, 2012 at 3:27 PM, Aleksey Shipilev
<aleksey.shipilev at gmail.com> wrote:
> I am puzzled now. Why wouldn't usual stub suffice as the default implementation?
>
>    @Override
>    public V computeIfAbsent(K key,
> ConcurrentHashMapV8.MappingFunction<? super K, ? extends V>
> mappingFunction) {
>        V v = get(key);
>        if (v == null) {
>            V newV = mappingFunction.map(key);
>            V oldV = putIfAbsent(key, newV);
>            v = (oldV == null) ? newV : oldV;
>        }
>        return v;
>    }
>
> Is this an incorrect defender?
>
> -Aleksey.
>
> On Wed, Jun 20, 2012 at 6:04 PM, Rémi Forax <forax at univ-mlv.fr> wrote:
>> 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
>>
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list