However, as I mentioned in Part 1, Task Decomposition tends to be a bit more difficult than data decomposition, and can require a bit more effort.  Before we being parallelizing our algorithm based on the tasks being performed, we need to decompose our problem, and take special care of certain considerations such as ordering and grouping of tasks.

Up to this point in this series, I’ve focused on parallelization techniques which are most appropriate when a problem space can be decomposed by data.  Using PLINQ and the Parallel class, I’ve shown how problem spaces where there is a collection of data, and each element needs to be processed, can potentially be parallelized.

However, there are many other routines where this is not appropriate.  Often, instead of working on a collection of data, there is a single piece of data which must be processed using an algorithm or series of algorithms.  Here, there is no collection of data, but there may still be opportunities for parallelism.

As I mentioned before, in cases like this, the approach is to look at your overall routine, and decompose your problem space based on tasks.  The idea here is to look for discrete “tasks,” individual pieces of work which can be conceptually thought of as a single operation.

Let’s revisit the example I used in Part 1, an application startup path.  Say we want our program, at startup, to do a bunch of individual actions, or “tasks”.  The following is our list of duties we must perform right at startup:

• Display a splash screen
• Request a license from our license manager
• Check for an update to the software from our web server
• If an update is available, download it
• Setup our menu structure based on our current license
• Open and display our main, welcome Window
• Hide the splash screen

The first step in Task Decomposition is breaking up the problem space into discrete tasks.

This, naturally, can be abstracted as seven discrete tasks.  In the serial version of our program, if we were to diagram this, the general process would appear as:

These tasks, obviously, provide some opportunities for parallelism.  Before we can parallelize this routine, we need to analyze these tasks, and find any dependencies between tasks.  In this case, our dependencies include:

• The splash screen must be displayed first, and as quickly as possible.
• We can’t download an update before we see whether one exists.
• Our menu structure depends on our license, so we must check for the license before setting up the menus.
• Since our welcome screen will notify the user of an update, we can’t show it until we’ve downloaded the update.
• Since our welcome screen includes menus that are customized based off the licensing, we can’t display it until we’ve received a license.
• We can’t hide the splash until our welcome screen is displayed.

By listing our dependencies, we start to see the natural ordering that must occur for the tasks to be processed correctly.

The second step in Task Decomposition is determining the dependencies between tasks, and ordering tasks based on their dependencies.

Looking at these tasks, and looking at all the dependencies, we quickly see that even a simple decomposition such as this one can get quite complicated.  In order to simplify the problem of defining the dependencies, it’s often a useful practice to group our tasks into larger, discrete tasks.  The goal when grouping tasks is that you want to make each task “group” have as few dependencies as possible to other tasks or groups, and then work out the dependencies within that group.  Typically, this works best when any external dependency is based on the “last” task within the group when it’s ordered, although that is not a firm requirement.  This process is often called Grouping Tasks.  In our case, we can easily group together tasks, effectively turning this into four discrete task groups:

1. Show our splash screen –

This needs to be left as its own task.  First, multiple things depend on this task, mainly because we want this to start before any other action, and start as quickly as possible.

2. Check for Update and Download the Update if it Exists -

These two tasks logically group together.  We know we only download an update if the update exists, so that naturally follows.  This task has one dependency as an input, and other tasks only rely on the final task within this group.

3. Request a License, and then Setup the Menus –

Here, we can group these two tasks together.  Although we mentioned that our welcome screen depends on the license returned, it also depends on setting up the menu, which is the final task here.  Setting up our menus cannot happen until after our license is requested.  By grouping these together, we further reduce our problem space.

4. Display welcome and hide splash -

Finally, we can display our welcome window and hide our splash screen.  This task group depends on all three previous task groups – it cannot happen until all three of the previous groups have completed.

By grouping the tasks together, we reduce our problem space, and can naturally see a pattern for how this process can be parallelized.  The diagram below shows one approach:

The orange boxes show each task group, with each task represented within.  We can, now, effectively take these tasks, and run a large portion of this process in parallel, including the portions which may be the most time consuming.  We’ve now created two parallel paths which our process execution can follow, hopefully speeding up the application startup time dramatically.

The main point to remember here is that, when decomposing your problem space by tasks, you need to:

• Define each discrete action as an individual Task
• Discover dependencies between your tasks
• Group tasks based on their dependencies
• Order the tasks and groups of tasks

Recursive algorithms, especially ones based on a form of divide and conquer, are often a very good candidate for parallelization.

This is apparent from a common sense standpoint.  Since we’re dividing up the total work in the algorithm, we have an obvious, built-in partitioning scheme.  Once partitioned, the data can be worked upon independently, so there is good, clean isolation of data.

Implementing this type of algorithm is fairly simple.  The Parallel class in .NET 4 includes a method suited for this type of operation: Parallel.Invoke.  This method works by taking any number of delegates defined as an Action, and operating them all in parallel.  The method returns when every delegate has completed:

Parallel.Invoke(
    () =>
        {
            Console.WriteLine("Action 1 executing in thread {0}",
                                                 Thread.CurrentThread.ManagedThreadId);
        },
    () =>
        {
            Console.WriteLine("Action 2 executing in thread {0}",
                                                 Thread.CurrentThread.ManagedThreadId);
        },
    () =>
        {
            Console.WriteLine("Action 3 executing in thread {0}",
                                                 Thread.CurrentThread.ManagedThreadId);
        }
    );

Running this simple example demonstrates the ease of using this method.  For example, on my system, I get three separate thread IDs when running the above code.  By allowing any number of delegates to be executed directly, concurrently, the Parallel.Invoke method provides us an easy way to parallelize any algorithm based on divide and conquer.  We can divide our work in each step, and execute each task in parallel, recursively.

For example, suppose we wanted to implement our own quicksort routine.  The quicksort algorithm can be designed based on divide and conquer.  In each iteration, we pick a pivot point, and use that to partition the total array.  We swap the elements around the pivot, then recursively sort the lists on each side of the pivot. 

For example, let’s look at this simple, sequential implementation of quicksort:

public static void QuickSort<T>(T[] array) where T : IComparable<T>
{
    QuickSortInternal(array, 0, array.Length - 1);
}

private static void QuickSortInternal<T>(T[] array, int left, int right)
    where T : IComparable<T>
{
    if (left >= right)
    {
        return;
    }

    SwapElements(array, left, (left + right) / 2);
    int last = left;
    for (int current = left + 1; current <= right; ++current)
    {
        if (array[current].CompareTo(array[left]) < 0)
        {
            ++last;
            SwapElements(array, last, current);
        }
    }

    SwapElements(array, left, last);

    QuickSortInternal(array, left, last - 1);
    QuickSortInternal(array, last + 1, right);
}

static void SwapElements<T>(T[] array, int i, int j)
{
    T temp = array[i];
    array[i] = array[j];
    array[j] = temp;
}

Here, we implement the quicksort algorithm in a very common, divide and conquer approach.  Running this against the built-in Array.Sort routine shows that we get the exact same answers (although the framework’s sort routine is slightly faster).  On my system, for example, I can use framework’s sort to sort ten million random doubles in about 7.3s, and this implementation takes about 9.3s on average.

Looking at this routine, though, there is a clear opportunity to parallelize.  At the end of QuickSortInternal, we recursively call into QuickSortInternal with each partition of the array after the pivot is chosen.  This can be rewritten to use Parallel.Invoke by simply changing it to:

    // Code above is unchanged...
    SwapElements(array, left, last);

    Parallel.Invoke(
        () => QuickSortInternal(array, left, last - 1),
        () => QuickSortInternal(array, last + 1, right)
    );
}

This routine will now run in parallel.  When executing, we now see the CPU usage across all cores spike while it executes. 

However, there is a significant problem here – by parallelizing this routine, we took it from an execution time of 9.3s to an execution time of approximately 14 seconds!  We’re using more resources as seen in the CPU usage, but the overall result is a dramatic slowdown in overall processing time.

This occurs because parallelization adds overhead.  Each time we split this array, we spawn two new tasks to parallelize this algorithm!  This is far, far too many tasks for our cores to operate upon at a single time.  In effect, we’re “over-parallelizing” this routine.  This is a common problem when working with divide and conquer algorithms, and leads to an important observation:

When parallelizing a recursive routine, take special care not to add more tasks than necessary to fully utilize your system.

This can be done with a few different approaches, in this case.  Typically, the way to handle this is to stop parallelizing the routine at a certain point, and revert back to the serial approach.  Since the first few recursions will all still be parallelized, our “deeper” recursive tasks will be running in parallel, and can take full advantage of the machine.  This also dramatically reduces the overhead added by parallelizing, since we’re only adding overhead for the first few recursive calls. 

There are two basic approaches we can take here.  The first approach would be to look at the total work size, and if it’s smaller than a specific threshold, revert to our serial implementation.  In this case, we could just check right-left, and if it’s under a threshold, call the methods directly instead of using Parallel.Invoke.

The second approach is to track how “deep” in the “tree” we are currently at, and if we are below some number of levels, stop parallelizing.  This approach is a more general-purpose approach, since it works on routines which parse trees as well as routines working off of a single array, but may not work as well if a poor partitioning strategy is chosen or the tree is not balanced evenly.

This can be written very easily.  If we pass a maxDepth parameter into our internal routine, we can restrict the amount of times we parallelize by changing the recursive call to:

// Code above is unchanged...
SwapElements(array, left, last);

if (maxDepth < 1)
{
    QuickSortInternal(array, left, last - 1, maxDepth);
    QuickSortInternal(array, last + 1, right, maxDepth);
}
else
{
    --maxDepth;
    Parallel.Invoke(
        () => QuickSortInternal(array, left, last - 1, maxDepth),
        () => QuickSortInternal(array, last + 1, right, maxDepth));
}

We no longer allow this to parallelize indefinitely – only to a specific depth, at which time we revert to a serial implementation.  By starting the routine with a maxDepth equal to Environment.ProcessorCount, we can restrict the total amount of parallel operations significantly, but still provide adequate work for each processing core.

With this final change, my timings are much better.  On average, I get the following timings:

• Framework via Array.Sort: 7.3 seconds
• Serial Quicksort Implementation: 9.3 seconds
• Naive Parallel Implementation: 14 seconds
• Parallel Implementation Restricting Depth: 4.7 seconds

Finally, we are now faster than the framework’s Array.Sort implementation.

Cancellation in .NET 4 is based around a new, lightweight struct called CancellationToken.  A CancellationToken is a small, thread-safe value type which is generated via a CancellationTokenSource.  There are many goals which led to this design.  For our purposes, we will focus on a couple of specific design decisions:

• Cancellation is cooperative.  A calling method can request a cancellation, but it’s up to the processing routine to terminate – it is not forced.
• Cancellation is consistent.  A single method call requests a cancellation on every copied CancellationToken in the routine.

Let’s begin by looking at how we can cancel a PLINQ query.  Supposed we wanted to provide the option to cancel our query from Part 6:

double min = collection
                .AsParallel()
                .Min(item => item.PerformComputation());

We would rewrite this to allow for cancellation by adding a call to ParallelEnumerable.WithCancellation as follows:

var cts = new CancellationTokenSource();

// Pass cts here to a routine that could, 
// in parallel, request a cancellation

try
{
    double min = collection
                    .AsParallel()
                    .WithCancellation(cts.Token)
                    .Min(item => item.PerformComputation());
}
catch (OperationCanceledException e)
{
    // Query was cancelled before it finished
}

Here, if the user calls cts.Cancel() before the PLINQ query completes, the query will stop processing, and an OperationCanceledException will be raised. 

Be aware, however, that cancellation will not be instantaneous.  When cts.Cancel() is called, the query will only stop after the current item.PerformComputation() elements all finish processing.  cts.Cancel() will prevent PLINQ from scheduling a new task for a new element, but will not stop items which are currently being processed.  This goes back to the first goal I mentioned – Cancellation is cooperative.  Here, we’re requesting the cancellation, but it’s up to PLINQ to terminate.

If we wanted to allow cancellation to occur within our routine, we would need to change our routine to accept a CancellationToken, and modify it to handle this specific case:

public void PerformComputation(CancellationToken token)
{
    for (int i=0; i<this.iterations; ++i)
    {
        // Add a check to see if we've been canceled
        // If a cancel was requested, we'll throw here
        token.ThrowIfCancellationRequested();

        // Do our processing now
        this.RunIteration(i);
    }
}

With this overload of PerformComputation, each internal iteration checks to see if a cancellation request was made, and will throw an OperationCanceledException at that point, instead of waiting until the method returns.  This is good, since it allows us, as developers, to plan for cancellation, and terminate our routine in a clean, safe state.

This is handled by changing our PLINQ query to:

try
{
    double min = collection
                    .AsParallel()
                    .WithCancellation(cts.Token)
                    .Min(item => item.PerformComputation(cts.Token));
}
catch (OperationCanceledException e)
{
    // Query was cancelled before it finished
}

PLINQ is very good about handling this exception, as well.  There is a very good chance that multiple items will raise this exception, since the entire purpose of PLINQ is to have multiple items be processed concurrently.  PLINQ will take all of the OperationCanceledException instances raised within these methods, and merge them into a single OperationCanceledException in the call stack.  This is done internally because we added the call to ParallelEnumerable.WithCancellation.

If, however, a different exception is raised by any of the elements, the OperationCanceledException as well as the other Exception will be merged into a single AggregateException.

The Task Parallel Library uses the same cancellation model, as well.  Here, we supply our CancellationToken as part of the configuration.  The ParallelOptions class contains a property for the CancellationToken.  This allows us to cancel a Parallel.For or Parallel.ForEach routine in a very similar manner to our PLINQ query.  As an example, we could rewrite our Parallel.ForEach loop from Part 2 to support cancellation by changing it to:

try
{
    var cts = new CancellationTokenSource();
    var options = new ParallelOptions()
                      {
                          CancellationToken = cts.Token
                      };
    Parallel.ForEach(customers, options, customer =>
    {
        // Run some process that takes some time...
        DateTime lastContact = theStore.GetLastContact(customer);
        TimeSpan timeSinceContact = DateTime.Now - lastContact;

        // Check for cancellation here
        options.CancellationToken.ThrowIfCancellationRequested();

        // If it's been more than two weeks, send an email, and update...
        if (timeSinceContact.Days > 14)
        {
           theStore.EmailCustomer(customer);
           customer.LastEmailContact = DateTime.Now;
        }
    });
}
catch (OperationCanceledException e)
{
    // The loop was cancelled
}

Notice that here we use the same approach taken in PLINQ.  The Task Parallel Library will automatically handle our cancellation in the same manner as PLINQ, providing a clean, unified model for cancellation of any parallel routine.  The TPL performs the same aggregation of the cancellation exceptions as PLINQ, as well, which is why a single exception handler for OperationCanceledException will cleanly handle this scenario.  This works because we’re using the same CancellationToken provided in the ParallelOptions.  If a different exception was thrown by one thread, or a CancellationToken from a different CancellationTokenSource was used to raise our exception, we would instead receive all of our individual exceptions merged into one AggregateException.

When working with Data Parallelism, there is one primary configuration option we often need to control – the number of threads we want the system to use when parallelizing our routine.  By default, PLINQ and the TPL both use the ThreadPool to schedule tasks.  Given the major improvements in the ThreadPool in CLR 4, this default behavior is often ideal. 

However, there are times that the default behavior is not appropriate.  For example, if you are working on multiple threads simultaneously, and want to schedule parallel operations from within both threads, you might want to consider restricting each parallel operation to using a subset of the processing cores of the system.  Not doing this might over-parallelize your routine, which leads to inefficiencies from having too many context switches.

In the Task Parallel Library, configuration is handled via the ParallelOptions class.  All of the methods of the Parallel class have an overload which accepts a ParallelOptions argument.

We configure the Parallel class by setting the ParallelOptions.MaxDegreeOfParallelism property.  For example, let’s revisit one of the simple data parallel examples from Part 2:

Parallel.For(0, pixelData.GetUpperBound(0), row =>
{
    for (int col=0; col < pixelData.GetUpperBound(1); ++col)
    {
        pixelData[row, col] = AdjustContrast(pixelData[row, col], minPixel, maxPixel);
    }
});

Here, we’re looping through an image, and calling a method on each pixel in the image.  If this was being done on a separate thread, and we knew another thread within our system was going to be doing a similar operation, we likely would want to restrict this to using half of the cores on the system.  This could be accomplished easily by doing:

var options = new ParallelOptions();
options.MaxDegreeOfParallelism = Math.Max(Environment.ProcessorCount / 2, 1);

Parallel.For(0, pixelData.GetUpperBound(0), options, row =>
{
    for (int col=0; col < pixelData.GetUpperBound(1); ++col)
    {
        pixelData[row, col] = AdjustContrast(pixelData[row, col], minPixel, maxPixel);
    }
});

Now, we’re restricting this routine to using no more than half the cores in our system.  Note that I included a check to prevent a single core system from supplying zero; without this check, we’d potentially cause an exception.  I also did not hard code a specific value for the MaxDegreeOfParallelism property.  One of our goals when parallelizing a routine is allowing it to scale on better hardware.  Specifying a hard-coded value would contradict that goal.

Parallel LINQ also supports configuration, and in fact, has quite a few more options for configuring the system.  The main configuration option we most often need is the same as our TPL option: we need to supply the maximum number of processing threads.  In PLINQ, this is done via a new extension method on ParallelQuery<T>: ParallelEnumerable.WithDegreeOfParallelism.

Let’s revisit our declarative data parallelism sample from Part 6:

double min = collection.AsParallel().Min(item => item.PerformComputation());

Here, we’re performing a computation on each element in the collection, and saving the minimum value of this operation.  If we wanted to restrict this to a limited number of threads, we would add our new extension method:

int maxThreads = Math.Max(Environment.ProcessorCount / 2, 1);
double min = collection
                 .AsParallel()
                 .WithDegreeOfParallelism(maxThreads)
                 .Min(item => item.PerformComputation());

This automatically restricts the PLINQ query to half of the threads on the system.

PLINQ provides some additional configuration options.  By default, PLINQ will occasionally revert to processing a query in parallel.  This occurs because many queries, if parallelized, typically actually cause an overall slowdown compared to a serial processing equivalent.  By analyzing the “shape” of the query, PLINQ often decides to run a query serially instead of in parallel.  This can occur for (taken from MSDN):

• Queries that contain a Select, indexed Where, indexed SelectMany, or ElementAt clause after an ordering or filtering operator that has removed or rearranged original indices.
• Queries that contain a Take, TakeWhile, Skip, SkipWhile operator and where indices in the source sequence are not in the original order.
• Queries that contain Zip or SequenceEquals, unless one of the data sources has an originally ordered index and the other data source is indexable (i.e. an array or IList(T)).
• Queries that contain Concat, unless it is applied to indexable data sources.
• Queries that contain Reverse, unless applied to an indexable data source.

If the specific query follows these rules, PLINQ will run the query on a single thread.  However, none of these rules look at the specific work being done in the delegates, only at the “shape” of the query.  There are cases where running in parallel may still be beneficial, even if the shape is one where it typically parallelizes poorly.  In these cases, you can override the default behavior by using the WithExecutionMode extension method.  This would be done like so:

var reversed = collection
                  .AsParallel()
                  .WithExecutionMode(ParallelExecutionMode.ForceParallelism)
                  .Select(i => i.PerformComputation())
                  .Reverse();

Here, the default behavior would be to not parallelize the query unless collection implemented IList<T>.  We can force this to run in parallel by adding the WithExecutionMode extension method in the method chain.

Finally, PLINQ has the ability to configure how results are returned.  When a query is filtering or selecting an input collection, the results will need to be streamed back into a single IEnumerable<T> result.  For example, the method above returns a new, reversed collection.  In this case, the processing of the collection will be done in parallel, but the results need to be streamed back to the caller serially, so they can be enumerated on a single thread.

This streaming introduces overhead.  IEnumerable<T> isn’t designed with thread safety in mind, so the system needs to handle merging the parallel processes back into a single stream, which introduces synchronization issues.  There are two extremes of how this could be accomplished, but both extremes have disadvantages.

The system could watch each thread, and whenever a thread produces a result, take that result and send it back to the caller.  This would mean that the calling thread would have access to the data as soon as data is available, which is the benefit of this approach.  However, it also means that every item is introducing synchronization overhead, since each item needs to be merged individually.

On the other extreme, the system could wait until all of the results from all of the threads were ready, then push all of the results back to the calling thread in one shot.  The advantage here is that the least amount of synchronization is added to the system, which means the query will, on a whole, run the fastest.  However, the calling thread will have to wait for all elements to be processed, so this could introduce a long delay between when a parallel query begins and when results are returned.

The default behavior in PLINQ is actually between these two extremes.  By default, PLINQ maintains an internal buffer, and chooses an optimal buffer size to maintain.  Query results are accumulated into the buffer, then returned in the IEnumerable<T> result in chunks.  This provides reasonably fast access to the results, as well as good overall throughput, in most scenarios.

However, if we know the nature of our algorithm, we may decide we would prefer one of the other extremes.  This can be done by using the WithMergeOptions extension method.  For example, if we know that our PerformComputation() routine is very slow, but also variable in runtime, we may want to retrieve results as they are available, with no bufferring.  This can be done by changing our above routine to:

var reversed = collection
                  .AsParallel()
                  .WithExecutionMode(ParallelExecutionMode.ForceParallelism)
                  .WithMergeOptions(ParallelMergeOptions.NotBuffered)
                  .Select(i => i.PerformComputation())
                  .Reverse();

On the other hand, if are already on a background thread, and we want to allow the system to maximize its speed, we might want to allow the system to fully buffer the results:

var reversed = collection
                  .AsParallel()
                  .WithExecutionMode(ParallelExecutionMode.ForceParallelism)
                  .WithMergeOptions(ParallelMergeOptions.FullyBuffered)
                  .Select(i => i.PerformComputation())
                  .Reverse();

Notice, also, that you can specify multiple configuration options in a parallel query.  By chaining these extension methods together, we generate a query that will always run in parallel, and will always complete before making the results available in our IEnumerable<T>.

PLINQ adds a new method unavailable in standard LINQ which provides new functionality…

LINQ is designed to provide a much simpler way of handling querying, including filtering, ordering, grouping, and many other benefits.  Reading the description in LINQ to Objects on MSDN, it becomes clear that the thinking behind LINQ deals with retrieval of data.  LINQ works by adding a functional programming style on top of .NET, allowing us to express filters in terms of predicate functions, for example.

PLINQ is, generally, very similar.  Typically, when using PLINQ, we write declarative statements to filter a dataset or perform an aggregation.  However, PLINQ adds one new method, which provides a very different purpose: ForAll.

The ForAll method is defined on ParallelEnumerable, and will work upon any ParallelQuery<T>.  Unlike the sequence operators in LINQ and PLINQ, ForAll is intended to cause side effects.  It does not filter a collection, but rather invokes an action on each element of the collection.

At first glance, this seems like a bad idea.  For example, Eric Lippert clearly explained two philosophical objections to providing an IEnumerable<T>.ForEach extension method, one of which still applies when parallelized.  The sole purpose of this method is to cause side effects, and as such, I agree that the ForAll method “violates the functional programming principles that all the other sequence operators are based upon”, in exactly the same manner an IEnumerable<T>.ForEach extension method would violate these principles.  Eric Lippert’s second reason for disliking a ForEach extension method does not necessarily apply to ForAll – replacing ForAll with a call to Parallel.ForEach has the same closure semantics, so there is no loss there.

Although ForAll may have philosophical issues, there is a pragmatic reason to include this method.  Without ForAll, we would take a fairly serious performance hit in many situations.  Often, we need to perform some filtering or grouping, then perform an action using the results of our filter. 

Using a standard foreach statement to perform our action would avoid this philosophical issue:

// Filter our collection
var filteredItems = collection.AsParallel().Where( i => i.SomePredicate() );

// Now perform an action
foreach (var item in filteredItems)
{
    // These will now run serially
    item.DoSomething();
}

This would cause a loss in performance, since we lose any parallelism in place, and cause all of our actions to be run serially.

We could easily use a Parallel.ForEach instead, which adds parallelism to the actions:

// Filter our collection
var filteredItems = collection.AsParallel().Where( i => i.SomePredicate() );

// Now perform an action once the filter completes
Parallel.ForEach(filteredItems, item =>
{
    // These will now run in parallel
    item.DoSomething();
});

This is a noticeable improvement, since both our filtering and our actions run parallelized.  However, there is still a large bottleneck in place here. 

The problem lies with my comment “perform an action once the filter completes”.  Here, we’re parallelizing the filter, then collecting all of the results, blocking until the filter completes.  Once the filtering of every element is completed, we then repartition the results of the filter, reschedule into multiple threads, and perform the action on each element.  By moving this into two separate statements, we potentially double our parallelization overhead, since we’re forcing the work to be partitioned and scheduled twice as many times.

This is where the pragmatism comes into play.  By violating our functional principles, we gain the ability to avoid the overhead and cost of rescheduling the work:

// Perform an action on the results of our filter
collection
    .AsParallel()
    .Where( i => i.SomePredicate() )
    .ForAll( i => i.DoSomething() );

The ability to avoid the scheduling overhead is a compelling reason to use ForAll.  This really goes back to one of the key points I discussed in data parallelism: Partition your problem in a way to place the most work possible into each task.  Here, this means leaving the statement attached to the expression, even though it causes side effects and is not standard usage for LINQ.

This leads to my one guideline for using ForAll:

The ForAll extension method should only be used to process the results of a parallel query, as returned by a PLINQ expression.

Any other usage scenario should use Parallel.ForEach, instead.

In order to illustrate the main differences, and why they exist, let’s begin by discussing some differences in how the two technologies operate, and look at the underlying types involved in LINQ to Objects and PLINQ .

LINQ to Objects is mainly built upon a single class: Enumerable.  The Enumerable class is a static class that defines a large set of extension methods, nearly all of which work upon an IEnumerable<T>.  Many of these methods return a new IEnumerable<T>, allowing the methods to be chained together into a fluent style interface.  This is what allows us to write statements that chain together, and lead to the nice declarative programming model of LINQ:

double min = collection
                .Where(item => item.SomeProperty > 6 && item.SomeProperty < 24)
                .Min(item => item.PerformComputation());

Other LINQ variants work in a similar fashion.  For example, most data-oriented LINQ providers are built upon an implementation of IQueryable<T>, which allows the database provider to turn a LINQ statement into an underlying SQL query, to be performed directly on the remote database.

PLINQ is similar, but instead of being built upon the Enumerable class, most of PLINQ is built upon a new static class: ParallelEnumerable.  When using PLINQ, you typically begin with any collection which implements IEnumerable<T>, and convert it to a new type using an extension method defined on ParallelEnumerable: AsParallel().  This method takes any IEnumerable<T>, and converts it into a ParallelQuery<T>, the core class for PLINQ.  There is a similar ParallelQuery class for working with non-generic IEnumerable implementations.

This brings us to our first subtle, but important difference between PLINQ and LINQ –

PLINQ always works upon specific types, which must be explicitly created.

Typically, the type you’ll use with PLINQ is ParallelQuery<T>, but it can sometimes be a ParallelQuery or an OrderedParallelQuery<T>.  Instead of dealing with an interface, implemented by an unknown class, we’re dealing with a specific class type.  This works seamlessly from a usage standpoint – ParallelQuery<T> implements IEnumerable<T>, so you can always “switch back” to an IEnumerable<T>. 

The difference only arises at the beginning of our parallelization.  When we’re using LINQ, and we want to process a normal collection via PLINQ, we need to explicitly convert the collection into a ParallelQuery<T> by calling AsParallel().  There is an important consideration here – AsParallel() does not need to be called on your specific collection, but rather any IEnumerable<T>.  This allows you to place it anywhere in the chain of methods involved in a LINQ statement, not just at the beginning.  This can be useful if you have an operation which will not parallelize well or is not thread safe.  For example, the following is perfectly valid, and similar to our previous examples:

double min = collection
                .AsParallel()
                .Select(item => item.SomeOperation())
                .Where(item => item.SomeProperty > 6 && item.SomeProperty < 24)
                .Min(item => item.PerformComputation());

However, if SomeOperation() is not thread safe, we could just as easily do:

double min = collection
                .Select(item => item.SomeOperation())
                .AsParallel()
                .Where(item => item.SomeProperty > 6 && item.SomeProperty < 24)
                .Min(item => item.PerformComputation());

In this case, we’re using standard LINQ to Objects for the Select(…) method, then converting the results of that map routine to a ParallelQuery<T>, and processing our filter (the Where method) and our aggregation (the Min method) in parallel.

