Question

I currently have an application where I create a series of Tasks that execute one after the other, with a cancellation source that can interrupt execution between Tasks (i.e. at safe termination points.) I currently use this cancellation source only when the managing class is Disposed, as a way to cleanly and quickly abort execution.

I now have a use case where I’d like to create an automatic timeout to cancel the Task sequence, in case the operator doesn’t respond in a timely manner (some of the Tasks wait on operator interaction with a physical mechanism.) At the same time, I still need to support cancellation if the managing class is Disposed. I found CancellationTokenSource.CreateLinkedTokenSource, which sounds like what I need, but I have a few concerns:

1. Multiple Task-series can be executed in parallel, so I need to create a new CancellationTokenSource for timeout cancellation and an associated linked source for each Task-series that I begin. CancellationTokenSource implements IDisposable, which means that I need to persist both cancellation sources and Dispose them when the last Task completes or when any of the sub-Tasks is Cancelled or Faulted. This seems rather awkward, even with the helpful magic of anonymous method closures (still have these cancellation sources being passed around.)

2. I also need to protect against the condition where the cancellation sources are Disposed before the timer expires (so I don’t Cancel a Disposed source.) This is a potential race condition, so I need to add appropriate locking. This also seems awkward, adds significant complexity (future maintenance cost) and makes unit testing more challenging (race conditions are tricky to reliably induce.)

Am I heading down the correct path here or is there a simpler way to do this?

Answer 1

The core issue in your question seems to be relating to calling Dispose() on your Task and/or CancellationTokenSource objects. In this case, I would recommend just not calling Dispose on these, which should dramatically simplify your design.

As justification I’ll refer you to this thread. In particular, Stephen Toub (the PM in charge of Task) suggests that you should:

dispose aggressively if it’s easy and correct to do based on the structure of your code. If you start having to do strange gyrations in order to Dispose (or in the case of Tasks, use additional synchronization to ensure it’s safe to dispose, since Dispose may only be used once a task has completed), it’s likely better to rely on finalization to take care of things.

This sounds like the exact situation he’s describing at the end – you’re trying to do strange gyrations in order to call Dispose() on these objects.