In my application I have the need to continually process some piece(s) of Work
on some set interval(s). I had originally written a Task
to continually check a given Task.Delay
to see if it was completed, if so the Work
would be processed that corresponded to that Task.Delay
. The draw back to this method is the Task
that checks these Task.Delays
would be in a psuedo-infinite loop when no Task.Delay
is completed.
To solve this problem I found that I could create a "recursive Task
" (I am not sure what the jargon for this would be) that processes the work at the given interval as needed.
// New Recurring Work can be added by simply creating
// the Task below and adding an entry into this Dictionary.
// Recurring Work can be removed/stopped by looking
// it up in this Dictionary and calling its CTS.Cancel method.
private readonly object _LockRecurWork = new object();
private Dictionary<Work, Tuple<Task, CancellationTokenSource> RecurringWork { get; set; }
...
private Task CreateRecurringWorkTask(Work workToDo, CancellationTokenSource taskTokenSource)
{
return Task.Run(async () =>
{
// Do the Work, then wait the prescribed amount of time before doing it again
DoWork(workToDo);
await Task.Delay(workToDo.RecurRate, taskTokenSource.Token);
// If this Work's CancellationTokenSource is not
// cancelled then "schedule" the next Work execution
if (!taskTokenSource.IsCancellationRequested)
{
lock(_LockRecurWork)
{
RecurringWork[workToDo] = new Tuple<Task, CancellationTokenSource>
(CreateRecurringWorkTask(workToDo, taskTokenSource), taskTokenSource);
}
}
}, taskTokenSource.Token);
}
Should/Could this be represented with a chain of Task.ContinueWith
? Would there be any benefit to such an implementation? Is there anything majorly wrong with the current implementation?
Yes!
Calling
ContinueWith
tells theTask
to call your code as soon as it finishes. This is far faster than manually polling it.