[concurrency-interest] Fork and and timed get
vitalyd at gmail.com
Wed Nov 27 20:40:57 EST 2013
So instead of timed get() is it possible to use async
continuations/callbacks? If enough time goes by without result being
available, calling thread just cancels and moves on. Otherwise, in cases
like this, I don't see how it can be solved at the FJ framework level
without ugly workarounds.
Sent from my phone
On Nov 27, 2013 11:17 AM, "Romain Colle" <rco at quartetfs.com> wrote:
> Hi all,
> I'd like to second Jonathan's post on this subject.
> The basic idea here is that, as far as I can tell, the get(long timeout,
> TimeUnit unit) method of a ForkJoinTask does not respect the Future
> Before blocking and waiting for the task to complete, the timed get()
> method tries to either steal and execute the task, or at least help it
> If it succeeds doing so, it will for instance execute the task that it is
> waiting for. And in this case, there is no telling how long it will take to
> execute it ...
> Although this is great for the overall throughput, a thread calling the
> timed get() method with a timeout of 1 second might end up returning a
> minute later (if the task does take a minute to execute).
> This is what Jonathan reproduced in its unit test (with a parallelism of 1
> in its pool to consistently reproduce this behavior).
> This behavior does causes some problems in our code, and to my knowledge
> there are no ways of invoking a reliable timed get() on a ForkJoinPool.
> Any feedback on this topic would be greatly appreciated!
> On Thu, Nov 21, 2013 at 8:35 AM, Martin Buchholz <martinrb at google.com>wrote:
>> Your message got ignored...
>> You created a pool with parallelism of 1, so it's not surprising that no
>> new thread was created to run action1. The action of the pool seems
>> reasonable to me - how would you do better?
>> Also, posting your code with a friendlier legal notice might help.
>> On Mon, Nov 18, 2013 at 8:35 AM, Jonathan Soto <jso at quartetfs.com> wrote:
>>> Hello everyone,
>>> It has been a few days I am thinking about this problem. Could you help
>>> me ?
>>> Suppose that we have two tasks
>>> - task1 waits for 5s
>>> - task2 forks task1 and does a timed get of 2.5 seconds
>>> The main thread submits task2 to a FJP.
>>> I observe the following behavior.
>>> - Thread Main :
>>> - Thread FJPO-1 : task1.fork
>>> As we are in the FJP it adds task1 into the workQueue of the current
>>> Task1 does not start in another thread
>>> - Thread FJPO-1 : task1.get(2.5, SECONDS)
>>> Starts by checking if the current thread has some local tasks to be
>>> done. As there is task1 that has been previously stored, we execute it.
>>> Task1 takes 5 seconds to be executed. The 2.5 seconds timeout is totally
>>> Is that the expected behavior ?
>>> P.s in attachment a unit test that prints FAIL when the test fails
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
> Romain Colle
> R&D Project Manager
> 2 rue Jean Lantier, 75001 Paris, France
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest