Native Parallelism with the Parallel Patterns Library

Sorry for the late response on this.  The C++0x library draft is here it has several crucial improvements to help with multi-threading (std::atomic, std::thread, and the locks), but doesn't address fine-grained concurrency in the same way that the PPL or the Concurrency Runtime does.  std::thread gives a developer a portable way to start threads (which is wonderful) and the atomics library and locks give folks a portable way to add thread safety and compare and swap operations, but the PPL provides a task abstraction and algorithms on top of it (similar to the STL algorithms) for describing potential concurrency in an application.  Specifically, I can build up generic 'algorithms' like those in the STL, for_each, accumulate, sort, transform and if as a developer I can guarantee that they won't be modified while being iterated upon (or provide safety), I can use the task_group and task_handles to implement versions of those algorithms that can be run in parallel. 

As far as getting access to ppl.h, check the blog at http://blogs.msdn.com/nativeconcurrency there is some content on the PPL, links to the CTP and links to the forums.

The helper function I showed make_task is not critical, it's a nicety.  task_handle is a template helper class and we need to specify a type for a functor.  I could use a std::function as the type, but again here this is binding it to a particular type, when the type of a lambda is intentionally anonymous, the helper function just makes it a little easier to express, particularly when the lambda is declared inside the constructor.

These are all syntactically correct (though compiled in this form)...

auto lambda1([](){  cout << " hello world from a task! " << endl';});

task_handle<function<void(void)>> task1(lambda1);
auto task2(make_task(lambda1));
task_handle<decltype(lambda1)> task2;

I can then schedule any of these with a structured_task_group or a task_group.

i.e.

structured_task_group tg;
tg.run(task1);
tg.wait();

or:
task_group tg;
tg.run(task2);
tg.wait();

structured_task_group is lighter weight and more efficient, but really for structured, nested or recursive scenarios (like building loops or algorithms), the task_group is more general purpose, the run and wait methods are threadsafe so can be use for unstructured parallelism, and work can be scheduled on it on multiple threads for example, or it can be waited on a separate thread than it was started on.

-Rick