[concurrency-interest] generalise computeIfAbsent() for ConcurrentMap

Aleksey Shipilev aleksey.shipilev at gmail.com
Wed Jun 20 10:27:27 EDT 2012

I am puzzled now. Why wouldn't usual stub suffice as the default implementation?

    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?


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

More information about the Concurrency-interest mailing list