Cap
Every element of Cap is highly customizable through our Theme Options. You can build page-based website or usual blog.
March 4th, 2010
Microsoft Developer & Platform Evangelism, in collaboration with the Microsoft Parallel Computing Platform product team, is hosting a developer lab at the Platform Adoption Center on April 12-15, 2010. This event is for Microsoft Partners and Customers seeking to incorporate either .NET Framework 4 or Visual C++ 2010 parallelism features into their new or existing applications, and to gain expertise with new Visual Studio 2010 tools including the Parallel Stacks and Parallel Tasks debugger tool windows, and the Concurrency Visualizer in the profiler.
Opportunities for attendees include:
The event has limited capacity, thus enrollment is based on an application process. Please download and complete the application form then return it to the event management team per instructions included within the form. Applications will be evaluated based upon the technical solution scenario along with indicated project readiness timelines. Microsoft event management team members may contact you directly for additional clarification and discussion of your project scenario during the nomination process.
March 2nd, 2010
.NET 2.0 introduced Generics to allow enhanced code reusability and type safety. Since then, generic collections (IEnumerable<T>, List<T>, Dictionary<T>, etc.) have become standard and are recommended over their non-generic counterparts (IEnumerable, ArrayList, HashTable, etc.). As a result, Parallel.ForEach only supports generic collections, so code like the following will fail to compile.
IEnumerable nonGenericCollection = …;
Parallel.ForEach(nonGenericCollection, currentElement =>
{
});
This issue applies to all non-generic collections (pretty much anything that was added before .NET 2.0), but here are some usual suspects that we’ve seen folks run into: XmlNodeList, DataRowCollection, DataTableCollection. The error message is typically something like the following:
· “The type arguments for method ‘System.Threading.Tasks.Parallel.ForEach<TSource>) cannot be inferred from the usage. Try specifying the type arguments explicitly.”
· “The best overloaded method match for ‘System.Threading.Tasks.Parallel.ForEach<object>(System.Collections.Generic.IEnumerable<object>, System.Action<object>)’ has some invalid arguments.”
Fortunately, the workaround is simple. Since non-generic collections produce objects (IEnumerator.Current returns Object), it is always possible to produce an IEnumerable<Object> from an IEnumerable. For example:
static IEnumerable<object> Cast(IEnumerable source)
{
foreach (object o in source)
yield return o;
}
Even more fortunately, LINQ already provides this functionality:
public static IEnumerable<TResult>
Cast<TResult>(this IEnumerable source);
So we can easily fix the initial example using this Cast extension method.
using System.Linq;
…
Parallel.ForEach(nonGenericCollection.Cast<object>(),
currentElement =>
{
});
February 15th, 2010
I previously posted in November about a paper I’d written on patterns for parallel programming. The original paper had over 200 snippets of C# code to demonstrate and exemplify the ideas being discussed. Due to popular demand (and in honor of the many Visual Basic MVPs on campus this week for the MVP Summit), we’ve now posted another version of the paper that uses Visual Basic instead of C#. You can download both versions of the paper from http://www.microsoft.com/downloads/details.aspx?FamilyID=86b3d32b-ad26-4bb8-a3ae-c1637026c3ee. Enjoy! And, as usual, feedback is always welcome and encouraged.
February 13th, 2010
We’re hiring! If you’re reading this post, you most likely have an interest in parallel or distributed computing, writing concurrent software, and the like. Take that interest a step further, and help us make the manycore era a successful reality by coming to work on the Parallel Computing Platform team at Microsoft.
We currently have several exciting positions available:
If you’re interested in any of these, please submit your resume and apply for the job through the "Apply to Job" button on the relevant page. We look forward to hearing from you!
February 11th, 2010
The new parallelization support in the .NET Framework 4 is implemented purely in libraries and the runtime and does not require special compiler support. Therefore, it is available to all compliant .NET languages. This includes all of the managed languages that ship as part of Visual Studio 2010 (Visual C#, Visual Basic, Visual F#, and C++/CLI) as well as other Microsoft-provided languages (e.g. IronPython) and 3rd-party developed languages. In fact, our samples available at http://code.msdn.microsoft.com/ParExtSamples include examples in multiple languages.
However, some of the APIs in .NET 4 have been designed with certain language capabilities in mind. For example, C#, Visual Basic, and F# all support lambda expressions and closures, which enable easily defining the bodies for Tasks and parallel loops. Query comprehensions in C# and Visual Basic, and sequences in F#, can help to write cleaner, more elegant PLINQ queries. F#’s support for asynchronous workflows and its provision of immutability of data by default are geared towards making it easier to write highly concurrent applications.
In summary, you can introduce parallelism in your application using any .NET language. Which one is best still depends on your scenario.
February 11th, 2010
The new parallelization support in the .NET Framework 4 is implemented purely in libraries and the runtime and does not require special compiler support. Therefore, it is available to all compliant .NET languages. This includes all of the managed languages that ship as part of Visual Studio 2010 (Visual C#, Visual Basic, Visual F#, and C++/CLI) as well as other Microsoft-provided languages (e.g. IronPython) and 3rd-party developed languages. In fact, our samples available at http://code.msdn.microsoft.com/ParExtSamples include examples in multiple languages.
However, some of the APIs in .NET 4 have been designed with certain language capabilities in mind. For example, C#, Visual Basic, and F# all support lambda expressions and closures, which enable easily defining the bodies for Tasks and parallel loops. Query comprehensions in C# and Visual Basic, and sequences in F#, can help to write cleaner, more elegant PLINQ queries. F#’s support for asynchronous workflows and its provision of immutability of data by default are geared towards making it easier to write highly concurrent applications.
In summary, you can introduce parallelism in your application using any .NET language. Which one is best still depends on your scenario.
February 10th, 2010
The F# team has released the F# PowerPack for download on CodePlex, and we’re very excited that the PowerPack now has direct support for PLINQ. From the CodePlex site:
F# Parallel LINQ Integration
FSharp.PowerPack.Parallel.dll provides an F#-style API for parallel operations on sequences that are part of .NET 4.0 as System.Linq.ParallelEnumerable class. The API is akin to F# operations on sequences:
let nums = [|1..500000|]
let finalDigitOfPrimes =
nums
|> PSeq.filter isPrime
|> PSeq.groupBy (fun i -> i % 10)
|> PSeq.map (fun (k, vs) -> (k, Seq.length vs))
|> PSeq.toArray
Enjoy!
February 10th, 2010
Reed Copsey, Jr. has been writing a great series of articles on parallelism with the .NET Framework 4. The articles provide the insights of an expert developer who has been using parallelism with .NET to speed up real-world programs. Recommended reading.
Parallelism in .NET
Part 2, Simple Imperative Data Parallelism
Part 3, Imperative Data Parallelism: Early Termination
Part 4, Imperative Data Parallelism: Aggregation
Part 6, Declarative Data Parallelism
Part 7, Some Differences between PLINQ and LINQ to Objects
February 9th, 2010
The aim of this post is to help developers writing applications in which operations may need to be performed and then later undone due to a subsequent failure. It shows a pattern for how to maintain such a consistent application state by utilizing functionality from the Task Parallel Library (TPL) in the .NET Framework 4.
For the purposes of this blog post, a program/routine is a state machine where each state is equally valid and important and should be handled correctly regardless of whether it belongs to a happy path or not. Specifically, a step that rolls back an incomplete state transition is equally important as a step that makes a forward state transition. A lot could be written about the advantages and disadvantages of exceptions vs. error codes, and such a discussion is not the goal of this post: for the purpose of this article, it is only worth mentioning that throwing and catching exceptions is focused on the happy path (it keeps the code clean and easy to comprehend), while returning and checking error codes is focused on detecting the places of the code (program states) where deviations from the happy path may occur.
In general, a routine that consists of n atomic forward steps, where each forward step may fail and then needs to be undone, could be modeled as the following state machine:

Assuming a step is atomic means we don’t have to undo that particular step if it fails. That is why the undo sequences in the diagram start with the last successful step.
Note: It is also assumed that undoing may not fail. If failures are possible to occur during rollback, then you should strongly consider using a real transactional resource manager like a database server.
Now that we’ve stated the problem, what is the best way to approach it? Obviously, there are solutions through either error checking or through exception handling, but both of those come at the expense of convoluting the code. Notice that the number of state transition paths is about three times the number of forward steps. Ideally, we are looking for a solution that has a clean happy path as well as clean undo paths without any if statements or separate Exception types for each forward step. In other words, we are looking for a way to describe a program as a state machine.
That’s exactly what the TPL does through tasks (as states) and continuations (as state transitions).
Let’s take a concrete application as an example and write some real code. Let’s say we have a system that manages the process of making a sandwich. In a terminal state our resources, bread and ham, are in the fridge. (For the sake of simplicity, we produce one sandwich at a time.) First, we take a slice of bread out of the fridge. Second, we take a slice of ham out of the fridge. Third, we assemble the bread and the ham into a sandwich. If an operation fails, we have to return whatever ingredients are currently on the line back to the fridge so they don’t rot:
And here is the code of our routine:
// HAPPY PATH
Task retrieveBread = Task.Factory.StartNew(RetrieveBreadFromFridge);
Task retrieveHam = retrieveBread.ContinueWith(_ => RetrieveHamFromFridge(),
TaskContinuationOptions.OnlyOnRanToCompletion);
Task assembleSandwich = retrieveHam.ContinueWith(_ => AssembleSandwich(),
TaskContinuationOptions.OnlyOnRanToCompletion);
// RESET STATE
TaskCompletionSource<bool> reset = new TaskCompletionSource<bool>();
assembleSandwich.ContinueWith(_ => reset.SetCanceled(),
TaskContinuationOptions.OnlyOnRanToCompletion);
// UNDO PATH
Task returnBread = new Task(ReturnBreadToFridge);
returnBread.ContinueWith(_ => reset.SetResult(true),
TaskContinuationOptions.OnlyOnRanToCompletion);
Task returnHam = new Task(ReturnHamToFridge);
returnHam.ContinueWith(_ => returnBread.Start(),
TaskContinuationOptions.OnlyOnRanToCompletion);
// HAPPY PATH -> UNDO PATH
// On a failure in bread retrieval – signal “reset”.
retrieveBread.ContinueWith(_ => reset.SetResult(true),
TaskContinuationOptions.OnlyOnFaulted);
// On a failure in ham retrieval – return bread
retrieveHam.ContinueWith(_ => returnBread.Start(),
TaskContinuationOptions.OnlyOnFaulted);
// On a failure in sandwich assembly- return ham and bread
assembleSandwich.ContinueWith(_ => returnHam.Start(),
TaskContinuationOptions.OnlyOnFaulted);
// WAIT
// Log the execution of the HAPPY PATH tasks.
// Additionally, wait on the reset state to get signaled.
Task[] loggedTasks = new Task[]
{retrieveBread, retrieveHam, assembleSandwich, reset.Task};
Task.Factory.ContinueWhenAll(loggedTasks,LogErrors)
.Wait();
As you can see, there are no if statements, nor are there any Exception types customized to provide information what step failed.
Finally, I added a logging task that effectively waits for all the state machine tasks to finish, and then traverses the given task array and logs any error messages. (Notice that I still have to wait for that task to finish.) The body of that method is straightforward:
private void LogErrors(Task[] tasks)
{
Console.WriteLine(“ntERRORS:”);
foreach (Task task in tasks)
{
if (task.IsFaulted)
{
// Use the InnerException since it is wrapped in an AggregateException
Console.WriteLine(“t{0}”, task.Exception.InnerException.Message);
}
}
}
In conclusion, TPL enables writing state-sensitive applications on the .NET platform without convoluting the application code with many if statements or customized exception types. While the code is still a little verbose, it closely resembles the state machine’s diagram. The attached zip file contains the complete C# project. Feel free to download it and play with it. Your feedback is welcome.