Terminology question: Why is Parallel part of TPL?

Fri, 03 Jul 2009 14:25:05 Z

How do we explain to people why the Parallel class considered part of the Task Parallel Library?
http://msdn.microsoft.com/en-us/library/dd460693(VS.100).aspx

It doesn't appear to have anything to do with tasks.

In fact, the Parallel class is much closer to PLINQ than the Task class in its model: the Parallel class and PLINQ both offer structured data parallelism . I would consider the two sit side-by-side, with the Task class (and Task's associated classes) underneath.

Intuitively, the types in System.Threading.Tasks would seem to constitute the Task Parallel Library:

Task
Task<TResult>
TaskFactory
TaskFactory<TResult>
TaskScheduler
TaskCompletionSource

and nothing else.

Unless it's the Task / Parallel Library :)

Joe

Write LINQ queries interactively - www.linqpad.net

Terminology question: Why is Parallel part of TPL?

Fri, 03 Jul 2009 19:57:03 Z

re: "How do we explain to people why the Parallel class is considered part of the Task Parallel Library"

That's largely how it evolved. At this point, both Parallel and Task (and the types that support both) are core components of the .NET Framework, and from that perspective the "Task Parallel Library" moniker is just a nice way of grouping some new technologies for explanatory purposes, but isn't necessary for any technical reason.

re: "It doesn't appear to have anything to do with tasks"

Parallel does use tasks extensively under the covers, evidenced by the fact that ParallelOptions accepts a TaskScheduler that can be used to target the Parallel.* operations' tasks to run on a particular scheduler (by default they run on TaskScheduler.Default as you'd expect). In effect, the methods on Parallel are very sophisticated task generators, and they're very closely intertwined from an implementation perspective, much more so than is PLINQ (at least in the current implementation).

Additionally, consider a method like Parallel.Invoke. If you want to perform multiple operations in parallel, it's likely the first place you start. If you then determine you need more control than Parallel.Invoke provides, you can replace it with starting on multiple tasks and waiting on all of them. From there you can do more sophisticated things. In that sense, Parallel.Invoke sits on the same spectrum as Tasks, in terms of productivity vs control/power.

re: "the Parallel class and PLINQ both offer structured data parallelism"

The line between what is data parallelism and what is task parallelism can get a bit blurry. Parallel.Invoke isn't really about data parallelism. Certainly Parallel.ForEach would seem to fall squarely into the data parallel camp, but then again, you could use Parallel.ForEach to iterate in parallel through a set of arbitrary delegates, invoking each (which is similar in concept to what Parallel.Invoke will do under the covers in some situations), in which case it's less about data and more about executing arbitrary tasks in parallel.

re: "Unless it's the Task / Parallel Library :)"

Sure, that works, too ;)

I personally use the TPL terminology as an easy mechanism to refer to set a of technologies that are being shipped in .NET 4, but I wouldn't get hung up on that. In the long term, I'd honestly expect that terminology to drop away, leaving behind what's actually important: the technology and what it can be used to accomplish.