Parallel Programming: Task Cancellation

re: Parallel Programming: Task Cancellation

RockyLOMO — Fri, 03 May 2013 10:15:48 GMT

thx

re: Parallel Programming: Task Cancellation

westseyi — Sat, 26 Nov 2011 05:20:04 GMT

Thank you.

You freed me from all that multithreading, background work , UI locking, Passing Data to a Thread Horror !!!

Thank you.

re: Parallel Programming: Task Cancellation

Luca — Tue, 15 Nov 2011 23:29:33 GMT

@Alexandra Rusina

>> When i want to make a task to be long-running,

>> I have to pass the creation option to be long running,

>> but then the Taskscheduler is required,

>> then how do i pass the taskscheduler parameter?

> You can simply pass null, it should be OK.

Actually MSDN specifies that an ArgumentNullException "is thrown when the scheduler argument is null" and my tests confirm this.

You may want to use TaskScheduler.Current instead.

re: Parallel Programming: Task Cancellation

Terry — Fri, 14 Jan 2011 18:27:55 GMT

Add a Thread.Sleep into the iteration code with a duration of say 5 seconds. Then 1 second after the loop has began, close the form. The threads can't exit even though you diligently made such a request in the form_closing event as each thread is locked in the ''pretend long running 3rd party web-service call or library call' that (Thread.Sleep is supposed to represent this). The user thinks the app has closed, but it ain't. =/

Further, if the loop logic raises events and those events are subscribed to by the UI, in which the UI perhaps increments a progress-bar and event fired when the form is closed and long gone, the event would execute code that raises exceptions on deallocated form resources.

Said user is now baffled as an error and an application debug/shut down request dialogue appears from no where.... I think we need a thread abort construct adding to this new library, and the dev should handle resource deallocation etc within the Thread.Abort Exception catch they put in the iteration logic.

I hope MS don't expect me to implement my own TaskShedualer to do this.. I think they do.. oh dear time to get the sledge hammer out. =(

re: Parallel Programming: Task Cancellation

eisenpony — Wed, 08 Dec 2010 20:29:01 GMT

I understand the usefulness of throwing to cancel immediately out of a thread, but is using exceptions to control flow of a program considered best practice? It seems to me that if you are writing cooperateive cancellation, you should gracefully end the thread without throwing.

If you do use the ThrowIfCancellationRequested() method, and need to use it in a try block, how can you avoid catching it? is this acceptable?

try

{

tokenSource.Token.ThrowIfCancellationRequested();

result += Math.Exp(Math.Log(i) / root);

}

catch (System.OperationCanceledException)

{

throw;

}

catch (Exception e)

{

// Handle e

}

re: Parallel Programming: Task Cancellation

Berryl — Wed, 08 Dec 2010 20:19:38 GMT

@Nemo. I found myself adding the Token param also as I went through the code. Definite improvement

@@codesbad. I agree the initialization should not be done in the declaration by the final code iteration, but hey - it doesn't sour an otherwise *very* useful offering for this target audience, IMO. In fact I can't remember the last time I saw some meaty material from MS that was this well produced.

@Alexandra. Great job, will look for more of the same from you! Cheers

re: Parallel Programming: Task Cancellation

9rune5 — Thu, 25 Nov 2010 09:02:24 GMT

Before I can ask my colleagues to use this otherwise excellent article as a point of reference, the code is in need of some cleanup.

CancellationTokenSource tokenSource = new CancellationTokenSource();

// ....

tokenSource = new CancellationTokenSource();

Any reason why tokenSource is initialized in the declaration? That looks like a leftover from the previous version of this code. It is cleaner to test if tokenSource==null in cancel_Click() instead of making sure the object is always created.

Ordinarily I am all for "left as an exercise for the reader", but this is MS', what, third or fourth attempt at trying to lure regular developers to utilize some sort of threading library. IMO this requires absolute 100% top-notch quality code in all sample code and documentation.

re: Parallel Programming: Task Cancellation

Nemo1571 — Thu, 18 Nov 2010 08:21:36 GMT

The TokenSource and associated Token are fully thread-safe. You never pass the actual TokenSource to any other thread so the other threads simply call the thread-safe Token::ThrowIfCancellationRequested method directly.

Except I just noticed this IS using the TokenSource, something like below should be used instead:

public double SumRootN(int root, Token token)

{

double result = 0;

for (int i = 1; i < 10000000; i++)

{

token.ThrowIfCancellationRequested();

result += Math.Exp(Math.Log(i) / root);

}

return result;

}

var compute = Task.Factory.StartNew(() =>

{

return SumRootN(j, tokenSource.Token);

}, tokenSource.Token);

re: Parallel Programming: Task Cancellation

Axiom — Wed, 18 Aug 2010 07:25:18 GMT

Ok, i was wrong in the second case. My fault. Sorry.

But i still think that ACCESSING the field is not thread safe.

re: Parallel Programming: Task Cancellation

Alexandra Rusina — Tue, 17 Aug 2010 16:27:45 GMT

@Axiom

1. This article talks only about cancellation. The TPL handles synchronization and thread-safety itself in this case.

2. I am not updating a UI thread from background thread. I execute this task directly on the UI thread, this is what the task scheduler is for.