[concurrency-interest] ConcurrentMap.replace

Doug Lea dl@cs.oswego.edu
Sat, 29 Nov 2003 19:41:37 -0500

There is now a two-argument version of ConcurrentMap.replace (aka
putIfPresent), that replaces a value only if key is already mapped.

> Not only is there a potential performance hit 

The delay on this was due to testing to make sure there is one (at
least in ConcurrentHashMap). In fact, performance of the "manual"
version in my last mail is almost indistinguishable from new built-in
version except when using key types with nontrivial hashCode
computations. Which makes it a marginal case, but still on the side of
including it.

> but there is
> also no guarantee of completion in a high contention scenario. 

(There's no guarantee you'll get a lock in a finite period of time
under high contention either. The performance profiles of the two
versions are basically the same.)

> An alternative idea is to provide access to the update Lock that is
> used for a particular key. 

We can't. We need the freedom to replace this implementation with, for
example, a lock-free version if/when we design or find one that
performs better than current implementation.