Like most generic classes, I prefer to create Future instances through static factory methods which allows me to take maximum advantage of type inference. In addition to the 2 straight forward declaration of Func<T> and Action, the methods will include overloads which take in Func<T> with...

In addition to Future<T> there is also the concept of Futures that don't return any values.  Instead the perform the operation and return.  Because there is no additional data to pass between the threads building an Empty Future is fairly straight forward. The biggest decision is how...

The last post dealt with building the base Future class.  Now we'll build the child class used to run Func<TResult> 's.  The basic implementation is straight forward.  The class will run a delegate typed to Func<TResult> in the override of RunCore.  The trickiest part...

In the end there are two basic types of Future implementations you can use. Futures which return no values Futures which return a value The rest of the behavior and shape of the Future is the same and screams for a pattern of sorts.  I've found the best way to implement this behavior is through...

Besides waiting, the another important issue when dealing with Futures is how to deal with exceptions thrown by the user specified code.  Option 1: Ignore the Exception Don't take any actions in the future code and force users to write exception free code.  IMHO this is not the best way to...

Future's are a great abstraction for asynchronous programming. One of the items making them so good is the easy manner in which you can declare one and wait for it to finish. The idea is to allow for many futures to be declared with as little overhead as possible. In order to do so you need to define...

Herb Sutter gave one of my favorite and inspiring presentations.  It is called "The Free Lunch is Over".  The original article can be found here .  My first encounter though came from his PDC presentation and highly recommend viewing that as well. The part that interested me...