PLINQ also provides us with a way to convert a ParallelQuery<T> back into a standard IEnumerable<T>, forcing sequential processing via standard LINQ to Objects.  If SomeOperation() was thread-safe, but PerformComputation() was not thread-safe, we would need to handle this by using the AsEnumerable() method:

double min = collection
                .AsParallel()
                .Select(item => item.SomeOperation())
                .Where(item => item.SomeProperty > 6 && item.SomeProperty < 24)
                .AsEnumerable()
                .Min(item => item.PerformComputation());

Here, we’re converting our collection into a ParallelQuery<T>, doing our map operation (the Select(…) method) and our filtering in parallel, then converting the collection back into a standard IEnumerable<T>, which causes our aggregation via Min() to be performed sequentially.

This could also be written as two statements, as well, which would allow us to use the language integrated syntax for the first portion:

var tempCollection = from item in collection.AsParallel()
                     let e = item.SomeOperation()
                     where (e.SomeProperty > 6 && e.SomeProperty < 24)
                     select e;
double min = tempCollection.AsEnumerable().Min(item => item.PerformComputation());

This allows us to use the standard LINQ style language integrated query syntax, but control whether it’s performed in parallel or serial by adding AsParallel() and AsEnumerable() appropriately.

The second important difference between PLINQ and LINQ deals with order preservation. 

PLINQ, by default, does not preserve the order of of source collection.

This is by design.  In order to process a collection in parallel, the system needs to naturally deal with multiple elements at the same time.  Maintaining the original ordering of the sequence adds overhead, which is, in many cases, unnecessary.  Therefore, by default, the system is allowed to completely change the order of your sequence during processing.  If you are doing a standard query operation, this is usually not an issue.  However, there are times when keeping a specific ordering in place is important.  If this is required, you can explicitly request the ordering be preserved throughout all operations done on a ParallelQuery<T> by using the AsOrdered() extension method.  This will cause our sequence ordering to be preserved.

For example, suppose we wanted to take a collection, perform an expensive operation which converts it to a new type, and display the first 100 elements.  In LINQ to Objects, our code might look something like:

// Using IEnumerable<SourceClass> collection
IEnumerable<ResultClass> results = collection
                                       .Select(e => e.CreateResult())
                                       .Take(100);

If we just converted this to a parallel query naively, like so:

IEnumerable<ResultClass> results = collection
                                       .AsParallel()
                                       .Select(e => e.CreateResult())
                                       .Take(100);

We could very easily get a very different, and non-reproducable, set of results, since the ordering of elements in the input collection is not preserved.  To get the same results as our original query, we need to use:

IEnumerable<ResultClass> results = collection
                                       .AsParallel()
                                       .AsOrdered()
                                       .Select(e => e.CreateResult())
                                       .Take(100);

This requests that PLINQ process our sequence in a way that verifies that our resulting collection is ordered as if it were processed serially.  This will cause our query to run slower, since there is overhead involved in maintaining the ordering.  However, in this case, it is required, since the ordering is required for correctness.

PLINQ is incredibly useful.  It allows us to easily take nearly any LINQ to Objects query and run it in parallel, using the same methods and syntax we’ve used previously.  There are some important differences in operation that must be considered, however – it is not a free pass to parallelize everything.  When using PLINQ in order to parallelize your routines declaratively, the same guideline I mentioned before still applies:

Parallelization is something that should be handled with care and forethought, added by design, and not just introduced casually.

C# 3.0 and Visual Basic 9.0 introduced a new, declarative programming model to .NET via the LINQ Project.  When working with collections, we can now write software that describes what we want to occur without having to explicitly state how the program should accomplish the task.  By taking advantage of LINQ, many operations become much shorter, more elegant, and easier to understand and maintain.  Version 4.0 of the .NET framework extends this concept into the parallel computation space by introducing Parallel LINQ.

Before we delve into PLINQ, let’s begin with a short discussion of LINQ.  LINQ, the extensions to the .NET Framework which implement language integrated query, set, and transform operations, is implemented in many flavors.  For our purposes, we are interested in LINQ to Objects.  When dealing with parallelizing a routine, we typically are dealing with in-memory data storage.  More data-access oriented LINQ variants, such as LINQ to SQL and LINQ to Entities in the Entity Framework fall outside of our concern, since the parallelism there is the concern of the data base engine processing the query itself.

LINQ (LINQ to Objects in particular) works by implementing a series of extension methods, most of which work on IEnumerable<T>.  The language enhancements use these extension methods to create a very concise, readable alternative to using traditional foreach statement.  For example, let’s revisit our minimum aggregation routine we wrote in Part 4:

double min = double.MaxValue;
foreach(var item in collection)
{
    double value = item.PerformComputation();
    min = System.Math.Min(min, value);
}

Here, we’re doing a very simple computation, but writing this in an imperative style.  This can be loosely translated to English as:

Create a very large number, and save it in min
Loop through each item in the collection.
For every item:
    Perform some computation, and save the result
    If the computation is less than min, set min to the computation 

Although this is fairly easy to follow, it’s quite a few lines of code, and it requires us to read through the code, step by step, line by line, in order to understand the intention of the developer.

We can rework this same statement, using LINQ:

double min = collection.Min(item => item.PerformComputation());

Here, we’re after the same information.  However, this is written using a declarative programming style.  When we see this code, we’d naturally translate this to English as:

Save the Min value of collection, determined via calling item.PerformComputation() 

That’s it – instead of multiple logical steps, we have one single, declarative request.  This makes the developer’s intentions very clear, and very easy to follow.  The system is free to implement this using whatever method required.

Parallel LINQ (PLINQ) extends LINQ to Objects to support parallel operations.  This is a perfect fit in many cases when you have a problem that can be decomposed by data.  To show this, let’s again refer to our minimum aggregation routine from Part 4, but this time, let’s review our final, parallelized version:

// Safe, and fast!
double min = double.MaxValue;
// Make a "lock" object
object syncObject = new object();
Parallel.ForEach(
    collection,
    // First, we provide a local state initialization delegate.
    () => double.MaxValue,
    // Next, we supply the body, which takes the original item, loop state,
    // and local state, and returns a new local state
    (item, loopState, localState) =>
    {
        double value = item.PerformComputation();
        return System.Math.Min(localState, value);
    },
    // Finally, we provide an Action<TLocal>, to "merge" results together
    localState =>
    {
        // This requires locking, but it's only once per used thread
        lock(syncObj)
            min = System.Math.Min(min, localState);
    }
);

Here, we’re doing the same computation as above, but fully parallelized.  Describing this in English becomes quite a feat:

Create a very large number, and save it in min
Create a temporary object we can use for locking
Call Parallel.ForEach, specifying three delegates
    For the first delegate:
        Initialize a local variable to hold the local state to a very large number
    For the second delegate:
        For each item in the collection, perform some computation, save the result
        If the result is less than our local state, save the result in local state
    For the final delegate:
        Take a lock on our temporary object to protect our min variable
        Save the min of our min and local state variables

Although this solves our problem, and does it in a very efficient way, we’ve created a set of code that is quite a bit more difficult to understand and maintain.

PLINQ provides us with a very nice alternative.  In order to use PLINQ, we need to learn one new extension method that works on IEnumerable<T> – ParallelEnumerable.AsParallel().

That’s all we need to learn in order to use PLINQ: one single method.  We can write our minimum aggregation in PLINQ very simply:

double min = collection.AsParallel().Min(item => item.PerformComputation());

By simply adding “.AsParallel()” to our LINQ to Objects query, we converted this to using PLINQ and running this computation in parallel! 

This can be loosely translated into English easily, as well:

Process the collection in parallel
Get the Minimum value, determined by calling PerformComputation on each item 

Here, our intention is very clear and easy to understand.  We just want to perform the same operation we did in serial, but run it “as parallel”.  PLINQ completely extends LINQ to Objects: the entire functionality of LINQ to Objects is available.  By simply adding a call to AsParallel(), we can specify that a collection should be processed in parallel.  This is simple, safe, and incredibly useful.

Partitioning our tasks is a challenging feat.  There are opposing forces at work here: too many partitions adds overhead, too few partitions leaves processors idle.  Trying to work the perfect balance between the two extremes is the goal for which we should aim.  Luckily, the Task Parallel Library automatically handles much of this process.  However, there are situations where the default partitioning may not be appropriate, and knowledge of our routines may allow us to guide the framework to making better decisions.

First off, I’d like to say that this is a more advanced topic.  It is perfectly acceptable to use the parallel constructs in the framework without considering the partitioning taking place.  The default behavior in the Task Parallel Library is very well-behaved, even for unusual work loads, and should rarely be adjusted.  I have found few situations where the default partitioning behavior in the TPL is not as good or better than my own hand-written partitioning routines, and recommend using the defaults unless there is a strong, measured, and profiled reason to avoid using them.  However, understanding partitioning, and how the TPL partitions your data, helps in understanding the proper usage of the TPL.

I indirectly mentioned partitioning while discussing aggregation.  Typically, our systems will have a limited number of Processing Elements (PE), which is the terminology used for hardware capable of processing a stream of instructions.  For example, in a standard Intel i7 system, there are four processor cores, each of which has two potential hardware threads due to Hyperthreading.  This gives us a total of 8 PEs – theoretically, we can have up to eight operations occurring concurrently within our system.

In order to fully exploit this power, we need to partition our work into Tasks.  A task is a simple set of instructions that can be run on a PE.  Ideally, we want to have at least one task per PE in the system, since fewer tasks means that some of our processing power will be sitting idle.  A naive implementation would be to just take our data, and partition it with one element in our collection being treated as one task.  When we loop through our collection in parallel, using this approach, we’d just process one item at a time, then reuse that thread to process the next, etc.  There’s a flaw in this approach, however.  It will tend to be slower than necessary, often slower than processing the data serially.

The problem is that there is overhead associated with each task.  When we take a simple foreach loop body and implement it using the TPL, we add overhead.  First, we change the body from a simple statement to a delegate, which must be invoked.  In order to invoke the delegate on a separate thread, the delegate gets added to the ThreadPool’s current work queue, and the ThreadPool must pull this off the queue, assign it to a free thread, then execute it.  If our collection had one million elements, the overhead of trying to spawn one million tasks would destroy our performance.

The answer, here, is to partition our collection into groups, and have each group of elements treated as a single task.  By adding a partitioning step, we can break our total work into small enough tasks to keep our processors busy, but large enough tasks to avoid overburdening the ThreadPool.  There are two clear, opposing goals here:

Always try to keep each processor working, but also try to keep the individual partitions as large as possible.

When using Parallel.For, the partitioning is always handled automatically.  At first, partitioning here seems simple.  A naive implementation would merely split the total element count up by the number of PEs in the system, and assign a chunk of data to each processor.  Many hand-written partitioning schemes work in this exactly manner.  This perfectly balanced, static partitioning scheme works very well if the amount of work is constant for each element.  However, this is rarely the case.  Often, the length of time required to process an element grows as we progress through the collection, especially if we’re doing numerical computations.  In this case, the first PEs will finish early, and sit idle waiting on the last chunks to finish.  Sometimes, work can decrease as we progress, since previous computations may be used to speed up later computations.  In this situation, the first chunks will be working far longer than the last chunks.  In order to balance the workload, many implementations create many small chunks, and reuse threads.  This adds overhead, but does provide better load balancing, which in turn improves performance.

The Task Parallel Library handles this more elaborately.  Chunks are determined at runtime, and start small.  They grow slowly over time, getting larger and larger.  This tends to lead to a near optimum load balancing, even in odd cases such as increasing or decreasing workloads. 

Parallel.ForEach is a bit more complicated, however. When working with a generic IEnumerable<T>, the number of items required for processing is not known in advance, and must be discovered at runtime.  In addition, since we don’t have direct access to each element, the scheduler must enumerate the collection to process it.  Since IEnumerable<T> is not thread safe, it must lock on elements as it enumerates, create temporary collections for each chunk to process, and schedule this out.  By default, it uses a partitioning method similar to the one described above.  We can see this directly by looking at the Visual Partitioning sample shipped by the Task Parallel Library team, and available as part of the Samples for Parallel Programming.  When we run the sample, with four cores and the default, Load Balancing partitioning scheme, we see this:

The colored bands represent each processing core.  You can see that, when we started (at the top), we begin with very small bands of color.  As the routine progresses through the Parallel.ForEach, the chunks get larger and larger (seen by larger and larger stripes).

Most of the time, this is fantastic behavior, and most likely will out perform any custom written partitioning.  However, if your routine is not scaling well, it may be due to a failure in the default partitioning to handle your specific case.  With prior knowledge about your work, it may be possible to partition data more meaningfully than the default Partitioner.

There is the option to use an overload of Parallel.ForEach which takes a Partitioner<T> instance.  The Partitioner<T> class is an abstract class which allows for both static and dynamic partitioning.  By overriding Partitioner<T>.SupportsDynamicPartitions, you can specify whether a dynamic approach is available.  If not, your custom Partitioner<T> subclass would override GetPartitions(int), which returns a list of IEnumerator<T> instances.  These are then used by the Parallel class to split work up amongst processors.  When dynamic partitioning is available, GetDynamicPartitions() is used, which returns an IEnumerable<T> for each partition.  If you do decide to implement your own Partitioner<T>, keep in mind the goals and tradeoffs of different partitioning strategies, and design appropriately.

The Samples for Parallel Programming project includes a ChunkPartitioner class in the ParallelExtensionsExtras project.  This provides example code for implementing your own, custom allocation strategies, including a static allocator of a given chunk size.  Although implementing your own Partitioner<T> is possible, as I mentioned above, this is rarely required or useful in practice.  The default behavior of the TPL is very good, often better than any hand written partitioning strategy.

Simple examples of this might include taking the sum of the results of processing a function on each element in the collection, or finding the minimum of the collection given some criteria.  This can be done using the techniques described in simple data parallelism, however, special care needs to be taken into account to synchronize the shared data appropriately.  The Task Parallel Library has tools to assist in this synchronization.

The main issue with aggregation when parallelizing a routine is that you need to handle synchronization of data.  Since multiple threads will need to write to a shared portion of data.  Suppose, for example, that we wanted to parallelize a simple loop that looked for the minimum value within a dataset:

double min = double.MaxValue;
foreach(var item in collection)
{
    double value = item.PerformComputation();
    min = System.Math.Min(min, value);
}

This seems like a good candidate for parallelization, but there is a problem here.  If we just wrap this into a call to Parallel.ForEach, we’ll introduce a critical race condition, and get the wrong answer.  Let’s look at what happens here:

// Buggy code!  Do not use!
double min = double.MaxValue;
Parallel.ForEach(collection, item =>
{
    double value = item.PerformComputation();
    min = System.Math.Min(min, value);
});

This code has a fatal flaw: min will be checked, then set, by multiple threads simultaneously.  Two threads may perform the check at the same time, and set the wrong value for min.  Say we get a value of 1 in thread 1, and a value of 2 in thread 2, and these two elements are the first two to run.  If both hit the min check line at the same time, both will determine that min should change, to 1 and 2 respectively.  If element 1 happens to set the variable first, then element 2 sets the min variable, we’ll detect a min value of 2 instead of 1.  This can lead to wrong answers.

Unfortunately, fixing this, with the Parallel.ForEach call we’re using, would require adding locking.  We would need to rewrite this like:

// Safe, but slow
double min = double.MaxValue;
// Make a "lock" object
object syncObject = new object();
Parallel.ForEach(collection, item =>
{
    double value = item.PerformComputation();
    lock(syncObject)
        min = System.Math.Min(min, value);
});

This will potentially add a huge amount of overhead to our calculation.  Since we can potentially block while waiting on the lock for every single iteration, we will most likely slow this down to where it is actually quite a bit slower than our serial implementation.  The problem is the lock statement – any time you use lock(object), you’re almost assuring reduced performance in a parallel situation.  This leads to two observations I’ll make:

When parallelizing a routine, try to avoid locks.

That being said:

Always add any and all required synchronization to avoid race conditions.

These two observations tend to be opposing forces – we often need to synchronize our algorithms, but we also want to avoid the synchronization when possible.  Looking at our routine, there is no way to directly avoid this lock, since each element is potentially being run on a separate thread, and this lock is necessary in order for our routine to function correctly every time.

However, this isn’t the only way to design this routine to implement this algorithm.  Realize that, although our collection may have thousands or even millions of elements, we have a limited number of Processing Elements (PE).  Processing Element is the standard term for a hardware element which can process and execute instructions.  This typically is a core in your processor, but many modern systems have multiple hardware execution threads per core.  The Task Parallel Library will not execute the work for each item in the collection as a separate work item. Instead, when Parallel.ForEach executes, it will partition the collection into larger “chunks” which get processed on different threads via the ThreadPool.  This helps reduce the threading overhead, and help the overall speed.  In general, the Parallel class will only use one thread per PE in the system.

Given the fact that there are typically fewer threads than work items, we can rethink our algorithm design.  We can parallelize our algorithm more effectively by approaching it differently.  Because the basic aggregation we are doing here (Min) is communitive, we do not need to perform this in a given order.  We knew this to be true already – otherwise, we wouldn’t have been able to parallelize this routine in the first place.  With this in mind, we can treat each thread’s work independently, allowing each thread to serially process many elements with no locking, then, after all the threads are complete, “merge” together the results.

This can be accomplished via a different set of overloads in the Parallel class: Parallel.ForEach<TSource,TLocal>.  The idea behind these overloads is to allow each thread to begin by initializing some local state (TLocal).  The thread will then process an entire set of items in the source collection, providing that state to the delegate which processes an individual item.  Finally, at the end, a separate delegate is run which allows you to handle merging that local state into your final results.

To rewriting our routine using Parallel.ForEach<TSource,TLocal>, we need to provide three delegates instead of one.  The most basic version of this function is declared as:

public static ParallelLoopResult ForEach<TSource, TLocal>(
    IEnumerable<TSource> source,
    Func<TLocal> localInit,
    Func<TSource, ParallelLoopState, TLocal, TLocal> body,
    Action<TLocal> localFinally
)

The first delegate (the localInit argument) is defined as Func<TLocal>.  This delegate initializes our local state.  It should return some object we can use to track the results of a single thread’s operations.

The second delegate (the body argument) is where our main processing occurs, although now, instead of being an Action<T>, we actually provide a Func<TSource, ParallelLoopState, TLocal, TLocal> delegate.  This delegate will receive three arguments: our original element from the collection (TSource), a ParallelLoopState which we can use for early termination, and the instance of our local state we created (TLocal).  It should do whatever processing you wish to occur per element, then return the value of the local state after processing is completed.

The third delegate (the localFinally argument) is defined as Action<TLocal>.  This delegate is passed our local state after it’s been processed by all of the elements this thread will handle.  This is where you can merge your final results together.  This may require synchronization, but now, instead of synchronizing once per element (potentially millions of times), you’ll only have to synchronize once per thread, which is an ideal situation.

Now that I’ve explained how this works, lets look at the code:

// Safe, and fast!
double min = double.MaxValue;
// Make a "lock" object
object syncObject = new object();
Parallel.ForEach(
    collection,
    // First, we provide a local state initialization delegate.
    () => double.MaxValue,
    // Next, we supply the body, which takes the original item, loop state,
    // and local state, and returns a new local state
    (item, loopState, localState) =>
    {
        double value = item.PerformComputation();
        return System.Math.Min(localState, value);
    },
    // Finally, we provide an Action<TLocal>, to "merge" results together
    localState =>
    {
        // This requires locking, but it's only once per used thread
        lock(syncObj)
            min = System.Math.Min(min, localState);
    }
);

Although this is a bit more complicated than the previous version, it is now both thread-safe, and has minimal locking. 

This same approach can be used by Parallel.For, although now, it’s Parallel.For<TLocal>.  When working with Parallel.For<TLocal>, you use the same triplet of delegates, with the same purpose and results.

Also, many times, you can completely avoid locking by using a method of the Interlocked class to perform the final aggregation in an atomic operation.  The MSDN example demonstrating this same technique using Parallel.For uses the Interlocked class instead of a lock, since they are doing a sum operation on a long variable, which is possible via Interlocked.Add.

By taking advantage of local state, we can use the Parallel class methods to parallelize algorithms such as aggregation, which, at first, may seem like poor candidates for parallelization.  Doing so requires careful consideration, and often requires a slight redesign of the algorithm, but the performance gains can be significant if handled in a way to avoid excessive synchronization.

Unfortunately, there are many common cases where this does not happen.  If we are dealing with a loop that requires early termination, extra care is required when parallelizing.

Often, while processing in a loop, once a certain condition is met, it is no longer necessary to continue processing.  This may be a matter of finding a specific element within the collection, or reaching some error case.  The important distinction here is that, it is often impossible to know until runtime, what set of elements needs to be processed.

In my initial discussion of data parallelism, I mentioned that this technique is a candidate when you can decompose the problem based on the data involved, and you wish to apply a single operation concurrently on all of the elements of a collection.  This covers many of the potential cases, but sometimes, after processing some of the elements, we need to stop processing.

As an example, lets go back to our previous Parallel.ForEach example with contacting a customer.  However, this time, we’ll change the requirements slightly.  In this case, we’ll add an extra condition – if the store is unable to email the customer, we will exit gracefully.  The thinking here, of course, is that if the store is currently unable to email, the next time this operation runs, it will handle the same situation, so we can just skip our processing entirely.  The original, serial case, with this extra condition, might look something like the following:

foreach(var customer in customers)
{
    // Run some process that takes some time...
    DateTime lastContact = theStore.GetLastContact(customer);
    TimeSpan timeSinceContact = DateTime.Now - lastContact;

    // If it's been more than two weeks, send an email, and update...
    if (timeSinceContact.Days > 14)
    {
         // Exit gracefully if we fail to email, since this 
         // entire process can be repeated later without issue.
         if (theStore.EmailCustomer(customer) == false)
             break;
         customer.LastEmailContact = DateTime.Now;
    }
}

Here, we’re processing our loop, but at any point, if we fail to send our email successfully, we just abandon this process, and assume that it will get handled correctly the next time our routine is run.  If we try to parallelize this using Parallel.ForEach, as we did previously, we’ll run into an error almost immediately: the break statement we’re using is only valid when enclosed within an iteration statement, such as foreach.  When we switch to Parallel.ForEach, we’re no longer within an iteration statement – we’re a delegate running in a method.

This needs to be handled slightly differently when parallelized.  Instead of using the break statement, we need to utilize a new class in the Task Parallel Library: ParallelLoopState.  The ParallelLoopState class is intended to allow concurrently running loop bodies a way to interact with each other, and provides us with a way to break out of a loop.  In order to use this, we will use a different overload of Parallel.ForEach which takes an IEnumerable<T> and an Action<T, ParallelLoopState> instead of an Action<T>.  Using this, we can parallelize the above operation by doing:

Parallel.ForEach(customers, (customer, parallelLoopState) =>
{
    // Run some process that takes some time...
    DateTime lastContact = theStore.GetLastContact(customer);
    TimeSpan timeSinceContact = DateTime.Now - lastContact;

    // If it's been more than two weeks, send an email, and update...
    if (timeSinceContact.Days > 14)
    {
         // Exit gracefully if we fail to email, since this 
         // entire process can be repeated later without issue.
         if (theStore.EmailCustomer(customer) == false)
             parallelLoopState.Break();
         else
             customer.LastEmailContact = DateTime.Now;
    }
});

There are a couple of important points here.  First, we didn’t actually instantiate the ParallelLoopState instance.  It was provided directly to us via the Parallel class.  All we needed to do was change our lambda expression to reflect that we want to use the loop state, and the Parallel class creates an instance for our use.  We also needed to change our logic slightly when we call Break().  Since Break() doesn’t stop the program flow within our block, we needed to add an else case to only set the property in customer when we succeeded.  This same technique can be used to break out of a Parallel.For loop.

That being said, there is a huge difference between using ParallelLoopState to cause early termination and to use break in a standard iteration statement.  When dealing with a loop serially, break will immediately terminate the processing within the closest enclosing loop statement.  Calling ParallelLoopState.Break(), however, has a very different behavior.

The issue is that, now, we’re no longer processing one element at a time.  If we break in one of our threads, there are other threads that will likely still be executing.  This leads to an important observation about termination of parallel code:

Early termination in parallel routines is not immediate.  Code will continue to run after you request a termination.

This may seem problematic at first, but it is something you just need to keep in mind while designing your routine.  ParallelLoopState.Break() should be thought of as a request.  We are telling the runtime that no elements that were in the collection past the element we’re currently processing need to be processed, and leaving it up to the runtime to decide how to handle this as gracefully as possible.  Although this may seem problematic at first, it is a good thing.  If the runtime tried to immediately stop processing, many of our elements would be partially processed.  It would be like putting a return statement in a random location throughout our loop body – which could have horrific consequences to our code’s maintainability.

In order to understand and effectively write parallel routines, we, as developers, need a subtle, but profound shift in our thinking.  We can no longer think in terms of sequential processes, but rather need to think in terms of requests to the system that may be handled differently than we’d first expect.  This is more natural to developers who have dealt with asynchronous models previously, but is an important distinction when moving to concurrent programming models.

As an example, I’ll discuss the Break() method.  ParallelLoopState.Break() functions in a way that may be unexpected at first.  When you call Break() from a loop body, the runtime will continue to process all elements of the collection that were found prior to the element that was being processed when the Break() method was called.  This is done to keep the behavior of the Break() method as close to the behavior of the break statement as possible. We can see the behavior in this simple code:

var collection = Enumerable.Range(0, 20);
var pResult = Parallel.ForEach(collection, (element, state) =>
{
    if (element > 10)
    {
        Console.WriteLine("Breaking on {0}", element);
        state.Break();
    }
    Console.WriteLine(element);
});

If we run this, we get a result that may seem unexpected at first:

0
2
1
5
6
3
4
10
Breaking on 11
11
Breaking on 12
12
9
Breaking on 13
13
7
8
Breaking on 15
15

What is occurring here is that we loop until we find the first element where the element is greater than 10.  In this case, this was found, the first time, when one of our threads reached element 11.  It requested that the loop stop by calling Break() at this point.  However, the loop continued processing until all of the elements less than 11 were completed, then terminated.  This means that it will guarantee that elements 9, 7, and 8 are completed before it stops processing.  You can see our other threads that were running each tried to break as well, but since Break() was called on the element with a value of 11, it decides which elements (0-10) must be processed.

If this behavior is not desirable, there is another option.  Instead of calling ParallelLoopState.Break(), you can call ParallelLoopState.Stop().  The Stop() method requests that the runtime terminate as soon as possible , without guaranteeing that any other elements are processed.  Stop() will not stop the processing within an element, so elements already being processed will continue to be processed.  It will prevent new elements, even ones found earlier in the collection, from being processed.  Also, when Stop() is called, the ParallelLoopState’s IsStopped property will return true.  This lets longer running processes poll for this value, and return after performing any necessary cleanup.

The basic rule of thumb for choosing between Break() and Stop() is the following.

• Use ParallelLoopState.Stop() when possible, since it terminates more quickly.  This is particularly useful in situations where you are searching for an element or a condition in the collection.  Once you’ve found it, you do not need to do any other processing, so Stop() is more appropriate.
• Use ParallelLoopState.Break() if you need to more closely match the behavior of the C# break statement.

Both methods behave differently than our C# break statement.  Unfortunately, when parallelizing a routine, more thought and care needs to be put into every aspect of your routine than you may otherwise expect.  This is due to my second observation:

Parallelizing a routine will almost always change its behavior.

This sounds crazy at first, but it’s a concept that’s so simple its easy to forget.  We’re purposely telling the system to process more than one thing at the same time, which means that the sequence in which things get processed is no longer deterministic.  It is easy to change the behavior of your routine in very subtle ways by introducing parallelism.  Often, the changes are not avoidable, even if they don’t have any adverse side effects.  This leads to my final observation for this post:

Parallelization is something that should be handled with care and forethought, added by design, and not just introduced casually.

Data Parallelism is the main technique we use to parallelize a routine which can be decomposed based off data.  Data Parallelism refers to taking a single collection of data, and having a single operation be performed concurrently on elements in the collection. 

One side note here: Data Parallelism is also sometimes referred to as the Loop Parallelism Pattern or Loop-level Parallelism.  In general, for this series, I will try to use the terminology used in the MSDN Documentation for the Task Parallel Library.  This should make it easier to investigate these topics in more detail.

