[concurrency-interest] Waiting for a cancelled Future

Millies, Sebastian Sebastian.Millies at softwareag.com
Thu Apr 21 10:13:50 EDT 2016

I agree with Vladimir. Cancel says you don’t care about the result, so why should one wait for a task to produce something one doesn’t need?
If a task cannot be cancelled gracefully, as you say, it should just refuse to be cancelled and do nothing in the cancel() method but return false.

However, in case you really want it, couldn’t you do the following? Submit a task for execution that would release a Semaphore when it is finished. Produce a second future from the original one that would try to acquire that same semaphore before completing. Calling get() on that second future would block while the cancelled task is still running. Both parts of this approach could be encapsulated in a single utility method.

n  Sebastian

From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Vladimir Ozerov
Sent: Thursday, April 21, 2016 2:36 PM
To: Daniel Tetlow
Cc: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] Waiting for a cancelled Future

Hi Dan,

This is an interesting question. Some frameworks which have their own "futures" has the same semantics as you described - they still wait for computation to complete. And both approaches could make sense.

However, future.get() is essentially about result, not about thread or computation state. When future is cancelled, result is known immediately, and there is no reason to block waiters any further. So immediate return makes perfect sense to me in this case.

21 апр. 2016 г. 15:09 пользователь "Daniel Tetlow" <daniel.tetlow at optasense.com<mailto:daniel.tetlow at optasense.com>> написал:

When I submit a task to one of the standard JDK ExecutorServices, I get a Future that represents the asynchronous execution of that task.

If I cancel the task before it gets executed, then of course Future.get() returns immediately as there is no asynchronous execution to wait for.

If I try to cancel the task while it is executing, what surprises me is that Future.get() still returns immediately even if the task is still actually running. So it appears that upon cancellation, the future becomes detached from the asynchronous execution state of the task. It may be that the task does not cancel gracefully, or that the task needs to do some cleanup on its cancellation path that takes time. In any case, if a task is executing by the time I cancel it, I’d still like to wait for it to finish before proceeding.

I have tried putting my own execution status on the actual Runnable/Callable that I submit to the executor, so I can check that separately. But this seems wrong to me because I end up duplicating status already known by the FutureTask, and this is likely also prone to race conditions.

How should I handle this, or am I doing something wrong to get into this state in the first place?

Thanks for your comments,


Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu<mailto:Concurrency-interest at cs.oswego.edu>

Software AG – Sitz/Registered office: Uhlandstraße 12, 64297 Darmstadt, Germany – Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Eric Duffaut, Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20160421/c2805f1e/attachment-0001.html>

More information about the Concurrency-interest mailing list