Parallel Computing Platform: Asynchronous Agents for Native Code

mwirth,

Much of the functionality we’ve talked about in the Asynchronous Agents Library and the Parallel Pattern Library in these past 2 videos is implemented as template classes and methods in header files; they aren’t policy driven template classes, but they also don’t require you to implement a COM interface either to use them.   The Agents & Parallel Pattern Library (PPL) are built on top of the Concurrency Runtime itself, which will likely have some significant non-template code (e.g. compiled binary).

CraigL,

Regarding OpenMP: Agents and the PPL are not necessarily a replacement for OpenMP, consider them library based alternatives. The Agents library in particular is orthogonal in the scenarios it addresses to what’s provided in OpenMP.  We haven’t announced any ship or product dates for the work that we’ve discussed in these two videos or on our blog at http://blogs.msdn.com/nativeconcurrency so when folks ask what to do in the interim in C++, I’ll tend to suggest looking at what’s available right now like OpenMP if it fits the pattern.  The other forward looking guidance that can serve is to start preparing by decomposing applications now into isolated tasks and components that minimize shared state to avoid those pesky correctness issues when you go to parallelize them.

Hope this helps,

Rick

A couple of quick responses here.

Craig, OpenMP can be a quick way to get started today. Particularly if all you are looking to parallelize a for loop (make sure you look at the different scheduling options in particular 'dynamic').

WRT to UI threads (or other) threads, the runtime doesn't do anything special for threads it doesn't know about which means that the OS will round-robin those threads with the other running threads on the system. There are some knobs in the runtime which we'll probably discuss at a later which can be used to be more particular with the scheduler and UI threasd. I'll also try to get a blog post up in the next week or so to talk about the message blocks in more detail and I'll probably mention communicating with UI threads at that point.

Jan,
You asked 'will I get into trouble if I call into legacy code' that used traditional threading constructs like mutexes and critical sections.  If by trouble, you mean things like deadlocks, it is possible to get into trouble, but it's also possible to avoid it.  You would need to take some care to ensure that thisinteraction works well and you aren't creating a deadlock or livelock. 

The message blocks (particularly call and tranform) mentioned in the video aren't re-entrant, which can be great at helping correctness, so  if I have a pipeline or network built up of a series of transforms there's only going to be one instance of each stage of that pipleine running by-default, though they can all be active at the same time.  However if as you mentioned you're interacting with legacy code in each stage that is taking locks, there may be a chance of deadlock.

Regardin erlang, this is still a C++ library so the language constraints of C++ will still apply.  However as we mentioned, the message blocks provide a certain degree of ordering and for 'call' and 'transform' they aren't re-entrant. We'll also make copies of messages between blocks.  As I'm sure Niklas mentioned, it's possible to get yourself into trouble if you're passing pointers around, but it's also very possible to avoid a lot of trouble by following best practices.