Once we’ve determined we have a problem that, potentially, can be decomposed based on data, implementation using Data Parallelism in the TPL is quite simple.  Let’s take our example from the Data Decomposition discussion – a simple contrast stretching filter.  Here, we have a collection of data (pixels), and we need to run a simple operation on each element of the pixel.  Once we know the minimum and maximum values, we most likely would have some simple code like the following:

for (int row=0; row < pixelData.GetUpperBound(0); ++row)
{
    for (int col=0; col < pixelData.GetUpperBound(1); ++col)
    {
        pixelData[row, col] = AdjustContrast(pixelData[row, col], minPixel, maxPixel);
    }
}

This simple routine loops through a two dimensional array of pixelData, and calls the AdjustContrast routine on each pixel.

As I mentioned, when you’re decomposing a problem space, most iteration statements are potentially candidates for data decomposition.  Here, we’re using two for loops – one looping through rows in the image, and a second nested loop iterating through the columns.  We then perform one, independent operation on each element based on those loop positions.

This is a prime candidate – we have no shared data, no dependencies on anything but the pixel which we want to change.  Since we’re using a for loop, we can easily parallelize this using the Parallel.For method in the TPL:

Parallel.For(0, pixelData.GetUpperBound(0), row =>
{
    for (int col=0; col < pixelData.GetUpperBound(1); ++col)
    {
        pixelData[row, col] = AdjustContrast(pixelData[row, col], minPixel, maxPixel);
    }
});

Here, by simply changing our first for loop to a call to Parallel.For, we can parallelize this portion of our routine.  Parallel.For works, as do many methods in the TPL, by creating a delegate and using it as an argument to a method.  In this case, our for loop iteration block becomes a delegate creating via a lambda expression.  This lets you write code that, superficially, looks similar to the familiar for loop, but functions quite differently at runtime.

We could easily do this to our second for loop as well, but that may not be a good idea.  There is a balance to be struck when writing parallel code.  We want to have enough work items to keep all of our processors busy, but the more we partition our data, the more overhead we introduce.  In this case, we have an image of data – most likely hundreds of pixels in both dimensions.  By just parallelizing our first loop, each row of pixels can be run as a single task.  With hundreds of rows of data, we are providing fine enough granularity to keep all of our processors busy.

If we parallelize both loops, we’re potentially creating millions of independent tasks.  This introduces extra overhead with no extra gain, and will actually reduce our overall performance.  This leads to my first guideline when writing parallel code:

Partition your problem into enough tasks to keep each processor busy throughout the operation, but not more than necessary to keep each processor busy.

Also note that I parallelized the outer loop.  I could have just as easily partitioned the inner loop.  However, partitioning the inner loop would have led to many more discrete work items, each with a smaller amount of work (operate on one pixel instead of one row of pixels).  My second guideline when writing parallel code reflects this:

Partition your problem in a way to place the most work possible into each task.

This typically means, in practice, that you will want to parallelize the routine at the “highest” point possible in the routine, typically the outermost loop.  If you’re looking at parallelizing methods which call other methods, you’ll want to try to partition your work high up in the stack – as you get into lower level methods, the performance impact of parallelizing your routines may not overcome the overhead introduced.

Parallel.For works great for situations where we know the number of elements we’re going to process in advance.  If we’re iterating through an IList<T> or an array, this is a typical approach.  However, there are other iteration statements common in C#.  In many situations, we’ll use foreach instead of a for loop.  This can be more understandable and easier to read, but also has the advantage of working with collections which only implement IEnumerable<T>, where we do not know the number of elements involved in advance.

As an example, lets take the following situation.  Say we have a collection of Customers, and we want to iterate through each customer, check some information about the customer, and if a certain case is met, send an email to the customer and update our instance to reflect this change.  Normally, this might look something like:

foreach(var customer in customers)
{
    // Run some process that takes some time...
    DateTime lastContact = theStore.GetLastContact(customer);
    TimeSpan timeSinceContact = DateTime.Now - lastContact;

    // If it's been more than two weeks, send an email, and update...
    if (timeSinceContact.Days > 14)
    {
       theStore.EmailCustomer(customer);
       customer.LastEmailContact = DateTime.Now;
    }
}

Here, we’re doing a fair amount of work for each customer in our collection, but we don’t know how many customers exist.  If we assume that theStore.GetLastContact(customer) and theStore.EmailCustomer(customer) are both side-effect free, thread safe operations, we could parallelize this using Parallel.ForEach:

Parallel.ForEach(customers, customer =>
{
    // Run some process that takes some time...
    DateTime lastContact = theStore.GetLastContact(customer);
    TimeSpan timeSinceContact = DateTime.Now - lastContact;

    // If it's been more than two weeks, send an email, and update...
    if (timeSinceContact.Days > 14)
    {
       theStore.EmailCustomer(customer);
       customer.LastEmailContact = DateTime.Now;
    }
});

Just like Parallel.For, we rework our loop into a method call accepting a delegate created via a lambda expression.  This keeps our new code very similar to our original iteration statement, however, this will now execute in parallel.  The same guidelines apply with Parallel.ForEach as with Parallel.For.

The other iteration statements, do and while, do not have direct equivalents in the Task Parallel Library.  These, however, are very easy to implement using Parallel.ForEach and the yield keyword.

Most applications can benefit from implementing some form of Data Parallelism.  Iterating through collections and performing “work” is a very common pattern in nearly every application.  When the problem can be decomposed by data, we often can parallelize the workload by merely changing foreach statements to Parallel.ForEach method calls, and for loops to Parallel.For method calls.  Any time your program operates on a collection, and does a set of work on each item in the collection where that work is not dependent on other information, you very likely have an opportunity to parallelize your routine.

There are two common abstractions that are useful when discussing parallel decomposition: Data Decomposition and Task Decomposition.  These two abstractions allow us to think about our problem in a way that helps leads us to correct decision making in terms of the algorithms we’ll use to parallelize our routine.

To start, I will make a couple of minor points.

• I’d like to stress that Decomposition has nothing to do with specific algorithms or techniques.  It’s about how you approach and think about the problem, not how you solve the problem using a specific tool, technique, or library.  Decomposing the problem is about constructing the appropriate mental model: once this is done, you can choose the appropriate design and tools, which is a subject for future posts.
• Decomposition, being unrelated to tools or specific techniques, is not specific to .NET in any way.  This should be the first step to parallelizing a problem, and is valid using any framework, language, or toolset.  However, this gives us a starting point – without a proper understanding of decomposition, it is difficult to understand the proper usage of specific classes and tools within the .NET framework.

Data Decomposition is often the simpler abstraction to use when trying to parallelize a routine.  In order to decompose our problem domain by data, we take our entire set of data and break it into smaller, discrete portions, or chunks.  We then work on each chunk in the data set in parallel.

This is particularly useful if we can process each element of data independently of the rest of the data.  In a situation like this, there are some wonderfully simple techniques we can use to take advantage of our data.  By decomposing our domain by data, we can very simply parallelize our routines.  In general, we, as developers, should be always searching for data that can be decomposed.

Finding data to decompose if fairly simple, in many instances.  Data decomposition is typically used with collections of data.  Any time you have a collection of items, and you’re going to perform work on or with each of the items, you potentially have a situation where parallelism can be exploited.  This is fairly easy to do in practice: look for iteration statements in your code, such as for and foreach.

Granted, every for loop is not a candidate to be parallelized.  If the collection is being modified as it’s iterated, or the processing of elements depends on other elements, the iteration block may need to be processed in serial.  However, if this is not the case, data decomposition may be possible.

Let’s look at one example of how we might use data decomposition.  Suppose we were working with an image, and we were applying a simple contrast stretching filter.  When we go to apply the filter, once we know the minimum and maximum values, we can apply this to each pixel independently of the other pixels.  This means that we can easily decompose this problem based off data – we will do the same operation, in parallel, on individual chunks of data (each pixel).

Task Decomposition, on the other hand, is focused on the individual tasks that need to be performed instead of focusing on the data.  In order to decompose our problem domain by tasks, we need to think about our algorithm in terms of discrete operations, or tasks, which can then later be parallelized.

Task decomposition, in practice, can be a bit more tricky than data decomposition.  Here, we need to look at what our algorithm actually does, and how it performs its actions.  Once we have all of the basic steps taken into account, we can try to analyze them and determine whether there are any constraints in terms of shared data or ordering.  There are no simple things to look for in terms of finding tasks we can decompose for parallelism; every algorithm is unique in terms of its tasks, so every algorithm will have unique opportunities for task decomposition.

For example, say we want our software to perform some customized actions on startup, prior to showing our main screen.  Perhaps we want to check for proper licensing, notify the user if the license is not valid, and also check for updates to the program.  Once we verify the license, and that there are no updates, we’ll start normally.  In this case, we can decompose this problem into tasks – we have a few tasks, but there are at least two discrete, independent tasks (check licensing, check for updates) which we can perform in parallel.  Once those are completed, we will continue on with our other tasks.

One final note – Data Decomposition and Task Decomposition are not mutually exclusive.  Often, you’ll mix the two approaches while trying to parallelize a single routine.  It’s possible to decompose your problem based off data, then further decompose the processing of each element of data based on tasks. 

This just provides a framework for thinking about our algorithms, and for discussing the problem.

Learning to write parallel software is challenging.  It requires more than reading that one chapter on parallelism in our programming language book of choice…

Today’s systems are no longer getting faster with each generation; in many cases, newer computers are actually slower than previous generation systems.  Modern hardware is shifting towards conservation of power, with processing scalability coming from having multiple computer cores, not faster and faster CPUs.  Our CPU frequencies no longer double on a regular basis, but Moore’s Law is still holding strong.  Now, however, instead of scaling transistors in order to make processors faster, hardware manufacturers are scaling the transistors in order to add more discrete hardware processing threads to the system.

This changes how we should think about software.  In order to take advantage of modern systems, we need to redesign and rewrite our algorithms to work in parallel.  As with any design domain, it helps tremendously to have a common language, as well as a common set of patterns and tools.

For .NET developers, this is an exciting time for parallel programming.  Version 4 of the .NET Framework is adding the Task Parallel Library.  This has been back-ported to .NET 3.5sp1 as part of the Reactive Extensions for .NET, and is available for use today in both .NET 3.5 and .NET 4.0 beta.

In order to fully utilize the Task Parallel Library and parallelism, both in .NET 4 and previous versions, we need to understand the proper terminology.  For this series, I will provide an introduction to some of the basic concepts in parallelism, and relate them to the tools available in .NET.

• A Windows Forms application
• A WPF Version of the application, using the same style
• A WPF Version of the application, built using MVVM

This allows a detailed understanding of the reasons behind MVVM, as well as the technology that enables the pattern.

The series is written in multiple parts:

• Introduction
• The Model
• Our Application In Windows Forms
• Our Application In WPF
• Data Binding
• Commands
• Templating
• MVVM
• Conclusion

Now that I’ve walked through how we do this, I will revisit our original RSS Feed Reader application, and show samples of how this changes the design and code in this simple application.

First, lets look at our Model.

Our Model classes, as expected, remained completely unchanged through all three versions of our software.  The same Model was usable by the Windows Forms application, our WPF application, and our WPF with MVVM version of our application.  This works because our Model described nothing but it’s own, domain specific information.  It took no dependencies on a presentation technology, and made no assumptions of how it would be used.

Next, lets begin by looking at our View.

In Part 7, I mentioned that we should keep a goal in mind for the View: The user interface should be declared entirely in XAML, with zero code behind.  Unfortunately, it’s impossible to have absolutely zero code, but we’ve managed to move our entire declaration of both our Window and our UserControl into XAML, so all that is left in the code is the constructor which calls InitializeComponent:

namespace RssMVVM.Views
{
    public partial class MainView
    {
        public MainView()
        {
            InitializeComponent();
        }
    }
}

In this example, we’ve succeeded in accomplishing our goal – we have no code in the code behind other than the automatically generated code that is required to initialize our UserControl or WIndow.

Our XAML changed, as well.  Instead of having nearly every element named in order to make them accessible via code, we now use data binding to bind directly to their values.  For example, in our original WPF version of our UserControl, the first set of TextBox elements was written like this:

<TextBox Grid.Row="0" Grid.Column="1" x:Name="textBoxTitle" />
<TextBox Grid.Row="1" Grid.Column="1" x:Name="textBoxLink" />
<TextBox Grid.Row="2" Grid.Column="1" x:Name="textBoxDescription" />

Now, in our MVVM version, we change this to:

<TextBox Grid.Row="0" Grid.Column="1"
  Text="{Binding Path=Feed.Title, Mode=OneWay}" />
<TextBox Grid.Row="1" Grid.Column="1"
  Text="{Binding Path=Feed.Link, Mode=OneWay, Converter={StaticResource StringToUriConverter}}" />
<TextBox Grid.Row="2" Grid.Column="1"
  Text="{Binding Path=Feed.Description, Mode=OneWay}"/>

At first glance, this may seem like extra work.  However, the second eliminates all of the code required to set and manage changes in the first (two entire methods).  The MVVM version also has a subtle, yet profound advantage over the first: the XAML code is exactly describing what will exist inside that text box.  This provides a level of self-documentation in your XAML, which fits in perfectly with it’s declarative nature.  In the original version, the only clue we would have to the TextBox’s purpose is the name we specified.

I will mention – I had to “cheat” here, to some extent.  There is one issue that was not easily resolved in porting this application to MVVM: the WebBrowser control.  Unfortunately, the WebBrowser control wraps a COM component, and is not a native WPF control.  I suspect that this led to an unfortunately design decision: WebBrowser.Source is not a standard WPF DependencyProperty, and as a result, can not be used with Data Binding like standard control elements.

There are at least two options for handling this situation.  We could have easily handled this by using code in the code behind file.  This would be a minor deviation from our goal, but as the goal of no code in code behind is a guideline, not a hard fixed rule, it would be a valid option.  However, there is another feature in WPF we can use in many situations such as this: Attached Properties.  In my case, I prefer to use attached properties, since this creates a tool that is easily reusable on any WebBrowser control.  By using an attached property, we can create a BindableSource property that allows us to use Data Binding with a WebBrowser, just by changing the XAML to:

<WebBrowser Grid.Row="2" RssMVVM:WebBrowserUtility.BindableSource="{Binding Uri}" />

The final change I introduced was the addition of a DataTemplate in the application’s XAML:

<Application.Resources>
    <DataTemplate DataType="{x:Type ViewModels:FeedViewModel}">
        <Views:FeedControl />
    </DataTemplate>
</Application.Resources>

