[concurrency-interest] generalise computeIfAbsent() for ConcurrentMap

Aleksey Shipilev aleksey.shipilev at gmail.com
Wed Jun 20 11:26:05 EDT 2012


Yes, I saw that coming. Continuing on my point, if computeIfAbsent()
ought to be the placeholder for the usual code people do around
putIfAbsent(), it seems to be presumed mapper function is side-effect
free. Would it help to require that for MappingFunction? What benefits
there are *not* requiring side-effect freedom for MappingFunction
(except for generality)?

-Aleksey.

On Wed, Jun 20, 2012 at 6:56 PM, Alex Lam S.L. <alexlamsl at gmail.com> wrote:
> (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
>
> _______________________________________________
> 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