BT

Replacing the ThreadPool with Tasks, Continuations, and Futures

by Jonathan Allen on Feb 04, 2009 |

With .NET 4.0 a new version of the thread pool will become available. In addition to performance and load balancing enhancements, this new thread pool allows you to use Tasks. A Task is a lightweight unit of work similar to what you create when you use ThreadPool.QueueUserWorkItem. But unlike the anonymous work item, Task objects expose a powerful API. You can access this API by capturing the return value from calls to the

Task.StartNew function. This function, like those for threads, accepts a delegate or anonymous function defining what work is to be performed.

Just like full threads, tasks expose a method allowing the scheduling thread to wait for the task’s completion. The methods are Wait, WaitAny, and WaitAll, the latter two accepting a list of tasks. Waits can be absolute or can have a maximum timeout.

With waits, the waiting thread is blocked. When blocking isn’t a good option, but you still want to perform an action when the current task(s) are complete, you can use continuations. A continuation in this context is a operation that is scheduled to be performed when the task or set of tasks are completed. To schedule a follow-up task, you can call the ContinueWith, ContinueWithAll, or ContinueWithAny function and pass it a delegate. This function can be called multiple times, effectively creating a pipeline of operations.

Cancellation is one area that .NET does not currently support very well. There is no way to remove unneeded tasks from the current thread pool and thread aborts are considered to be very dangerous. With .NET 4, cancellation of tasks becomes a first class citizen. When a task that has not been started is cancelled, it is removed from the queue immediately. If the task has begun, cooperation with the operation is needed. The delegate that actually performs the task’s work needs to periodically check the IsCancellationRequested property and respond appropriately.

Tasks have another feature not seen before in .NET, it supports parent-child relationships. This allows complex tasks to be broken into smaller parts but still be seen as a single logical operation. This offers significant advantages for supporting things such as cancellation. When a parent task is cancelled, child tasks are optionally cancelled as well.

Futures are tasks that execute a function asynchronously. When the result of the function is needed, the Future checks to see if the function has completed. A value is returned if it is done processing, what happens if it is not done depends on the implementation.

For example, Reading the Value property will cause the thread to block until the task is complete. Like other tasks, you have access to the IsCompleted property and the Wait, ContinueWith, and Cancel methods. This added functionality makes .NET futures more powerful than the textbook description and arguably not a future at all. For this reason, among others, .NET 4.0 futures have been renamed Task<T> where T is the return type.

It should be noted that Tasks in .NET are not constrained to thread-safe operations. There is nothing preventing, say a future that calculates a derivative, from also changing a global variable. This means normal locking and object ownership rules still apply, though of course these can be minimized by exclusively using immutable objects.

For more information on Tasks see Daniel Moths “Introducing the new Task type” and Stephen Toub‘s “Useful Abstractions Enabled with ContinueWith”.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Reminds me of the changes for Java 1.5 by Porter Woodward

Wow. I must say - that once I learned how to use Executors, and Futures in the new(er) Java concurrency package - multi-threaded programming became much more manageable. Obviously you still have synchronization issues around global state - but at least how many threads you have and what they are doing becomes more straight-forward.

Very good summary, thanks Jonathan. by Sadek Drobi

thanks

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT