[concurrency-interest] Proper workaround for FutureTask.set()/get() race (CR 7132378)

Joe Bowbeer joe.bowbeer at gmail.com
Mon Apr 23 15:31:24 EDT 2012


The result in this case may be CancellationException, ExecutionException or
T.

I still prefer the simplicity of:

boolean set(v)
boolean setException(e)

Since the Future result never changes (unlike a Map), you can always get()
it if you want it.

--Joe

On Mon, Apr 23, 2012 at 12:17 PM, Roel Spilker wrote:

> Why not
>
> public T setIfNotSet(T val);
>
> And return the set value or null it it wasn't set. That would be more
> consistent with putIfAbsent.
>
> Actually, I would have preferred if putIfAbsent would either return the
> value already in there or its value from the parameter if it wasn't so I
> would have been able to write:
>
> return map.putIfAbsent(key, calculateValue());
>
> instead of
>
> T value = calculateValue();
> T val = map.putIfAbsent(key, value);
> return val != null ? val : value;
>
> Roel
>
>
> On 23-4-2012 20:22, Gregg Wonderly wrote:
>
>> If both patterns need to be supported, than make the API support both
>> literally.
>>
>> public boolean setIfNotSet( T val );
>> public void set( T val ) throws ValueAlreadySetException;
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120423/bdffc30e/attachment.html>


More information about the Concurrency-interest mailing list