[concurrency-interest] Proper workaround for FutureTask.set()/get() race (CR 7132378)
viktor.klang at gmail.com
Sun Apr 22 17:42:39 EDT 2012
On Sun, Apr 22, 2012 at 9:49 PM, Doug Lea <dl at cs.oswego.edu> wrote:
> On 04/22/12 11:18, Aleksey Shipilev wrote:
>> Sorry, but I fail to see the connection between FutureTask/ForkJoinTask
>> and proposed FutureValue. In my perspective you should not be able to
>> submit FutureValue anywhere, this is just the efficient shortcut for
>> asynchronously-settable value.
> Yes. I was commenting on adding operations like onResult, etc
> that invite usages requiring them be submittable to Executors.
Why would onResult/onException callbacks involve Executors?
Also, with defender methods you can simply have them throw an UOE.
Since j.u.c sort of sets the interop standard with regards to different
languages of the jvm, it would be nice to offer interop that doesn't
require sending worker threads to sleep.
> However, there are cases when I need to communicate single value between
>> two threads, with one thread blocked for the result. This is the case
>> where FutureValue comes handy. The cases like these are not as rare as
>> one might expect. :(
> Yes, I agree that this is (only) the functionality to target.
> P.S. I'm not allowed to look into Guava source code, but I will bet
>> their SettableFuture is done directly on AQS (it's the only sane option
>> at hand).
> (It is.)
> Concurrency-interest mailing list
> Concurrency-interest at cs.**oswego.edu <Concurrency-interest at cs.oswego.edu>
Akka Tech Lead
Typesafe <http://www.typesafe.com/> - The software stack for applications
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest