Tasks and the Event-based Asynchronous Pattern

re: Tasks and the Event-based Asynchronous Pattern

Barry Kelly — Sat, 20 Jun 2009 03:27:00 GMT

You neatly demonstrate all the horribleness of the EAP style, when contrasted with the easier to use APM.

I must ask, though, how do you unsubscribe from the *Completed events using your helpers?

I was most frustrated when EAP turned up in .NET 2.0; EAP was chosen ahead of APM for web-service proxies, IIRC. APM was used in one of the earlier CTPs, and was a joy to use, but then EAP went into the RTM version and broke all my code. Demultiplexing stateful events invoked upon completion of stateless async method calls? Yuck.

re: Tasks and the Event-based Asynchronous Pattern

toub — Sat, 20 Jun 2009 03:36:58 GMT

Hi Barry-

Thanks for the comments. Regarding unsubscribing, the implementations in the Beta 1 samples (and the last example shown in the blog post itself) unregister from the *Completed event automatically when the operation completes. Are you looking to unregister prior to the operation completing? If so, there are a variety of solutions. One would be, prior to returning from the helper, to register a handler with the Task's CancellationToken such that when the Task has cancellation requested, it unregisters from the *Completed event and transitions the Task into the Canceled state.

I hope that helps.

re: Tasks and the Event-based Asynchronous Pattern

Aleksander Polak — Sat, 20 Jun 2009 18:12:25 GMT

This caught my attention:

if (e.Cancelled) tcs.TrySetCanceled();

Although English is not my native language, I believe the form "Canceled" should be used in both cases. (As far as I remember this was even mentioned in "Framework Design Guidelines".) At the very least the naming should be consistent. Yes, both forms can be found in the BCL today, but not within a single API.

Any plans to fix that before you ship the bits?

re: Tasks and the Event-based Asynchronous Pattern

Mike — Sun, 21 Jun 2009 01:36:42 GMT

I have the following Problem.

I have a few Validation Tasks. All of them get their Data from a "Linq to XML" Source. I am using "AsParrallel" for this Linq Ressource.

Now i want to run all these Task parrallel and i am interested only in the following:

- If all of this Taskes finish successful then move on.

- If one of this Tasks throw an Exception then immediatelly kill all other tasks and give back the exception of this task which has thrown it.

Is this Doable with the new Task Library.

re: Tasks and the Event-based Asynchronous Pattern

MichaelGG — Sun, 21 Jun 2009 07:20:33 GMT

I don't know if I'll ever understand why MS added the silly event async pattern :(. With APM we can easily define a generic wrapper for all sorts of methods, without needing detailed wiring up code.

re: Tasks and the Event-based Asynchronous Pattern

toub — Sun, 21 Jun 2009 20:31:01 GMT

Aleksander-

You're correct that Canceled (one L) is the right spelling to be used, per the latest Framework guidelines, and it's why the Task Parallel Library uses that spelling. The "e.Cancelled" you're seeing is not coming from TPL, it's coming from the AsyncCompletedEventArgs class which shipped as part of the .NET Framework 2.0 to support the Event-based Asynchronous Pattern (EAP). This post is simply showing how to take classes that implement the EAP pattern using that API, and get them to interoperate with Tasks.

Thanks for the suggestion, though.

re: Tasks and the Event-based Asynchronous Pattern

toub — Sun, 21 Jun 2009 20:37:39 GMT

Mike, you can certainly do this with tasks, taking advantage of ContinueWhenAll, ContinueWhenAny, and cancellation. You might also be able to achieve the same thing by extending your PLINQ solution to first iterate through all of the XML files, since PLINQ will try to stop executing a query as fast as possible when an exception is thrown from elsewhere in the query.

re: Tasks and the Event-based Asynchronous Pattern

toub — Sun, 21 Jun 2009 20:39:33 GMT

MichaelGG, thanks for the comment.

re: Tasks and the Event-based Asynchronous Pattern

Joe Albahari — Mon, 29 Jun 2009 12:19:25 GMT

What exactly was the design goal of the EAP? Was it simply to achieve parallel execution - or was it intended as a wrapper around APM?

re: Tasks and the Event-based Asynchronous Pattern

toub — Mon, 29 Jun 2009 17:44:44 GMT

EAP was designed to simplify one-off asynchronous operations that are initiated from and need to conclude on the UI thread (or, more generally, in some SynchronizationContext). With a type like WebClient, in a client app you can asynchronously download some data and handle the downloaded data on the UI thread. Or in ASP.NET, you can implement an async page that uses some asynchronously downloaded data, and again achieve that relatively easily using a type like WebClient that implements the EAP pattern. The pattern starts to lose steam, however, when you need to compose multiple asynchronous operations, or when you don't know at async operation launch time what you want to do with the result of the operation when it's complete, etc. In short, it can be quite useful for some scenarios, but puts up roadblocks for other more complicated ones.

In any event, the purpose of this blog post was to demonstrate how Tasks can be used to represent existing EAP implementations, just as Tasks can be used to represent existing APM implements.

re: Tasks and the Event-based Asynchronous Pattern

Charles Prakash Dasari — Fri, 31 Jul 2009 12:26:16 GMT

Though EAP was introduced for one-off async operations like you mentioned above, MSDN documentation goes far and beyond to recommend EAP over APM. I find APM more convenient than EAP particularly for the following reasons:

1) Exception handling

2) Explicit call to EndXXXX method

3) No multiple listeners business (in EAP you could have multiple listeners for the completion event. While this may be an interesting side-affect, it is still a potential candidate for bugs especially when the effect is not foreseen by the developer of the EAP functions than the one who consumes).

re: Tasks and the Event-based Asynchronous Pattern

holatom — Thu, 10 Dec 2009 08:47:54 GMT

I belive that there is a bug in the example above, in lines (final version of DownloadDataTask):

TransferCompletionToTask(tcs, e, () => e.Result);

webClient.DownloadDataCompleted -= handler;

because second line is executed even if

if (e.UserState == tcs)

(in TransferCompletionToTask) is false, that causes handler unregistration prior "right" DownloadDataCompleted is raised.

re: Tasks and the Event-based Asynchronous Pattern

toub — Thu, 10 Dec 2009 17:10:33 GMT

Great catch, holatom. You're correct. I'll fix the issue.