[concurrency-interest] Fork and and timed get

Vitaly Davidovich 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
> contract.
>
> 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
> complete.
> 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!
>
> Thanks
> Romain
>
>
> 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   :
>>> FPJ.submit(task2)
>>>
>>> - Thread FJPO-1 : task1.fork
>>> As we are in the FJP it adds task1 into the workQueue of the current
>>> thread
>>> 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
>>> ignored.
>>>
>>> Is that the expected behavior ?
>>>
>>> Thanks
>>>
>>> Jonathan
>>>
>>> P.s in attachment a unit test that prints FAIL when the test fails
>>>
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>>>
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>
>
> --
> Romain Colle
> R&D Project Manager
> QuartetFS
> 2 rue Jean Lantier, 75001 Paris, France
> http://www.quartetfs.com
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20131127/d2536b72/attachment-0001.html>


More information about the Concurrency-interest mailing list