[concurrency-interest] Fork and and timed get

Oleksandr Otenko oleksandr.otenko at oracle.com
Thu Nov 28 09:59:45 EST 2013


But what is that contract? "The timeout being observed no later than 
..."? I don't think you can implement that in a non-RT system (hence 
cannot rely on that in a non-RT system).

It does uphold the "non-performance is a failure" contract.

Compare: whereas you can devise a protocol where the server responds 
within N units of time, you will still want a socket timeout - you don't 
want to rely on the callee to always be in a position to enforce the 
condition (halting problem and all that).

Alex

On 27/11/2013 16:09, Romain Colle 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 
> <mailto: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
>     <mailto: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
>         <mailto:Concurrency-interest at cs.oswego.edu>
>         http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
>     _______________________________________________
>     Concurrency-interest mailing list
>     Concurrency-interest at cs.oswego.edu
>     <mailto: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 <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/20131128/b0c5aad7/attachment.html>


More information about the Concurrency-interest mailing list