This simple addition allows WPF’s templating to automatically construct and manage our View for the UserControl, saving us all of the code required to construct and place the control.

We made our clean View possible by introducing two ViewModel classes: MainViewModel and FeedViewModel.  Looking at our ViewModel classes, we see their simplicity.  Most of the code involved in our ViewModel class is nothing but a wrapper around our Model in order to allow it to properly implement INotifyPropertyChanged, and to handle the creation of our ICommand implementations.

The nice thing here, is we can see all of our logic, everything that the View is going to use, in one location.  There is nothing tied to a specific View here, so it is easy to generate unit tests for our ViewModel classes.  All of our logic is wrapped into a commands, and the rest of our ViewModel classes do nothing but wrap properties to properly handle INotifyPropertyChanged.

I purposely did not make custom styles for the WPF versions of this application.  That would be very easy to do, and potentially could make the WPF versions of this application much better looking and more usable.  Though it would be a fun and easy exercise, the main goal of this series is to demonstrate how the code itself can be changed in order to make maintaining and redesigning the application simple – not how to make a beautiful designed user interface.

The Visual Studio Solution used in this article, with full source code, is available on MSDN Code Gallery.  I encourage you to download and compare all three versions of the RSS Feed Reader application in detail.  The progression of this application, and the advantages it brings, will be much more noticeable when looking at the full source code.

Windows Presentation Foundation has a lot to offer every application developer.  By taking advantage of its unique features, we can build our applications in a way that is maintainable, testable, designable, and simple to implement.  The Model-View-ViewModel design pattern provides a clean pattern we can use improve our efficiency as developers.

As I mentioned in the section on templating, WPF’s design strives to maintain a clear separation between presentation and logic.  We’ve seen some of the advantages in terms of control creation – unlike Windows Forms, we can completely change the way a control looks merely by creating a new template, using XAML in a completely declarative form.  No code is required.  We get more flexibility with less work.  By separating presentation and logic, WPF creates opportunities for much greater degrees of flexibility in our applications.

As a developer, I see this as a very “good thing”.  The Model-View-ViewModel pattern has one goal – to extend this same flexibility into our applications by creating and maintaining a clean separation of concerns through our entire application.

In order to understand MVVM, I will start off by defining our distinct concerns, the individual “parts” of our application. 

I already defined our arguably most important concern: the Model.  Again, the Model is the domain-specific data and logic used within your application.  It’s the goal – the “data” you’re working to expose to your users.  This may be customer records in a database, or product information on a website, or anything else.  In our case, it’s two classes, the Feed and the FeedItem class.  In Model-View-ViewModel, our goal is to keep the model unaware of the specific application or technology that’s using it.  The Model knows about itself, and nothing else.

The second concern I’ll discuss is the View.  The View is the entire user interface of your application – it’s everything the user’s interact with directly: every control, every button, every check box, every window.  As I mentioned in part 3, WPF changes how the View is normally defined.  Instead of developing the user interface via code, we use XAML to create an XML-based, declarative description of the interface.

Let’s review our goal of maintaining a full separation of presentation and logic, this time just in terms of the View.  When we create our user interface, we want to define what the user will see (presentation) without worrying about how the program works (logic).  XAML is perfect for this, as it lets us design the user interface with zero code involved.  This gives us an easy way to think about our View in terms of our goal: The user interface should be declared entirely in XAML, with zero code behind.

Succeeding in this goal has many advantages.  It makes the View very flexible – a designer can take our View and stylize it or change it in any way desired, without changing or effecting a single line of code.  Also, if there is no logic in the View itself, it eliminates the risk of “stale” or unused code creeping into the View, which often happens in Windows Forms.

Now that we have the View and the Model defined, we need a way to hook the two things together.  Something has to coordinate our actions between the Model and the View, so that the user’s interaction has an effect on the Model.  This is handled by our third concern: the ViewModel.

The ViewModel serves the purpose of adapting the Model to be directly usable by the View.  In order to do this, we take advantage of WPF’s incredible Data Binding support.  In MVVM, the ViewModel sits between the View and the Model, and basically acts similar to an Adapter – it translates the properties and methods of the Model to a form that can be directly used via Data Binding.

The ViewModel also provides us a place to manage application state and logic.  By taking advantage of WPF’s Commanding Infrastructure, we can define ICommand instances in the ViewModel that the View can directly access via Data Binding.  This provides us a clean way to keep the logic out of the View – again, the View works completely via Data Binding to the ViewModel.  This provides a means by which we can hook into logic from the View without having the logic be tied to the specific view that is using it.

Here is a diagram illustrating our three areas of concern:

There are some important aspects of this diagram I will discuss, for each of our Concerns, some critical points

• The Model
  • The Model is unaware of anything except itself
  • The Model could be used by any form of program, and is not tied to a specific framework or technology
• The View
  • The View is defined entirely in XAML
  • The View only needs to know what to bind to, by name.  It does not need to know anything about what will happen when properties change or commands are executed.
  • The View’s state is completely based upon data binding
• The ViewModel
  • The ViewModel knows nothing about the View
  • The ViewModel directly interacts with the Model, in order to expose it for data binding
  • The ViewModel manages the Application-specific information

The advantages here are profound:

Our Model, since it is self contained, can be used in any way we wish.  If, later, we decided we needed a web-based API to the same model, we could use the Model unchanged.  If the successor to WPF comes along, and we need to update our application to use it, the Model remains unchanged.

Our View, since it has no logic, is completely designable.  The View can be modified by a designer with little or no programming experience, with no fear of breaking the logic.  The only knowledge that the designer needs to know is what properties and commands are available, and their names – everything else is handled directly by the framework to make it work.  This leads to a tremendous amount of flexibility in the View – the entire look and feel of an application can be changed at any time.

Our ViewModel gets a nice advantage from this architecture, as well.  Since it is not tied to a specific View, it is very easily testable.  The logic of our application is all exposed through self-contained ICommand implementations, which are easy to test.  The data is exposed via properties; again, easy to test.

There is still one issue left to resolve, though.  At this point, we know how to architect a single window or form correctly – the Model is used by the ViewModel, and the View “hooks” into the ViewModel with data binding.  This works great for a single user control – but we still need to create and wire up the controls in the first place.

At first glance, it seems like we’d need to know about the View and the ViewModel in order to do this.  For the ViewModel to be used as a binding source, it needs to be set as the DataContext of the correct View.  We need a way, given a ViewModel, to construct a View and set its DataContext.  In order to do this, we break one of our rules – the ViewModel, in order to construct the View, needs to know about the Views.

WPF, again, provides us with the final tool required for MVVM: Templating.  The same mechanism that our ListBox used when we discussed templating can be used for our ViewModel.  Instead of trying to construct our View, we can setup a simple DataTemplate that specifies that our View is used to render our ViewModel.  This will look similar to:

<DataTemplate DataType="{x:Type local:OurViewModel}">
    <local:OurView />
</DataTemplate>

This DataTemplate tells WPF that, any time we say to directly render an instance of OurViewModel, it should construct an instance of OurView, place it at that location, and set the DataContext of the OurView instance to the instance of OurViewModel.  Basically, WPF will do all of the work for us, just be specifying a DataTemplate.

Since DataTemplates are definable in XAML, and will propagate downwards through the Visual Tree in WPF, this lets our View automatically set itself up.  All that needs to happen is to provide a ContentPresenter in our View which binds, using standard DataBinding, to a ViewModel, and WPF will do all of the plumbing for us!

WPF adds three profound features: Data Binding, Commands, and Templates.  By using these three feature sets appropriately, we can redesign the architecture of our applications by using the Model-View-ViewModel pattern. This maintains a clear separation of concerns, allows for easy changes and redesign of the View, provides good testability, and keeps our domain specific classes completely isolated.

… Continued in the Conclusion …

Windows Presentation Foundation, in its design, strives to keep a clear separation of presentation and logic.  This is apparent throughout its architecture, but perhaps most notable in one of the core building blocks of every WPF application: the Control class. 

Controls, in WPF, have two completely separate parts.  There is the logical portion, and then there is a ControlTemplate that defines how the control is represented visually; how the control looks.  The difference in thinking, even in this core element, is apparent from the documentation.

Here is how the Control class in Windows Forms is described in MSDN:

Defines the base class for controls, which are components with visual representation.

Compare that to the Control class in WPF:

Represents the base class for user interface (UI) elements that use a ControlTemplate to define their appearance.

Note the difference here.  Even the most basic definition of a “Control”, the core component used to build applications, has changed in Windows Presentation Foundation.  In Windows Forms, when you defined a control, you defined everything about the control directly.  Take a button – a button not only had to deal with the fact that it has behavior (its something visual on which you click, which in turn triggers behavior) – it also directly handled its own rendering.  Typically, if you wanted to make a Button that looked dramatically different from the standard button, you’d make a custom control (ie: a separate class), where you’d handle, not only the button’s behavior, but also all of the code required to paint the customized button.  In WPF, making custom controls is much less common – instead of making a separate class for the new button, you could just make a custom Style, a ControlTemplate which completely changes the way the button is rendered.  However, the behavior of the button is the same, since it’s still uses the standard “Button” class.

This is the key to making WPF applications highly designable – it’s very easy to allow a designer to go in and completely customize the look and feel of every part of your application without introducing custom controls.  Many people tout this as WPF’s advantage over Windows Forms, as well as nearly every other preceding UI technology.

In our case, however, we’re interested in how to architect our application from a code standpoint, not how to make it pretty.  The styling and templating engine in WPF provides another very critical component: the DataTemplate.

Data templates are most often used by WPF controls whose purpose is to display a collection of items.  These typically are the classes that derive from ItemsControl, such as ListBox and TreeView.  For our purposes, lets look at ListBox.

In Windows Forms, when you had a ListBox, by default it just displayed a list of items as text.  Changing this required creating an owner drawn list box, which was a challenge, even for a simple change in style.  This requires handling your own GDI+ drawing using the Graphics class, and pushed everything into code that is difficult to write and maintain.

In WPF, this is handled by a DataTemplate.  By default, you can bind a collection of any objects to a ListBox, and the ListBox will list the results of calling Object.ToString() on each element of the collection.  Custom drawing is handled very easily by using a DataTemplate.  In the Styling and Templating example, the DataTemplate creates a Border with a nested Image, bound to the Source property of each element.  This causes the ListBox to display a list of Images.

In our RSS Feed Reader, we use the same technique to display a list of FeedItems.  Our ListBox is bound directly to a list of our RssModel.FeedItem class, and without a DataTemplate, we see:

However, in our UserControl, we added a very simple DataTemplate:

<DataTemplate DataType="{x:Type model:FeedItem}">
    <TextBlock Text="{Binding Path=Title}" />
</DataTemplate>

This causes our display to change.  Now, instead of just listing the class name (the default behavior of ToString() on our RssModel.FeedItem class), we display a TextBlock containing the FeedItem’s Title property:

This is much nicer, and very simple to implement. 

DataTemplates, however, go far beyond just displaying Text – we could have displayed borders, images, text, or any other complex item we wished, merely by specifying a template in our UserControl.  The idea behind a DataTemplate is that you specify, in XAML, how any object should be represented visually.  This lets us tell the user interface to directly render a custom class, without the code needing to know or worry about the class being rendered properly.

In our case, we used that to customize the display of a list of FeedItems.  The MSDN sample displayed a list of Photo classes using pictures surrounded by a border.  This flexibility is the key to rethinking our architecture, and in our final installment, I’ll delve into how and why this should change the way you think about designing client applications.

… Continued in Part 7, MVVM …

It does this by providing a unified model for separating the originator of an action from the effect produced by the action, via the Commanding infrastructure.

Commands in WPF are a very powerful abstraction.  MSDN clearly states the goals of the commanding infrastructure:

What makes commands different from a simple event handler
attached to a button or a timer is that commands separate the
semantics and the originator of an action from its logic.
This allows for multiple and disparate sources to invoke the
same command logic, and it allows the command logic to be
customized for different targets.

This follows a simple, but pervasive goal in WPF – separation of logic from presentation.  In the case of commands, the goal is to decouple an “action” from the object on which its working, as well as from the user interface element that triggers the action.

Also MSDN’s Commanding discussion focuses on the RoutedCommand implementations, for our purposes, we’ll use the ICommand interface directly.  ICommand is a simple interface, and it provides two functions:

1. Provide a means (CanExecute method) to determine whether an action can be run in the current context, as well as a way to track when this changes (CanExecuteChanged event).
2. Provide a method (Execute) to perform a given action

By providing this in a simple interface, we can make our own class which wraps this functionality into any series of delegates.  In our case, we made an ICommand class called ActionCommand, which lets us do some nice things.

For example, in the DataContext we use for our specific feed information UserControl, we start off by defining an ICommand as a property:

/// <summary>
/// Gets the open feed command.
/// </summary>
/// <value>The open feed command.</value>
public ICommand OpenFeedCommand
{
    get;
    private set;
}

We then initialize this directly using:

this.OpenFeedCommand = new ActionCommand(this.OpenFeed, () => true);

Basically, this provides us a Property, directly on our DataContext, that lets us call an OpenFeed method.  Also, since we can now directly expose the SelectedFeedItem due to Data Binding (as discussed in part 4), we simplify our logic as well.

Now, in our code, we can replace our event handler:

private void ButtonOpenLink_Click(object sender, RoutedEventArgs e)
{
    if (this.Feed != null)
    {
        FeedItem item = this.Feed.Items[this.listBoxFeeds.SelectedIndex];
        if (item != null)
        {
            System.Diagnostics.Process.Start(item.Link.AbsoluteUri);
        }
    }
}

With a dramatically simplified OpenFeed method:

private void OpenFeed()
{
    if (this.SelectedFeedItem != null)
    {
        System.Diagnostics.Process.Start(this.SelectedFeedItem.Link.AbsoluteUri);
    }
}

Our XAML will change, so instead of using the event handler, we switch to specifying the Command for our button directly, using WPF’s DataBinding:

<Button
   Grid.Row="1" Grid.Column="1" Height="23"
   HorizontalAlignment="Right" Margin="0,0,0,0"
   VerticalAlignment="Top" Width="60"
   Command="{Binding OpenFeedCommand}">
Open
</Button>

Note the differences here in approach – we’re accomplishing the same goal (hooking our code into the button being clicked by the user), but in a very different way.

