[concurrency-interest] ConcurrentHashMapV8 insertion/update methods

Doug Lea dl at cs.oswego.edu
Tue Aug 7 06:30:09 EDT 2012

On 08/07/12 06:07, Aleksey Shipilev wrote:
> On 08/07/2012 04:25 AM, Doug Lea wrote:
>> This hits all possible cases of atomically skipping,
>> writing a value, or apply a function when the key
>> is absent or present. In principle, all of these things
>> can be done solely with the "compute" method, but it would
>> often require the use of heavy functions that could tie up
>> mappings and lead to more contention, which we'd like to help
>> people avoid.
> Any specific example? Assuming returning null to compute means "no
> update", users will have to translate as follows:
 > ...

These all are in keeping with the idea behind computeIfAbsent,
that people can avoid applying a function while still
maintaining atomicity. In all cases, these functions
ought to be idempotent, but they may consume resources
and take enough time to execute to generate contention
bottlenecks. Plus, conversely, people can (and I'm sure will)
sometimes exploit the exclusion guarantee to apply
functions that would otherwise need some sort of locking.

While I'm at it though:

> * merge(k, v, f)
>    if absent, write v, else write results of f(currentValue, v)
> * (keyed) merge(k, v, f)
>    if absent, write v, else write results of f(k, currentValue, v)
> The last two can be thought of as embedded reductions, where
> the keyless-function version plugs into most reduction idioms, but
> the keyed-function is needed elsewhere.

The main case for the keyless version is that it allows
use with existing reducer functions that we expect people
will have around, especially if JDK8 supplies some
prepackaged ones, as planned. But this is not so for the keyed
version, which can be eliminated without hurting any expected
usages -- people can get the effect in other ways.


More information about the Concurrency-interest mailing list