Parallel Programming with .NET : Visual Studio 2010

PDC09 Parallelism Session Videos Now Available

toub — Sat, 21 Nov 2009 09:05:20 GMT

Attendees at PDC09 this past week were privy to quite a few sessions on parallel computing. Now that the videos of these sessions are online, you can view them as well from the comfort of your own home. Here are some of the key parallelism-related sessions from this past week:

Overview

The State of Parallel Programming

Managed code in Visual Studio 2010

Native code in Visual Studio 2010

HPC Server

Accelerating Applications Using Windows HPC Server 2008

Research and Incubation

Enjoy!

Debugging TPL apps in VS2010

DanielMoth — Sun, 15 Nov 2009 08:18:00 GMT

The new parallel debugger windows in Visual Studio 2010 (Parallel Tasks and Parallel Stacks) have had many fixes and updates.

I have refreshed the existing content and also added new material for Beta 2. Find links to all of it from my blog post on Parallel Debugging.

Cheers
Daniel

What's New in Beta 2 for PLINQ

essey — Thu, 05 Nov 2009 20:37:00 GMT

Included in the .NET 4 Framework Beta 2 is a more robust and faster version of PLINQ. Between B1 and B2, PLINQ changes have mainly been under the covers, so hopefully no need to rewrite any of your applications to see the improvements.

1. Many improvements to performance and scalability

2. GroupBy and GroupJoin now preserve ordering within the groups

3. Better integration with performance profiling, which now shows PLINQ markers

4. Cancellation consistently works across all PLINQ operators

5. Scoped some of the boundary conditions of PLINQ in .NET 4 in Beta2 of Parallel Extensions as follows:

a. Max Degree of Parallelism changed from 64 to 63

b. Greater consistency regarding maximum input length

i. PLINQ does not support inputs of length > Int32.MaxValue. Queries may throw OverflowException for many operators.

ii. LongCount no longer counts beyond Int32.MaxValue

6. Improved robustness

a. Reliability and concurrency focus

b. More consistent exception handling and error model

7. Other bug fixes

If any of these severely impact your applications, particularly the boundary conditions, please let us know so that we can include that in our planning efforts. For now, we found that it makes the most sense to scope some inputs and give a reliable and predictable experience in this release.

Happy Coding!

What’s new in Beta 2 for the Task Parallel Library? (Part 3/3)

dashih — Wed, 04 Nov 2009 21:52:00 GMT

Last time, we covered Tasks being detached by default and some refactorings in our multiple-Task continuation APIs. The final post of this series will discuss Nested Tasks and Unwrap, a Parallel namespace change, and some changes under the covers.

Nested Tasks and Unwrap

We’ve added the Unwrap APIs to address scenarios that deal with nested Tasks. Before jumping into Unwrap, let’s first talk about nested Tasks, e.g. a Task<Task> or Task<Task<TResult>>. For example:

var nestedTask = Task.Factory.StartNew(() =>
{
    return Task.Factory.StartNew(() =>
    {
        return 42;
    });
});

Nested Tasks commonly lead to unexpected behavior in applications. For example, consider an API that provides the following functionality for asynchronously logging into a web service (like one from Facebook), retrieving a list of friends, and sending an email to each friend.

// Given a user name and password, returns a Task whose

// result is a UserToken object.

public Task<UserToken> LogOn(string username, string password);

// Given a UserToken, returns a Task whose result

// is a collection of Friend objects.

public Task<FriendCollection> GetFriendList(UserToken userToken);

// Given a Friend, subject, and body, returns a Task that

// represents an email sending operation.

public Task SendEmail(Friend friend, string subject, string body);

A user would like to be able to write code like the following, utilizing these APIs and Task continuations:

var userToken = LogOn(user, pass);

var friends = userToken.ContinueWith(_ => GetFriendList(userToken.Result));

var emails = friends.ContinueWith(_ =>

{

var sentMails = new List<Task>();

foreach(var friend in friends.Result)

{

sentMails.Add(SendEmail(friend, subject, body));

}

return Task.Factory.ContinueWhenAll(

sentMails.ToArray(), tasks => Task.WaitAll(tasks));

});

emails.ContinueWith(_ => Console.WriteLine(“All emails sent”));

The bolded code is problematic. Because the GetFriendList method returns a Task<FriendCollection>, the ‘friends’ variable is actually going to be a Task<Task<FriendCollection>>. This will cause a compiler error at the foreach loop, because ‘friends.Result’ will return a Task<FriendCollection> instead of a FriendCollection. The compiler error in this case is a good thing, of course, highlighting a programming error. However, once a developer realizes the type mismatch, he still has to code additional logic to unwrap the ‘friends’ Task so that it returns an actual FriendCollection. This logic is nontrivial, especially if it is to correctly deal with exceptions, cancellation, etc. The last line is also problematic. The emails variable here is actually of type Task<Task>. The outer Task will complete once the inner Task is returned from its body, even if the inner Task hasn’t completed. The net result of this is that “All emails sent” could be written out prior to all of the email tasks actually completing.

Now, you may have noticed that, in Beta 1, we provided special ContinueWith overloads to deal with this type of scenario. For example:

public Task<TResult> ContinueWith<TResult>(

Func<Task, Task<TResult>> continuationFunction);

The Func returns a Task<TResult>, so normally, ContinueWith would return a Task<Task<TResult>>. But this ContinueWith overload does some magic under the covers to return a Task<TResult>. There were a number of reasons why we didn’t like this approach, including:

· Too much magic. It’s hard to explain why one set of ContinueWith overloads is “just different”.

· Only works for ContinueWith. What if user scenarios result in nested Tasks for other Task creation APIs like StartNew, ContinueWhenAll, etc.?

· What if nested Tasks are actually desired? If a user actually wants that Task<Task<TResult>>, he still might unknowingly bind to this magical overload.

Given these reasons, our solution for Beta 2 and beyond is two Unwrap extension methods.

namespace System.Threading.Tasks

{

public static class TaskExtensions

{

public static Task Unwrap(

this Task<Task> task);

public static Task<TResult> Unwrap<TResult>(

this Task<Task<TResult>> task);

}

These methods may be used to transform any Task<Task> or Task<Task<TResult>> into a Task or Task<TResult>, respectively. The transformation performed produces a Task or Task<TResult> that fully represents the original nested Task, including exceptions, cancellation state, etc.

With Unwrap, we can fix the above scenario (note the bolded).

var userToken = LogOn(user, pass);

var friends = userToken.ContinueWith(

_ => GetFriendList(userToken.Result)).Unwrap();

var emails = friends.ContinueWith(_ =>

{

var sentMails = new List<Task>();

foreach(var friend in friends.Result)

{

sentMails.Add(SendEmail(friend, subject, body));

}

return Task.Factory.ContinueWhenAll(

sentMails.ToArray(), tasks => Task.WaitAll(tasks));

}).Unwrap();

emails.ContinueWith(_ => Console.WriteLine(“All emails sent”));

Parallel Namespace Change

We’ve moved the Parallel class from the System.Threading namespace to the System.Threading.Tasks namespace. We found that most applications needed to bring in both namespaces when using TPL, so why not put everything into one namespace? Additionally, Parallel is such a common word (and will likely become more so in the future), and System.Threading such a common namespace, we wanted to reduce the chances of conflict with other .NET types as much as possible.

Here’s a useful IDE tip. Use “Ctrl + .” to automatically bring in the relevant namespace once you’ve typed a class/type name.

Under the Covers

Beta 2 contains quite a few bug fixes not done for Beta 1. All of them were important, but we’ll focus on only two here.

First, Parallel.For and ForEach have been tweaked for better load-balancing with other workloads in the current or other AppDomains. Essentially, the change was to service the parallel loops with Tasks that periodically retired and re-queued themselves, allowing other contenders to grab Threads and make progress.

Second, waiting for Tasks in parent/child relationships has become more efficient. In Beta 1 and before, parent Tasks waited for their children using explicit Waits, so even if a parent completed first, it would burn a thread until all of its children completed. In Beta 2, parent Tasks wait for their children using callbacks; the parent maintains a count for number of children it has, and each child decrements the count as it completes. This waiting logic significantly improves scalability.

That’s it folks! We hope you’ve enjoyed this series. Download Beta 2 and try it out!

Slides from Parallelism Tour

toub — Mon, 02 Nov 2009 02:58:00 GMT

Last week, I had the privilege of touring around Tennessee, Kentucky, Ohio, and Michigan, speaking about the new parallel computing support in Visual Studio 2010 and the .NET Framework 4. Many folks I spoke with were interested in getting a copy of the slide deck I used, so I’ve attached it to this blog post. Enjoy!

What’s new in Beta 2 for the Task Parallel Library? (Part 2/3)

dashih — Tue, 27 Oct 2009 18:02:00 GMT

Last week, we talked about how TPL adopted a new, better cancellation model. Today, we’ll cover a change that makes Tasks Detached by Default, some ContinueWhenAll/Any Refactoring, and the handy UnobservedTaskException event.

Tasks are Detached by Default

In Beta 2, we have changed an important default. Tasks are now created as detached (instead of attached) if no options specify otherwise.

Let’s consider the following code to review the difference between attached and detached Tasks.

Task p = Task.Factory.StartNew(() =>

{

Task c = Task.Factory.StartNew(() =>

{

DoWork();

});

p.Wait();

In Beta 1 and before, since the default options are used, ‘c’ is created as a child Task of Task ‘p’, the parent Task; we refer to this as Task ‘c’ being “attached” to Task ‘p’. This means that the p.Wait() statement will not return until the call to DoWork completes, because parent Tasks do not complete until all of their child Tasks complete. To opt out of this behavior, a user needs to create ‘c’ with the DetachedFromParent option:

Task c = Task.Factory.StartNew(() =>

{

DoWork();

}, TaskCreationOptions.DetachedFromParent);

The original code shown behaves differently in Beta 2. Now, by default, ‘c’ is not related to ‘p’ (it’s “detached” by default), and the p.Wait() statement will return as soon as ‘p’ completes, regardless of the status of Task ‘c’ and thus regardless of when DoWork returns. To opt in to the parent/child relationship, a user needs to create ‘c’ with the AttachedToParent option:

Task c = Task.Factory.StartNew(() =>

{

DoWork();

}, TaskCreationOptions.AttachedToParent);

Here is a summary of the changes:

· Removed the DetachedFromParent option

· Added the AttachedToParent option

· Changed the default behavior so that Tasks do not enlist in parent/child relationships when no options are specified.

There were a number of reasons why we decided that detached is the correct default and to move forward with this change, including:

· Many users were using attached Tasks unknowingly. The vast majority of the time, users create Tasks for simple, asynchronous work. In such scenarios, parent/child relationships (and the implicit waiting) are not needed. We found through many interactions that folks were just going with the default options and were accidentally opting in to this behavior. In the best case, this would only result in a slight performance cost. In the worst case, this would bring with it incorrect behavior that would lead to difficult to diagnose errors.

· Easier migration from ThreadPool.QueueUserWorkItem. Tasks are now the recommended way to queue work to the ThreadPool, but the easiest way to create Tasks resulted in different behavior from QueueUserWorkItem (where there’s no concept of parent/child work items). This change makes Task.Factory.StartNew (with no options) a true replacement for QueueUserWorkItem.

· Additional behavior should be opt-in and pay-for-play. Almost everything in TPL that results in additional behavior is opt-in, e.g. cancellation, LongRunning, PreferFairness. With the Beta 1 default, users opt-out of parent/child relationships. In Beta 2, users opt-in, making it consistent. This makes the extra functionality provided by parent/child relationships pay-for-play, such that you don’t pay the cost for parents implicitly waiting for their children or for exceptions propagating from children to parents unless you need that functionality.

ContinueWhenAny/All Refactoring

We have refactored the set of ContinueWhenAny and ContinueWhenAll overloads to make things more intuitive, consistent, and complete.

To demonstrate the main issue, let’s consider the following overload that was provided in Beta 1.

public class TaskFactory<TResult>

{

public Task<TNewResult> ContinueWhenAny(

Task<TResult>[] tasks,

Func<Task<TResult>, TNewResult> continuationFunction);

}

This confused the meaning of TaskFactory<TResult>, which is meant to create tasks of type Task<TResult>. However, with these overloads, TaskFactory<TResult> could be used to create tasks of type Task<TNewResult>. As an example, consider the code:

Task<int>[] taskOfInts = ...;
Task<string> t = Task<int>.Factory.ContinueWhenAll(taskOfInts, _ => “”);

This compiles and works just fine, but the type parameter mismatch (shown in bold) is certainly odd. To address this, we changed a bunch of overloads, so that instead of taking Task<TResult>s and returning a Task<TNewResult>, they take Task<TAntecedentResult>s and return Task<TResult>s. For example, the overload that replaced the above is:

public Task<TResult> ContinueWhenAny<TAntecedentResult>(

Task<TAntecedentResult>[] tasks,

Func<Task<TAntecedentResult>, TResult> continuationFunction);

And the above example becomes:

Task<int>[] taskOfInts = ...;
Task<string> t = Task<string>.Factory.ContinueWhenAll(taskOfInts, _ => “”);

In addition to this change, we also added, removed, or modified a number of other overloads to make the set consistent and complete. Now, the entire set of ContinueWhenAll and ContinueWhenAny overloads follow these clear rules:

· A TaskFactory creates Tasks, but also provides overloads to create Task<TResult>s.

· A TaskFactory<TResult> only ever creates Task<TResult>s (never Tasks or Task<TNewResult>s).

UnobservedTaskException event

We’ve added an event that fires for every Task exception that goes unobserved. Recall that to “observe” a Task’s exceptions, you must either Wait on the Task or access its Exception property after it has completed. At least one of these actions must be done before the Task object is garbage collected, or its exceptions will propagate (currently this occurs on the finalizer thread).

The new static event resides on the TaskScheduler class, and subscribing to it is straightforward. Here’s an example to log all unobserved exceptions and mark them as observed (preventing them from being propagated).

TaskScheduler.UnobservedTaskException +=

(object sender, UnobservedTaskExceptionEventArgs exceptionArgs) =>

{

exceptionArgs.SetObserved();

LogException(exceptionArgs.Exception);

};

Some customers have complained that TPL’s exception policy is too strict. The UnobservedTaskException event provides an easy way out by allowing you to simply squash all Task exceptions in an application (though using it in this manner is not recommended). The primary reason that we made the addition was to support host-plugin scenarios where a host application can still be perfectly useful in the presence of some truly harmless exceptions (thrown by buggy plugins). These scenarios may be achieved using the UnobservedTaskException event in conjunction with AppDomains to sandbox plugins. Look for a future post that describes this in more detail!

We’re done for now! The 3^rd and final post of this series will cover the new Unwrap APIs, a Parallel namespace change, and some changes under the covers.

.NET 4 Beta 2 is here!

toub — Mon, 19 Oct 2009 18:50:05 GMT

The .NET Framework 4 Beta 2 is now available!

MSDN Subscribers can download it today, and it will be generally available for download on Wednesday. More information is available at http://msdn.microsoft.com/en-us/vstudio/dd582936.aspx. Additionally, one of the really exciting things about this Beta release is that it’s “go-live”; more information on that is available at “Going live” with Visual Studio 2010 Beta 2.

As part of .NET 4 Beta 2, of course, comes improved parallelism support. In the coming days and weeks, we’ll be blogging here about some of the exciting updates and additions in this release. Stay tuned…

In the meantime, the MSDN documentation on .NET 4’s parallelism support has been updated. It’s a great place to start learning about all of the functionality available in this release.

You can also learn more about the tools in Visual Studio 2010 for parallel development in the documentation at:

Enjoy!

Parallel Computing at PDC09 and TechEd Europe 2009

toub — Fri, 16 Oct 2009 17:28:23 GMT

It’s fall, and that means conference season! In November, members of the Parallel Computing Platform team will be descending upon both PDC09 in Los Angeles and TechEd Europe 2009 in Berlin. We’re extremely excited to see all of you there and to discuss the new support for parallel computing that’s coming in Visual Studio 2010, Visual C++ 10, and the .NET Framework 4. Please find us and introduce yourselves… we’re looking forward to speaking with you.

There are a bunch of cool sessions at both conferences having to do with parallel computing. Here’s a rundown of relevant announced sessions at the PDC:

A Computing Platform That Scales	See how Windows Server 2008 R2 represents the latest evolution of the Windows Server operating system and supports high-end hardware systems with large numbers of microprocessors. Learn how new Non-Uniform Memory Access (NUMA) and User-Mode Scheduling (UMS) API's effectively enable application developers to "minimize contention and maximize locality" of system resources relative to thread execution contexts. See how these new platform capabilities are extended via libraries such as the C++ Concurrency Runtime and the .NET Parallel Extensions along with complementary tools support within Visual Studio 2010.
Axum: A .NET Language for Safe and Scalable Concurrency	Axum is an incubation project from Microsoft's Parallel Computing Platform that aims to validate a safe and productive parallel programming model for the .NET framework. It's a language that builds on the principles of isolation, agents, and message-passing to increase application safety, responsiveness, scalability and developer productivity. Come learn about Axum and other advanced concepts we are exploring including data flow networks, asynchronous methods, and protocol-based component interactions.
Data-Intensive Computing on Windows HPC Server with the DryadLINQ Framework	Come get an overview of the DryadLINQ features and runtime environment, and walk through some real-world examples of DryadLINQ programs based on the familiar declarative syntax of LINQ combined with the fault-tolerant distributed graph scheduling of the Dryad runtime. Hear how DryadLINQ provides a programming model and runtime for data-parallel programs running across large clusters and partitioned data sets.
Lighting up Windows Server 2008 R2 Using the ConcRT on UMS	See examples of how to use C++ and the new Concurrency Runtime (ConcRT) to take advantage of new technologies on Windows Server 2008 R2, such as the ability to scale beyond 64 cores and User-Mode Scheduling (UMS) of threads. Learn to write code that scales even in the face of complicated processor architectures, Non-Uniform Memory Access (NUMA), and many-cores. Hear how ConcRT provides mechanisms that allow you to naturally express affinity requirements and schedule work on appropriate nodes without thrashing the system.
PLINQ: LINQ, but Faster!	Multi-core processors are everywhere! Parallel Language Integrated Query (PLINQ) in the Microsoft .NET Framework 4 offers a minimal-code solution to take advantage of this parallel hardware, providing an implementation of the .NET Standard Query Operators that uses parallel execution techniques underneath the simple LINQ programming to make applications run faster! Come for a deep dive into PLINQ via Microsoft Visual Studio 2010. See what it looks like from the perspective of LINQ developers, the debugging and profiling support, how it's implemented under the covers, and how to best incorporate it into your applications in order to reap the performance benefits of the manycore era.
F# for Parallel and Asynchronous Programming	Concurrency is increasingly important for many applications. The shift to manycore brings abundant parallelism to the desktop. The Web, Microsoft Silverlight, and distributed systems increase the demand for asynchronous solutions. F#, a functional and object-oriented language for Microsoft .NET, adds many tools to make parallel and asynchronous programming both fun and easy. Come hear the core concepts of the F# language, and see how ideas like immutability, functional design, async workflows, agents, and more can be used to meet the challenges of today’s real-world applications.
C++ Forever: Interactive Applications in the Age of Manycore	Developing concurrent applications is hard. Making them robust and responsive is even more challenging. The new asynchronous agents library and parallel debugging and profiling support in Microsoft Visual Studio 2010 simplify the situation, enabling you to develop I/O- and computationally-intensive applications that offload work from the UI and that make good use of available resources. Come for a deep dive into the power of actor-based and dataflow programming in Microsoft Visual C++ 2010. Learn how it can help you to write correct, efficient, and scalable applications.
The State of Parallel Programming	Parallel programming has been more difficult than it needs to be, perhaps because its tools have been treated as an “add-on” to serial programming. The objectives of composability and productivity demand something better. Come hear a relatively recent consensus view about what is needed for productive parallel programming, and why.
Manycore and the Microsoft .NET Framework 4: A Match Made in Microsoft Visual Studio 2010	The Microsoft .NET Framework 4 and Visual Studio 2010 include new technologies for expressing, debugging, and tuning parallelism in managed applications. Dive into key areas of support, including the new System.Threading.Tasks and System.Collections.Concurrent namespaces, cutting-edge concurrency views in the Visual Studio profiler, and debugger tool windows for analyzing the state of concurrent code.
Patterns of Parallel Programming: A Tutorial on Fundamental Patterns and Practices for Parallelism	The transition from single-core to multi-core technology is altering computing as we know it, enabling increased productivity, powerful energy-efficient performance, and leading-edge advanced computing experiences. Multi-core and HPC technologies are rapidly moving into the computing mainstream, allowing us to develop applications with improved performance, increased responsiveness, and reduced latency. This workshop is aimed at experienced software developers who are relatively new to the parallel computing space but expect it to become more important to their work. The workshop helps software developers understand the fundamental challenges of parallel computing, that span from the client to the cluster, such as synchronization, shared state, and moving from multi-core to multi-server. Learn how established software patterns can help developers building on both Microsoft’s Parallel Computing Platform—consisting of Task Parallel Library, PLINQ and Coordination Data Structures for .NET development, and Parallel Patterns Library and Concurrency Runtime for C++—and the HPC platform. The presenters describe the patterns in a bigger context, share their experience, and demonstrate implementations of these patterns in examples and demos. Learn how to add these patterns and new technologies to your toolbox.

There are also several good and related sessions at TechEd Europe:

F# for Parallel and Asynchronous Programming	Concurrency is increasingly important for many applications. The shift to manycore brings abundant parallelism to the desktop. The Web, Microsoft Silverlight, and distributed systems increase the demand for asynchronous solutions. F#, a functional and object-oriented language for Microsoft .NET, adds many tools to make parallel and asynchronous programming both fun and easy. This talk quickly reviews the core concepts of the F# language, and shows how ideas like immutability, functional design, async workflows, agents and more can be used to meet the challenges of today's real-world applications.
Parallel Computing for Managed Developers	The microprocessor industry has undergone a major paradigm shift from increasing clock speed with each successive hardware revision to increasing core count and potential for parallelism. This change requires software developers to think parallel in order to extract performance and provide a competitive user experience. This session discusses the new programming model and tools technologies in Visual Studio 2010 and .NET 4.0, including the Task Parallel Library (TPL), Parallel Language Integrated Query (PLINQ), and Concurrent Data Structures (CDS). Developers will also gain a deeper understanding of the advantages of building applications using these task-centric parallel technologies and will see demonstrations of several important patterns for parallelization.
Microsoft Visual C++ 2010: The "Fast" Way towards Modern Windows Applications	Do you love it when your application is the fastest on the block? Do you want to get the most of the Windows platform without re-writing your application and make it even faster in the process? Come and watch an action-packed demo and see how Visual Studio 2010 is a huge release for C++ developers! It's huge because it's focused on making it easier for ISVs who have many million lines of code. We have dramatically improved the scalability and productivity of the IDE and enabled MFC applications to seamlessly light up on Windows Vista and Windows 7. With the advent of highly parallel hardware, our adoption of the new C++ standard ushers in new ways to program scalable native applications.
Building High Performance Parallel Software	In this session, attendees will learn how to parallelize their software to take advantage of the industry shift to multicore hardware architectures. Several key aspects of achieving performance through parallelization will be covered, including identifying opportunities for parallelism, high performance patterns and best practices for parallel coding, effectively employing the new Visual Studio 2010 programming models, and the use of the Visual Studio 2010 Profiler to identify bottlenecks and optimize applications. Examples will be shown in both managed and native code.

Both events should prove to be very exciting. See you there.

Parallel Computing Presentations in Michigan, Ohio, Kentucky, and Tennessee

toub — Fri, 16 Oct 2009 15:49:29 GMT

In a week, I’m going to be traveling through Michigan, Ohio, Kentucky, and Tennessee, speaking about parallel computing, Visual Studio 2010, and .NET 4, primarily at corporations during the day and at user groups in the evenings.

If you’re in the area and interested, please do attend, and I look forward to meeting you! A list of events is available at http://blogs.msdn.com/jennifer/archive/2009/10/14/stephen-toub-parallel-computing-tour.aspx.

See you in a week!

Stephen

TaskScheduler.FromCurrentSynchronizationContext

toub — Tue, 22 Sep 2009 19:46:13 GMT

The Task abstractions in .NET 4 run on instances of the TaskScheduler class. Two implementations of TaskScheduler ship as part of the .NET Framework 4. The first is the default scheduler, which is integrated with the .NET 4 ThreadPool and takes advantage of its work-stealing queues. The second is the type of TaskScheduler returned from the static method TaskScheduler.FromCurrentSynchronizationContext.

According to MSDN, SynchronizationContext “provides the basic functionality for propagating a synchronization context in various synchronization models.” What does that really mean? At its core, SynchronizationContext provides two methods, Send and Post, both of which accept a delegate to be executed. Send synchronously invokes the delegate, and Post asynchronously invokes the delegate. That’s it, and the base implementation of SynchronizationContext doesn’t do anything fancier than that:

public virtual void Send(SendOrPostCallback d, object state)
{
d(state);
}

public virtual void Post(SendOrPostCallback d, object state)
{
ThreadPool.QueueUserWorkItem(new WaitCallback(d.Invoke), state);
}

Where things get interesting is when new types are derived from SynchronizationContext, something typically done by a UI framework (though there are other non-UI framework implementations). For folks familiar with Windows Forms and Windows Presentation Framework development, you’re likely aware that UI controls should only be accessed by the thread that created them, almost always the main UI thread. Thus, if a thread doing work in the background wants to update something in the UI, it needs to marshal that work back to the GUI thread so that the controls may be accessed safely. Different UI frameworks expose different ways for accomplishing this marshaling. For example, in Windows Forms, one uses the Invoke or BeginInvoke method of the target Control (or at least a Control created on the same thread as the target Control). In WPF, one uses the target thread’s Dispatcher and corresponding Invoke/BeginInvoke methods. With every UI framework having its own model for marshaling work to a particular “synchronization context”, it becomes difficult to write code that supports this marshaling concept but which is agnostic to the particular environment that it’s in. Enter SynchronizationContext. A new type may be derived from SynchronizationContext such that its Send method synchronously marshals a delegate to the right thread for execution, and Post does the same but asynchronously. If you look at the implementations of the SynchronizationContexts provided by Windows Forms and WPF, that’s exactly what they do, delegating to the relevant Invoke/BeginInvoke methods from Send and Post to marshal the work correctly.

To make it easy to get at the right SynchronizationContext, a UI framework like Windows Forms will publish an instance of its SynchronizationContext-derived class to SynchronizationContext.Current. Code can then grab SynchronizationContext.Current and use it to marshal work, without having to know whether it’s being used from Windows Forms or Windows Presentation Foundation or another similar model.

“TaskScheduler.FromCurrentSynchronizationContext” should now make more sense. This method creates a TaskScheduler that wraps the SynchronizationContext returned from SynchronizationContext.Current. Thus, this gives you a TaskScheduler that will execute Tasks on the current SynchronizationContext. Why is that useful? It means you can create Tasks that are able to access UI controls safely, simply by running them on the right scheduler.

Let’s say that I wanted to load three images from some data source. When those images have been loaded, I want to blend them all together, and then I want to display the result into a PictureBox on my UI. Using Tasks and TaskScheduler.FromCurrentSynchronizationContext, I could write code like the following:

private void Button1_Click(…)
{
    var ui = TaskScheduler.FromCurrentSynchronizationContext();
    var tf = Task.Factory;

    // Load the three images asynchronously
    var imageOne = tf.StartNew(() => LoadFirstImage());
    var imageTwo = tf.StartNew(() => LoadSecondImage());
    var imageThree = tf.StartNew(() => LoadThirdImage());

    // When they’ve been loaded, blend them
    var blendedImage = tf.ContinueWhenAll(
        new [] { imageOne, imageTwo, imageThree }, _ =>
        BlendImages(imageOne.Result, imageTwo.Result, imageThree.Result));

    // When we’re done blending, display the blended image
    blendedImage.ContinueWith(_ =>
    {
        pictureBox1.Image = blendedImage.Result;
    }, ui);
}

This code runs three tasks to load the three input images asynchronously. When all of those have been loaded, again asynchronously some BlendImages method is used to blend the images, taking the three inputs and returning the blended image. Finally, once that’s done, another task is used to render the blended image by storing it into a PictureBox on the UI. Since this modifies a UI control, we need to do it from the UI thread. Thus, we pass a TaskScheduler to the ContinueWith method; this scheduler targets the UI’s SynchronizationContext, and will cause the Task to execute on the UI thread.

TaskScheduler.FromCurrentSynchronizationContext is provided for convenience and because this is a very common need. However, due to TaskScheduler’s extensibility, it’s actually possible to implement this behavior yourself, and in doing so you could modify it to suit your own needs however you see fit.

Let’s say you did want to develop a new SynchronizationContextTaskScheduler. It might look something like this:

public class SynchronizationContextTaskScheduler : TaskScheduler
{
    private ConcurrentQueue<Task> _tasks = new ConcurrentQueue<Task>();
    private SynchronizationContext _context;

    public SynchronizationContextTaskScheduler() :
        this(SynchronizationContext.Current) { }

    public SynchronizationContextTaskScheduler(
        SynchronizationContext context)
    {
        if (context == null) throw new ArgumentNullException("context");
        _context = context;
    }

    protected override void QueueTask(Task task)
    {
        // Add the task to the collection
        _tasks.Enqueue(task);

        // Queue up a delegate that will dequeue and execute a task
        _context.Post(delegate
        {
            Task toExecute;
            if (_tasks.TryDequeue(out toExecute)) TryExecuteTask(toExecute);
        }, null);
    }

    protected override bool TryExecuteTaskInline(
        Task task, bool taskWasPreviouslyQueued)
    {
        return SynchronizationContext.Current == _context &&
                  TryExecuteTask(task);
    }

    public override int MaximumConcurrencyLevel { get { return 1; } }

    protected override IEnumerable<Task> GetScheduledTasks()
    {
        return _tasks.ToArray();
    }
}

Not a lot of code for a fairly powerful thing.

The constructors simply accept the target SynchronizationContext and store it, also initializing a thread-safe queue that will store the tasks to be executed.
The QueueTask method is called whenever the system is providing a Task for this scheduler to execute: this scheduler handles it by storing that Task into a queue, and then Post’ing to the SynchronizationContext a delegate that will pull the next Task from the queue and execute it.
The TryExecuteTaskInline is invoked any time the system wants to run a Task inline on the current thread (either from a call to RunSynchronously or from a Wait attempt): we need to make sure that the call is coming from the same SynchronizationContext as the target, otherwise we may end up running in the wrong context.
We only intended to support SynchronizationContexts that represent a single thread of execution (that’s most common), so we return 1 from MaximumConcurrencyLevel.
And we want the debugger to be able to display tasks scheduled to this scheduler, so we override GetScheduledTasks to return an array of the tasks queued. (This is why we need to explicitly store the queue of tasks; otherwise, we could have simply relied on lambda closures to capture each task to be executed.)

Samples for Parallel Programming with the .NET Framework 4

toub — Thu, 21 May 2009 03:36:00 GMT

Along with the release of the .NET Framework 4 Beta 1, we've just published a slew of samples that demonstrate using Parallel Extensions in a variety of ways. You can download these from Code Gallery at http://code.msdn.microsoft.com/ParExtSamples.

These samples include raytracers, a sudoku game, an image colorization algorithm, solvers for the n-queens problem, fractal image generators, and more. The samples include code written to use Parallel Extensions from C#, Visual Basic, F#, and C++/CLI. They include examples of using the Task Parallel Library, PLINQ, new coordination data structures, and even databinding a WPF UI to a collection that has data stored into it from a background thread.

On top of all of this, the samples include a project called "Parallel Extensions Extras", which features a healthy portion of extension methods for .NET 4 types, new data structures to augment what's being shipped in .NET 4, custom schedulers for TPL, and lots of other goodness. Definitely worth a perusal.

Enjoy!

.NET 4 MSDN documentation for parallelism

toub — Thu, 21 May 2009 01:59:00 GMT

In addition to the Betas of Visual Studio 2010 and the .NET Framework 4 being available for download today, the MSDN documentation for .NET 4 Beta 1 is also available. This includes quite a bit of useful information about the new parallelism constructs. Here's a summary of the relevant material, with links:

Parallel Programming in the .NET Framework

Task Parallel Library
Parallel LINQ
Data Structures for Parallel Programming
Parallel Diagnostic Tools

.NET Framework Class Library

Related to this and for more background information, you can also check out the documentation for our native concurrency runtime and programming models:

Concurrency Runtime

Reference

Concurrency Namespace

As with the actual bits, any and all feedback on the docs is welcome and encouraged. A great place to provide feedback is on the forums, for managed at http://social.msdn.microsoft.com/Forums/en-US/parallelextensions/threads and for native at http://social.msdn.microsoft.com/Forums/en-US/parallelcppnative/threads.

Debugging Support for Tasks

DanielMoth — Sat, 16 May 2009 07:55:00 GMT

Visual Studio 2010 has new debugger windows to support the Task-based programming model. Check out my blog post about the Parallel Tasks window.

Parallelism Videos Galore

toub — Tue, 18 Nov 2008 11:14:00 GMT

It's been a hectic and exciting few weeks, and we on the Parallel Computing Platform team have been having a great time talking with customers all over the world, at the PDC, at TechEd EMEA, at DevConnections, through Channel 9, and more. A lot of the resulting material is now available online for viewing, so do check it out if you're interested.

PDC 2008 videos

Parallel Programming for Managed Developers with the Next Version of Microsoft Visual Studio

Parallel Programming for C++ Developers in the Next Version of Microsoft Visual Studio

Microsoft Visual Studio: Bringing out the Best in Multicore Systems

Concurrency Runtime Deep Dive: How to Harvest Multicore Computing Resources

Parallel Symposium: Addressing the Hard Problems with Concurrency

Parallel Symposium: Application Opportunities and Architectures

Parallel Symposium: Future of Parallel Computing

Research: Concurrency Analysis Platform and Tools for Finding Concurrency Bugs

The Concurrency and Coordination Runtime and Decentralized Software Services Toolkit

Channel 9: Visual Studio 2010 and .NET Framework 4.0 Week

Using the Parallel Extensions to the .NET Framework

Native Parallelism with the Parallel Patterns Library

Debugging Parallel Applications with Visual Studio 2010

TechEd EMEA 2008

Parallel Programming for Managed developers with Visual Studio 2010 and .NET Framework 4.0

Tech chat with Microsoft's parallel guru Steve Teixeira

Why we Need the Task-Based Programming Model Introduced in .NET 4

The Inexorable Drive to Many-Core Processors

Other (OnMicrosoft, University of Washington Colloquium, ...)

Concurrent Programming on Windows

Visual Studio 2010 Part 1 of 2- Support for Parallelism

Microsoft's Parallel Computing Platform: Applied Research in a Product Setting

And if you're more interested in the written word, check out this recent tech brief in Redmond Developer News:

Tech Brief: Parallel Extensions

All of this is, of course, in addition to all of the previous material that's been posted online, such as was mentioned at The Channel 9 videos are rolling in, Webcasts on Parallelism from France, Parallel Extensions Demo Fun on Channel 9, More Channel 9 Parallel Extensions Goodness, New PLINQ video on Channel 9, Task Parallel Library on Channel 9, Burton Smith on Channel 9, Parallel Extensions on .NET Rocks, Parallelism in October 2008 MSDN Magazine, and Another Parallel Extensions screencast.

Enjoy!

Using Hyper-V with the Visual Studio 2010 and .NET Framework 4.0 CTP

toub — Tue, 04 Nov 2008 09:41:49 GMT

Last week, we posted about the availability of the Visual Studio 2010 and .NET Framework 4.0 CTP, which includes Parallel Extensions to the .NET Framework. This preview release is available as a Virtual PC (VPC) image. Unfortunately, a VPC image isn't great for showcasing parallel processing, as even on a machine with many cores, the guest OS will only have a single virtual core.

Over on his blog, Grant Holliday has put up a nice guide to converting the VPC image into a Hyper-V image. Why is this useful? Because the guest OS can see up to four virtual cores, which makes it an environment much better suited to trying out the parallel technologies included in Visual Studio 2010.

Note that as Grant states, "This is not an officially tested scenario. Things may or may not work. You’re on your own." Even so, it's nice to have options. Good luck!