In Windows Forms, and even in WPF when we use the event approach, we’re directly handling the button’s click event, and our logic gets mixed with the fact that we’re using a button in the interface.  If we were to change from a button to a menu, or a hyperlink, or some other control, we’d have to change our code to handle the different type of event, and move our logic across.  The code is always aware of what control is triggering some action.

Now, by using an ICommand, we’re doing something different.  What we are accomplishing here is making two statements in our code:

1. Our user should be able to call a command to Open a feed (OpenFeedCommand)
2. The OpenFeedCommand performs this function (launches the browser with the feed’s URI).

Nothing in the code knows how this command will get invoked – it can be from a button’s click (as it is here), but it could just as easily be triggered by any ICommandSource, including a Hyperlink, MenuItem, or even a KeyGesture.

The important point here is that the code does not know, or care, what triggered it.  We could rework the user interface to use completely different controls without changing one line of C# code, because we decoupled the action from what triggered the action by using a Command.

… Continued in Part 6, Templating …

The first new concept in WPF I’ll introduce is the new, more powerful, more flexible model for Data Binding.

Windows Presentation Foundation provides an entirely new form of Data Binding than previous data binding technologies.  Data Binding existed in Windows Forms, but was limited to being bound to pretty specific data sources.  Many developers have used data bound controls prior to WPF, but the way data binding works in WPF has changed.  The data binding support in WPF adds the potential to use completely different programming models than we used previously.

So lets start with explaining data binding, in general terms.  Data binding is a general purpose technique that lets you take two (or potentially more than two) separate elements, and “bind” them together so that their values stay synchronized.  Typically, a control in the user interface (like a text box or a label) is bound to a property on some object containing your business logic.

The advantages of this should be obvious pretty quickly, provided this works correctly.  However, previous attempts at data binding have all fallen short when it came time to use them in practical, real-world problems.  I believe this comes down to the inability of most data binding frameworks to handle everything required.  For data binding to truly be effective, a binding framework should provide the following.

• An easy way to bind user interface elements to data sources
• A clean way to specify a data source for an entire collection of objects
• A consistent way to specify bindings, no matter what is being bound
• Allow flexibility in what triggers updates
• An effective means of validation of values
• The means to do conversion of the data through the binding itself

Most frameworks for data binding have provided some, but not all, of the features available above.  I’m going to address the above bullet points, and show how WPF provides for clean data binding.  We’ll start with the first three points:

• An easy way to bind user interface elements to data sources
• A clean way to specify a data source for an entire collection of objects
• A consistent way to specify bindings, no matter what is being bound

Nearly all user interface items in WPF derive from FrameworkElement.  Whenever you create a Window or a UserControl in WPF, you have the option of specifying any object as the Framework Element’s DataContext.  The DataContext property specifies “the data context for an element when it participates in data binding”.  Whenever an object has a DataContext specified, you can use WPF’s data binding to bind directly to properties defined on that object.

There is a very important line in the documentation for DataContext:

This dependency property inherits property values. If there are child
elements without other values for DataContext established through local values
or styles, then the property system will set the value to be the DataContext
value of the nearest parent element with this value assigned.

What this means is that you don’t have to specify the DataContext for every element in your Window or UserControl.  You can specify the DataContext for a UserControl, and, by default, every control inside of the UserControl will automatically use that same DataContext for data binding!  This is incredibly powerful.

For example, in both our Windows Forms and WPF (version 1) applications, we had a UserControl defined for displaying information about our Feed object.  Whenever we’d update our Feed object, we would write a bunch of code triggered by setting our property to update our UI, such as:

// .. Called when Feed changes to update the user interface
    this.textBoxTitle.Text = this.Feed.Title;
    this.textBoxLink.Text = this.Feed.Link.AbsoluteUri;
    this.textBoxDescription.Text = this.Feed.Description;

By using data binding, we can completely eliminate this code.  Instead of doing this, we could, for example, just set the DataContext of our UserControl to the Feed object itself.  Once we’ve done that, we can just specify, in our XAML (which can be done in the designer), which property in our DataContext which we want to bind to our individual TextBox controls:

<TextBox Grid.Row="0" Grid.Column="1" Text="{Binding Path=Feed.Title, Mode=OneWay}" />
<TextBox Grid.Row="1" Grid.Column="1" Text="{Binding Path=Feed.Link.AbsoluteUri, Mode=OneWay}" />
<TextBox Grid.Row="2" Grid.Column="1" Text="{Binding Path=Feed.Description, Mode=OneWay}"/>

Now, all of a sudden, we have full, up to date user interface controls, and we can completely eliminate two entire methods (ResetFeed and ClearFeed) from our code!  Less code means less to maintain, less to test, and less to worry about.  Our TextBox instances don’t have a DataContext specified, so they automatically inherit the DataContext of the UserControl (since that is the first parent element with a DataContext provided).  They then bind directly to the property of the object in the DataContext.

This solves our first three bullet points – we can bind to any object (*see note below) using declarative syntax (in XAML), and we can specify the object one time, at a high level such as a Window or UserControl, via FrameworkElement.DataContext.

Let’s move on to the next two points:

• Allow flexibility in what triggers updates
• An effective means of validation of values

Windows Presentation Foundation provides the means to handle this, as well.  Again, with no changes to our code, we can declaratively add support for both of the above bullet points.

First, what triggers an update to the binding can be specified, in XAML, by providing an UpdateSourceTrigger.  This lets us say, explicitly, that we want the property to update every time we type a letter into a TextBox (by setting the trigger to “PropertyChanged”), or only when the control loses focus (“LostFocus”).  In addition, UpdateSourceTrigger lets us explicitly handle property updates, even though this is not as commonly used.

Validation can be handled, and again specified declaratively by using XAML, in multiple ways.  I do not want to cover Validation here in detail, but it is discussed in detail on MSDN.  One or more ValidationRules can be attached to a Binding, allowing for great flexibility in data validation.

Let’s look at our final point:

• The means to do conversion of the data through the binding itself

Using WPF, we have the ability to bind objects of any type to a control, even if the type wouldn’t normally (directly) be editable or displayable within a control.  WPF allows you to specify a converter to use to convert from the source type to the editing type, as well as handling the conversion back.  This is done via IValueConverter.  By specifying your own value converter, you can bind, via both OneWay or TwoWay binding, any control to any type of object.  For example, above, we bound our TextBox to “Feed.Link.AbsoluteUri”, which is a string.  However, if the AbsoluteUri property didn’t exist, we could write a converter to convert from a Uri to a string, and use that in our data binding.  This would allow us to bind directly to “Feed.Link”, as follows:

<TextBox Grid.Row="1" Grid.Column="1">
    <TextBox.Text>
        <Binding Path="Feed.Link" Mode="OneWay">
            <Binding.Converter>
                <RssMVVM:StringToUriConverter />
            </Binding.Converter>
        </Binding>
    </TextBox.Text>
</TextBox>

This is critical to the flexibility of WPF’s data binding – we’re now directly binding a string (the TextBox.Text property) to a custom class (Uri).  We can now data bind to any type of object, which allows us to do very complex operations.  For example, we can now display different images for Enum values (by having a converter that converts from the Enum value to an image).

To summarize, the data binding in Windows Presentation Foundation provides us with a simple, clean, powerful, and flexible means of displaying our properties inside our user interfaces, as well as automatically updating our properties when the user edits values within controls in our user interfaces.  In addition, it does it in a way that’s completely declarative, with no code required.

* Although you can bind to any object, there are certain types of objects that work better.  In particular, any object that implements INotifyPropertyChanged or derives from DependencyObject will allow for TwoWay binding to work properly.  Collections should implement INotifyCollectionChanged or IBindingList in order to allow for proper TwoWay binding, as well.  This isn’t a requirement, but it is worth mentioning, since it has a large impact on usability.

… Continued in Part 5, Commands …

The first thing you’ll notice when working with WPF is the change in how the designer works.  The same concepts are there – you can drag controls onto a Window or a UserControl, and move them around, perform layout, etc.  There are some differences in how things work, especially in regards to layout, but for the most part, a developer can still open a window, drag in controls, and place them using the same basic technique as the Windows Forms designer.

However, when this is done, the designer does something very different.  In Windows Forms, the designer wrote our code for us; it created a partial class, and in the .designer.cs file, we got all of the code required to programmatically create our user interface.  This fit well with Windows Form’s imperative programming style.  The WPF designer, on the other hand, builds its user interface by creating .xaml files instead, using the Extensible Application Markup Language.  Microsoft describes XAML as “A Declarative Language with Flow Control Support”; the key word here is “declarative.”  WPF uses a declarative programming model, at least for the creation of the user interface.  Instead of specifying the steps required to build the user interface, the compiler uses a markup file (based on XML) that describes what should be displayed, not how to display it.

This is the single, fundamental change in thinking required to use WPF.  Even then, this is handled completely by the designer, so technically, you can build an entire user interface and never even look at this, just as you could build a Windows Forms user interface and never look at the designer file.

WPF also provides similar, often identical, events on controls for each control type.  For example, Button provides a Click event, to which you can subscribe.  The TextBox control provides a Text property you can set. This lets you wire up your event handlers in a manner that is nearly identical to Windows Forms.

For this part of our Series, we’re going to demonstrate this.  We’re going to write the same application we wrote using Windows Forms in Part 2, this time, using WPF.

First thing to notice – the application looks very similar:

The main differences are due to changes in the default styling of WPF’s controls vs. those of Windows Forms.  Functionally, the application is identical.  It uses the same Model classes, completely unchanged.  I performs the same functions, with the same basic behavior.  We even structured it the same way, using a UserControl for the center section of the Window.

When we look at the code, we find something even more surprising – the code is nearly identical to our Windows Forms application!

For example, our “Load RSS Feed” button in our main Window class has a click event handler attached to it, and just like our Windows Forms application, it does nothing but load the Feed using the Model, and set a property in the UserControl.  The only difference here is in the declaration of our method: instead of passing EventArgs e, we now pass RoutedEventArgs e.  Otherwise, the code is identical:

private void ButtonUpdateFeed_Click(object sender, RoutedEventArgs e)
{
    this.feedControl.Feed = Feed.Read(new Uri(this.textBoxFeedUrl.Text));
}

Just like before, this sets the “Feed” property within our UserControl, but this time, the code in our UserControl is exactly the same as our Windows Forms code!  We were able to copy the code, with absolutely no changes, from Windows Forms to WPF.  Here is a small subset of that code, just to demonstrate that it hasn’t changed:

// ... previous code from Windows Forms application
    this.textBoxTitle.Text = this.Feed.Title;
    this.textBoxLink.Text = this.Feed.Link.AbsoluteUri;
    this.textBoxDescription.Text = this.Feed.Description;

    foreach (var item in this.Feed.Items)
    {
        this.listBoxFeeds.Items.Add(item.Title);
    }
// ... continue with code from Windows Forms application

In fact, when we look at our UserControl’s code behind file (the file that ends in .xaml.cs), the only differences we have between our WPF code and our Windows Forms code, through the entire Window and UserControl, are subtle differences in the method declaration, and setting “.Source” instead of “.Url” in our Main window, since WPF has different delegate declarations for its events and some subtle differences in control APIs.  Otherwise, the code we wrote is identical, to the letter.

Windows Presentation Foundation, though new, does not force us as developers to change our programming style.  We can do things the way we’ve always done them in Windows Forms, and continue forward with newer technology.  We can even mix and match Windows Forms and WPF via ElementHost and WindowsFormsHost, which let us host WPF inside Windows Forms and Windows Forms inside WPF.

Here are the important points to realize from this part of the series:

• Although WPF is a completely new API, you can use the same event-driven programming style that you used in Windows Forms.
• Most of the “new” features in WPF are optional.  WPF can make a real application using the same techniques as Windows Forms, only now, some of the interface is defined declaratively instead of being entirely imperative.

Hopefully, this mitigates some of the concern and fear of moving from Windows Forms to WPF.  There really is no reason to avoid using Windows Presentation Foundation, even if I haven’t described (yet) the compelling reasons to migrate, and the numerous advantages of WPF.

… Continued in Part 4, Data Binding …

When Microsoft first developed and released .NET, they provided a very clean, simple API for creating Windows applications based upon existing technologies: Windows Forms.  The Windows Forms programming model is an event based programming model.  This matches very well with prior Microsoft technologies, such as ATL and MFC, since the core of Windows Forms wraps around controls defined in the Windows API.

In Windows Forms, you start with a “Form”, which corresponds to a Window in the desktop.  The form contains multiple controls, each done via a wrapper around the Controls in the Windows API.  Each control provides its own window handle (HWND, via Control.Handle), which is basically a separate Window.  When the application starts, you create a windows message pump by calling Application.Run, which maps the standard windows messages to their appropriate controls, which in turn raise events in the code for the Form.

In addition, a full designer was built which takes care of the initialization of the form, so the developer can graphically layout their controls on a form, and the appropriate C# code will be generated (inside the InitializeComponent method) on the fly.  It will add event handlers for the developer, and map them to methods in the Form’s .cs file automatically, making the creation of quick GUIs very easy.

Microsoft also provided a means of compartmentalizing a form, breaking it into more managable, smaller pieces of functionality called a UserControl.  A UserControl is basically the “guts” of a form that you can drop into another form, allowing both reuse in multiple forms, but also separation of logic into pieces to prevent a form from getting too large, in terms of code.

This is a very similar, comfortable model for developers who have used MFC, VB6, or even Delphi.  The implementation details are slightly different, but the basic conceptual model was unchanged – design a form, hook up events, handle the events, always working with the message pump in code.  This made adoption of the Windows Forms model very fast – it was familiar, and easy to transition from other technologies to Windows Forms.

For our series, we’re going to start here.  Taking our Model, the Feed and FeedItem classes described previously, we’re going to wire up a simple RSS Feed Reader application using Windows Forms. 

This is a very simple application.  For our purposes, the application must:

• Load the feed using the Model
• Display the basic information about the Feed
• Display the list of FeedItems in the Feed
• Let the user choose a specific FeedItem
• Allow the user to open a FeedItem’s original source in their browser
• Display the FeedItem in a wrapped browser

Here is a screenshot of our completed Windows Forms application:

There’s nothing fancy in this application, and the code should look very familiar to anyone who’s used Windows Forms.  So, let’s look at how this works internally…

The “Feed Information” and “Select a Feed Item” section are broken into a separate UserControl for demonstration purposes.  The user interface was completely generated inside of a designer, and the code was written for us. 

When the user clicks on “Load RSS Feed”, a small event handler is run:

private void ButtonUpdateFeed_Click(object sender, EventArgs e)
{
    this.feedControl.Feed = Feed.Read(new Uri(this.textBox1.Text));
}

This sets the “Feed” property within our UserControl to a Feed (our Model).  The UserControl has a “Feed” property, which specifies some code to run when the Feed is updated:

public Feed Feed
{
    get
    {
        return this.feed;
    }

    set
    {
        this.feed = value;
        this.ResetFeed();
    }
}

This, in turn, calls the ResetFeed() method, which first calls ClearFeed() to cleanup the current UI, and then sets values inside each control:

private void ResetFeed()
{
    this.ClearFeed();

    if (this.Feed == null)
    {
        return;
    }

    this.textBoxTitle.Text = this.Feed.Title;
    this.textBoxLink.Text = this.Feed.Link.AbsoluteUri;
    this.textBoxDescription.Text = this.Feed.Description;

    foreach (var item in this.Feed.Items)
    {
        this.listBoxFeeds.Items.Add(item.Title);
    }
}

private void ClearFeed()
{
    this.listBoxFeeds.Items.Clear();
    this.textBoxTitle.Text = string.Empty;
    this.textBoxLink.Text = string.Empty;
    this.textBoxDescription.Text = string.Empty;
    this.textBoxItemTitle.Text = string.Empty;
    this.textBoxItemLink.Text = string.Empty;
    this.textBoxItemDescription.Text = string.Empty;
}

Our user control gets filled in with all of the feed information by us.  When the user chooses a feed in the ListBox control, we handle it via another event handler:

private void ListBoxFeeds_SelectedIndexChanged(object sender, EventArgs e)
{
    FeedItem item = this.Feed.Items[this.listBoxFeeds.SelectedIndex];
    this.textBoxItemTitle.Text = item.Title;
    this.textBoxItemLink.Text = item.Link.AbsoluteUri;
    this.textBoxItemDescription.Text = item.Description;

    if (this.UriChanged != null)
    {
        this.UriChanged(this, new UriChangedEventArgs(new Uri(this.textBoxItemLink.Text)));
    }
}

When our selected feed item changes, we update the feed item’s controls, and also raise an event on our UserControl.  Our main form subscribes to this event, and uses it to update the WebBrowser control sitting underneath our UserControl in the Form.

Finally, we have a button labeled “Open”, which has an event handler attached to it to open the Feed in our browser:

private void ButtonOpenLink_Click(object sender, EventArgs e)
{
    if (this.Feed != null)
    {
        FeedItem item = this.Feed.Items[this.listBoxFeeds.SelectedIndex];
        if (item != null)
        {
            System.Diagnostics.Process.Start(item.Link.AbsoluteUri);
        }
    }
}

This should look familiar to most Windows Forms programmers.  There are other ways to write this type of code, but this is very common, and seems quite indicative of how many Windows Forms programs are written.  This is by no means meant to be a perfect example of a great Windows Forms application, but rather a typical, common way this application could have been written.

There are some important things to realize here. 

• All of our logic is handled in events, triggered by the user interacting with the user interface in our Window.
• Although the Windows Forms designer provides a nice interface, if you actually examine the code, the entire user interface is defined imperitively, whether by us or by the designer.
• The code, and therefore the logic, is really dependent on the type of control being used.  For example, if we changed from a ListBox to some other type of control, we’d most likely need to change the code to compensate

… Continued in Part 3, Our Application in WPF …

When we discuss software architecturally, the core elements of our program are the “Model”.  The terminology comes from architectural design patterns, and goes back pretty far.  The “Model” is the one thing in most user interface patterns that hasn’t changed, and is the same terminology used all the way back with Smalltalk in the 70’s when Trygve Reenskaug first described the Model-View-Controller pattern.

When we’re talking about the Model, we’re talking about the domain-specific data and logic – the “guts” inside the program itself.  In an ideal world, the program should be able to, at least theoretically and architecturally, work without the user interface being present at all, provided it has the appropriate information passed to it.  The core business logic, in an ideal world, doesn’t need or want to know anything about how it’s being used – that’s outside of its concern.

Your business logic should know about your business, and nothing else.  This is key to maintaining an effective separation of concerns within the design of our program.  This is also very useful for maintaining a program over time.  Keeping the model separate makes it much easier to extend an application into other realms without duplication of code or breaking a deployed application.  For example, if your business logic is completely isolated, you could potentially switch, without changing your business logic, from using a desktop, client-side application to using a command line, script based version of your application.  In some situations, you can even take the same logic and host it, accessing it remotely via a web page.

In most cases, its easiest to think of the Model as the data.  If you are making an application to edit customer information, the customer information (data) is the Model.  The model can also encapsulate logic, however.  If you have a service that needs to be called as part of your business logic when data is updated, the service itself can be thought of as part of the model.  When you talk about your program, when you discuss what functions the program performs, such as it “works on” this (data) or “performs this task” (logic), you are talking about the model.  Any time you discuss how the user interacts with the program, however, you are talking outside of the concern of the Model.

I want to mention, as a side note, one other thing here, that I often see as a point of confusion.  If you have an application with a full, multi-tier data access layer, all of the data access and logic layers are part of (or under) the Model.  For our purposes, we treat data and logic tiers as an internal, private implementation detail of the Model.  Here, the business logic layer acts as the Model’s public API, and we use that as our Model.  Presentation is separate from the Model, but the things the user "works on" (the data and domain specific logic to manipulate the data) are part of the Model.

For our series, we’re going to work with a simple program that is just an RSS feed reader.  When we’re talking about the feed reader applications, all three versions of our application we will develop use the same Model.  The public API of the Model is nothing but 2 classes: a Feed and a FeedItem.  The Feed class has some properties (Title, Description, etc), as well as a collection of FeedItem instances.  The FeedItem class contains properties for information about each item in the feed, including a Title, a Link to the original item, and a Description of the feed item.  The Feed class also has some logic – it has a static method that allows it to create a Feed given a Uri.

There is one important thing to remember about our Feed and FeedItem classes – they just describe data, and provide a means to load it.  They do not describe, in any way, how to edit or display the data.  Because the Model is all about data, and not about presentation or manipulation of that data by the user, we can use the same assembly, unchanged, in all three versions of our application.

… Continued in Part 2, Our Application in Windows Forms …

I feel that the confusion around choosing WPF really stems from a lack of understanding about WPF.  Even people on my own team have been overwhelmed trying to understand how the different pieces of WPF fit together, and how to apply the new concepts introduced with WPF effectively.  In order to address this, I’m going to break this down into a few simple pieces, and show the migration in terms of thought required to transition from being a good Windows Forms developer to an effective WPF developer.

Windows Presentation Foundation is huge.  Do not doubt it.  It is huge, both in terms of scope, but also in terms of the radically different approach it takes to developing user interfaces than other technologies.  Don’t let the scope frighten you, however – it is very well thought out, and very usable, once you understand some of the basic concepts.

In addition to the huge scope of WPF, new design patterns have evolved to take advantage of the new features introduced by this framework.  The most commonly referenced one, in terms of WPF, seems to be MVVM, or Model-View-ViewModel.  The Model-View-ViewModel pattern was inspired by some of the features in WPF, and seems perfectly fit for WPF, so many developers advocate it (with good reason) for use with WPF.

Again, don’t let this frighten or discourage you… MVVM isn’t about making WPF more difficult, it’s about making WPF usable in a quick, efficient manner.  Learning MVVM actually makes understanding WPF easier, not more difficult.

The issue here is that WPF is large, and the framework doesn’t force you into a single way of working.  There are lots of ways to work with WPF, including doing nearly the exact thing you’re used to with Windows Forms!  This is part of the power and flexibility of WPF, but also a trap to watch for and to avoid.  MVVM helps guide and force you to take advantage of WPF’s new features effectively, insulating you from common pitfalls and mistakes.

For this series, I’m going to start by showing a simple Windows Forms application – an RSS Feed Reader, and demonstrate converting it to WPF.  I’ll start with a strait conversion – and demonstrate how you can make WPF look and work exactly the same as you can with Windows Forms.  I’ll then explain, in details, some of the new ways of thinking that are pervasive within WPF, and show how this should change your way of thinking about user interfaces.

In order to do this, we’ll work with four separate projects – which include three completely different versions of the same application.  The goal here isn’t to use WPF to make the application “pretty” or “flashy”, rather, it’s to show how you can use WPF to make an application more developer friendly, including making it cleaner, more logical, easier to maintain, and more testable.

… Continued in Part 1, The Model …

The key to this is the TaskScheduler.FromCurrentSynchronizationContext() method.  This method creates a scheduler from the current SynchronizationContext, automatically choosing the appropriate context.  This scheduler can then be used by nearly all of the TaskFactory methods to generate a task.

As an example, here is a very simple Form.Load event handler for a demo Windows Forms application which creates a task which will execute in the background when the form loads.  The task runs some (fake) work, and occasionally uses tasks, as well as a continuation task, to update the user interface.

private void Form1_Load(object sender, EventArgs e)
{
    // This requires a label titled "label1" on the form...
    // Get the UI thread's context
    var context = TaskScheduler.FromCurrentSynchronizationContext();

    this.label1.Text = "Starting task...";

    // Start a task - this runs on the background thread...
    Task task = Task.Factory.StartNew( () =>
        {
            // Do some fake work...
            double j = 100;
            Random rand = new Random();
            for (int i = 0; i < 10000000; ++i)
            {
                j *= rand.NextDouble();
            }

            // It's possible to start a task directly on
            // the UI thread, but not common...
            var token = Task.Factory.CancellationToken;
            Task.Factory.StartNew(() =>
            {
                this.label1.Text = "Task past first work section...";
            }, token, TaskCreationOptions.None, context);

            // Do a bit more work
            Thread.Sleep(1000);
        })
        // More commonly, we'll continue a task with a new task on
        // the UI thread, since this lets us update when our
        // "work" completes.
        .ContinueWith(_ => this.label1.Text = "Task Complete!", context);
}

The beauty of this may not be apparent at first glance, but look closely at the threading methods.  They work with the SynchronizationContext instance, which was generated by the TaskFactory for us.  Nowhere do we explicitly say to use Control.Invoke or any other Windows Forms construct.  In fact, this code will work exactly the same way, unchanged, on WPF.  The library handles assigning us the correct SynchronizationContext for us.  In Windows Forms, it will generate a context which passes everything to the message loop.  In WPF, it will automatically generated a context which uses the Dispatcher to push messages back into the WPF message queue.

Currently, if you want to use data kept at a local scope with a copy per thread, the solution is to use a LocalDataStoreSlot to manage your threaded data.  This works, but is not very developer-friendly.  It is not type-safe; all data is stored as a System.Object.  It is clunky at best to use, especially if you want to free, as you have to use and track strings with named data slots in order to release the memory.  Version 4 of the .NET Framework fixes all of these issues by introducing ThreadLocal<T>.

The new ThreadLocal<T> class provides us with a strongly typed, locally scoped object we can use to setup data that is kept separate for each thread.  This allows us to use data stored per thread, without having to introduce static variables into our types.  Internally, the ThreadLocal instance will automatically setup the static data, manage its lifetime, do all of the casting to and from our specific type.  This makes developing much simpler.

Here’s a simple but complete example showing how this is used:

namespace CSharpConsoleApplication
{
    using System;
    using System.Threading;
    using System.Threading.Tasks;

    class Program
    {

        static void Main(string[] args)
        {
            // Create our ThreadLocal<T>, with a Func<T> used to initialize
            using (ThreadLocal<int> dataPerThread =
                    new ThreadLocal<int>(() => Thread.CurrentThread.ManagedThreadId))
            {
                // Loop a few times, to see the output
                Parallel.For(0, 10, (i) =>
                    {
                        Console.WriteLine("dataPerThread {0}/{1} for iteration {2}",
                                     dataPerThread.IsValueCreated, dataPerThread.Value, i);
                    });
            }

            // Wait for a keypress to exit
            Console.WriteLine("Press any key to exit...");
            Console.ReadKey();
        }
    }
}

When we run, we’ll get results similar to the following:

dataPerThread False/9 for iteration 0
dataPerThread True/9 for iteration 2
dataPerThread False/10 for iteration 1
dataPerThread True/10 for iteration 5
dataPerThread True/10 for iteration 6
dataPerThread True/10 for iteration 7
dataPerThread True/10 for iteration 8
dataPerThread True/10 for iteration 9
dataPerThread False/12 for iteration 4
dataPerThread True/9 for iteration 3
Press any key to exit...

Your results will obviously be different, as the order is somewhat random.  (We are multi-threading here!)

Here are a few things to note about this sample and these results:

First, when we create the ThreadLocal<int> instance, we have the option of providing a Func<T> to the ThreadLocal<T>’s Constructor.  This allows us to provide an initialization routine which will be used the first time a given thread accesses the Value property.  This greatly eases our construction burden, since we can just wrap everything in a delegate (potentially using closures around our class variables) to have complex initialization of our type without having to “think about” it during our work.

Second, when we first access our dataPerThread variable, it is uninitialized.  If we need to do complex initialization, we can check the ThreadLocal<T>.IsValueCreated property.  This will tell us whether or not a specific value has been created for the currently running thread.  When we run the sample, you can see this – the first time a specific thread (the first number, either 9, 10, or 12) accesses dataPerThread, IsValueCreated returns false.  When we then read the value, our Func<T> will execute, and set the data to the current managed thread ID.  The subsequent times we try to read the data, it’s already been created.

Third, ThreadLocal<T> implements IDisposable.  This provides a much simpler way of handling cleanup than trying to deal with static variables per thread.

So the final question I’ll address here: Why is this useful, and where would I want to use this class?  In my case, I already have one very good use case.  I will be using ThreadLocal<T> in order to handle a thread-specific cache.

We have some algorithms which are parallelizable.  However, as we run from one case to the next, there is a chance we can save quite a bit of computation by caching and reusing certain steps, momoizing the results.  However, since we’re threading the algorithm, sharing this cache amongst the threads is problematic – it requires adding locking within the algorithm in order to have a thread-safe cache.  The locking nearly wipes out the speed gains we achieve via the caching.

By using ThreadLocal<T> to store our cache information, each thread can have it’s own copy of the cache, created once per run (local scope).  This provides us with completely threadsafe, lock-free memoization, at the cost of two threads potentially recalculating results.  Profiling our algorithm proved that this provided a dramatic speed improvement.