[concurrency-interest] question about ConcurrentHashMapV8.RemappingFunction

Kasper Nielsen kasperni at gmail.com
Fri Jun 29 09:14:56 EDT 2012

On Fri, Jun 29, 2012 at 2:36 PM, Doug Lea <dl at cs.oswego.edu> wrote:
> On 06/26/12 07:46, Doug Lea wrote:
>>> Was there any reason why the ConcurrentHashMapV8.RemappingFunction must
>>> return not-null when called from
>>> ConcurrentHashMapV8.compute(K,RemappingFunction) method?
>> There was some list discussion about this when CHMV8 was first
>> released. I don't have a strong opinion about it.
> On second thought...
>>> At the moment such algorithms would
>>> need to do compute(K, RemappingFunction) with the function returning a
>>> magic-value, then call remove(K, magic-value), which would lead to double
>>> hash-lookup and additional cost due to the two mutating operations
>>> instead
>>> of one in the success case for a remove race.
> ... avoiding the need for magic values and/or non-atomic rechecks is
> why we introduced the computeIfAbsent and recompute methods in the
> first place. Using null to indicate the lack of value
> (thus removal from the map if present) not only simplifies
> such user code but also maintains atomicity of the operation.

Are the various compute methods only going to be available on CHM?
I mean letting null indicate a removal (or something else) makes it
impossible to introduce them
later on any kind of maps that allow null values.


More information about the Concurrency-interest mailing list