System.Threading.Tasks

Published on , by Vincent Jacquet In Programming Tags #async

In essence, the classes in this namespace serve the same purpose as the IJob interface and the JobDispatcher classes.  But the implementation is quite different.

The classes involved are TaskScheduler, Task, Task<TResult>, TaskFactory and TaskFactory<TResult>. The only abstract class  is the TaskScheduler and it could be compared to the JobDispatcher. But the Task is merely a wrapper around an Action or a Func<TResult>, i.e. a wrapper around a function. There are two versions because you can have Task returning methods or not. Func<Void> is not allowed and could not be used as an alias of Action.

I do  not understand yet why there are two versions of the TaskFactory. Should not  generic methods be enough to create instances of Task<TResult>? Also, using a TaskFactory is not mandatory and both Task and TaskFactory have tons of methods to handle of possible cases of continuation.

Anyway, it looks like the main purpose of this namespace is to make it easy to refactor an existing class in order to use asynchronous programming or I'd rather say multiple processors. The IJob might be more difficult to use but it favors reusability. The Factory and the continuation gives me some ideas to improve the JobDispacther. For instance, the Factory could use dependency injection and the continuation could help linking Jobs together in a loosely coupled manner.

Leave a comment

Please note that we won't show your email to others, or use it for sending unwanted emails. We will only use it to render your Gravatar image and to validate you as a real person.