[concurrency-interest] ConcurrentHashMapV8

Doug Lea dl at cs.oswego.edu
Tue Aug 30 07:13:24 EDT 2011

On 08/30/11 00:42, Zhong Yu wrote:
> The requirement that the computation must not write to entries of
> different keys seems especially hard to cope with. For example, if a
> map is used as a cache; when computing value for `k1`, it might be
> reasonable to disallow recursion on `k1`; however, it will be very odd
> and inconvenient to disallow `cache.get( k2, #{ load(k2) } )` when
> computing value for `k1`.

Yes. As I mentioned in other replies, a version suitable for
arbitrary caches should be based on an internal form of Futures
that can deal with reservations/place-holders. But this
(as well as accommodating weak references etc) would
add a lot of overhead and code bulk to operations for all
other CHM usages. So stay tuned for a version supporting such things.

> Requiring that the computation is transparent to the caller, must be
> inexpensive and must not write to the map, will turn away majority of
> potential users.

That's all for the best. The main problem computeIfAbsent
addresses is people often getting wrong the alternative
(and still usually best) idiom of:
if (map.get(k) == null)
    map.putIfAbsent(k, new V(k));
Even though it introduces potential contention (no free lunch),
with lambda syntax support, computeIfAbsent will be less
error-prone. As in, something like:
   map.computeIfAbsent(k, #{k -> new V(k)} };

In other words, the use of locks in CHMV8 is just an internal
implementation detail that may change at any time (although
as indicated in other postings, is not too likely to change).
Even without them, any support for computeIfAbsent introduces
contention etc, so users should keep the functions short.


More information about the Concurrency-interest mailing list