[concurrency-interest] ConcurrentMap.replace

Eric Zoerner eric.zoerner@gemstone.com
Fri, 05 Dec 2003 14:31:13 -0800


I was referring to the two-arg version of the replace method,

   boolean replace(K key, V newValue);

which replaces with the new value only if key exists, regardless of the oldValue 
  (and does not return the oldValue).


Joseph Bowbeer wrote:

> Eric Zoerner writes:
> 
> 
>>In any case, getting the old value at the time of replace is
>>impossible without race conditions unless the replace method
>>returns the old value.
> 
> 
> The old value is one of the parameters to the replace method, right?  So why
> doesn't the following work?
> 
>   if (replace(key, oldValue, newValue)) {
>     // do something with oldValue here
>   }
> 
> This does raise questions about whether the value replacement test is equals
> or ==; it is equals.
> 
> 
> ----- Original Message ----- 
> From: "Eric Zoerner" <eric.zoerner@gemstone.com>
> To: "Doug Lea" <dl@altair.cs.oswego.edu>
> Cc: <concurrency-interest@altair.cs.oswego.edu>
> Sent: Friday, December 05, 2003 10:38 AM
> Subject: Re: [concurrency-interest] ConcurrentMap.replace
> 
> 
> Actually, I do have a use case for the replace method to return the old
> value.
> In cache eviction, you need to replace an existing value with a NullObject,
> but
> you need the previous value, if there is one, in order to 1) know if it had
> been
> already evicted, in which case you might do nothing else; and 2) put the old
> value into an event object that is passed to a listener that is interested
> in
> the cache eviction and may want to know what the old value was. In any case,
> getting the old value at the time of replace is impossible without race
> conditions unless the replace method returns the old value.
> 
> Eric Zoerner wrote:
> 
>>Doug, thanks for adding the two-arg replace method, and I agree with
>>your analysis. However, I was expecting the two-arg replace method to
>>return the oldValue, not a boolean. I don't have a use case for why it
>>should return the oldValue, but it seems like it would provide more
>>information than a boolean. If the return value is null, then we know
>>the key didn't exist and the replace didn't happen (same as the current
>>return of false). Otherwise we get the object that was replaced, similar
>>to the return value from put and putIfAbsent. [Of course, if the Map
>>supports null values then there is ambiguity, but that is also true of
>>putIfAbsent].
>>
>>- Eric