Waiting for a cancelled Future

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Waiting for a cancelled Future

Daniel Tetlow

Hi,

 

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,

 

Dan.

 


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Waiting for a cancelled Future

Vladimir Ozerov

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.

Vladimir.

21 апр. 2016 г. 15:09 пользователь "Daniel Tetlow" <[hidden email]> написал:

Hi,

 

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,

 

Dan.

 


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Waiting for a cancelled Future

Millies, Sebastian

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: [hidden email] [mailto:[hidden email]] On Behalf Of Vladimir Ozerov
Sent: Thursday, April 21, 2016 2:36 PM
To: Daniel Tetlow
Cc: [hidden email]
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.

Vladimir.

21 апр. 2016 г. 15:09 пользователь "Daniel Tetlow" <[hidden email]> написал:

Hi,

 

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,

 

Dan.

 


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


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


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Waiting for a cancelled Future

Viktor Klang

I prefer the model where execution control is separate from where the result may be obtained. Those are two orthogonal concerns, and with different access control (reading results vs writing the result)

--
Cheers,

On Apr 21, 2016 4:23 PM, "Millies, Sebastian" <[hidden email]> wrote:

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: [hidden email] [mailto:[hidden email]] On Behalf Of Vladimir Ozerov
Sent: Thursday, April 21, 2016 2:36 PM
To: Daniel Tetlow
Cc: [hidden email]
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.

Vladimir.

21 апр. 2016 г. 15:09 пользователь "Daniel Tetlow" <[hidden email]> написал:

Hi,

 

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,

 

Dan.

 


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


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


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest