parallel roads

I’m getting ready for my session at PDC 2009, Forever C++ and thought that I would take a moment to provide an outline of what I’ll be talking about and demo’ing.

First and foremost, I’ll be providing an overview of the programming model in the Parallel Pattern Library and Asynchronous Agents Library.  I’ll hit a lot of the APIs, how to use them and how to apply them to your application.   I’ll touch on a few of the algorithms and extras we provided in the sample pack as well.

I’ll also cover our tooling support for debugging and profiling multi-threaded applications in  Visual Studio 2010 and I’ll show you how (hopefully) how to recognize a couple common patterns that are particularly useful when profiling PPL code in the new concurrency view of the profile.

Finally, I’ll talk about a couple ways you can coordinate your concurrent work, manage shared state across tasks and threads and integrate this into your existing application.  I won’t be able to spend as much time on this as I had originally hoped, but myself and others from the team will be at our booths and at ‘ask the experts’ so there will be plenty of opportunities for you to ask your specific questions or share feedback with us.

Finally just thought I’d share a screenshot of one of our demos running on a high core count box.

Unfortunately this box won’t be at PDC but I’ll show this app launched on my quad-core briefly and Dana Groff will be showing it live in on a high core count server box in his talk on the Concurrency Runtime (SVR10).

Finally rumour has it that Dana and I will be doing another short talk in the Theatre Wednesday at 1pm.

Hope to see you there…

-Rick

Inspired by some pretty cool slides by Mike Acton that came through my twitter feed last week, I implemented a version of the Sleeping Barber problem.

For those not familiar with the problem, it’s a story that illustrates some of the perils associated inter process / inter thread synchronization, wikipedia describes it as:

The analogy is based upon a hypothetical barber shop with one barber, one barber chair, and a number of chairs for waiting customers. When there are no customers, the barber sits in his chair and sleeps. As soon as a customer arrives, he either awakens the barber or, if the barber is cutting someone else’s hair, sits down in one of the vacant chairs. If all of the chairs are occupied, the newly arrived customer simply leaves.

Wikipedia was also kind enough to provide pseudo-code for he boring three semaphore solution so an implementation was straightforward and only took a few minutes. 

Here’s the skeleton of the outline

Here’s the snippets of the outline, first 3 semaphores and a counter:

 cooperative_semaphore customers_semaphore(0,num_customers,L"C");
 cooperative_semaphore barber_semaphore(0,num_barbers,L"B");
 cooperative_semaphore seats_semaphore (1,num_seats,L"S");
 int free_seat_counter = num_seats;

In his blog, Herb Sutter recently posted notes from the latest C++ standards meeting:

For me, easily the biggest news of the meeting was that we voted lambda functions and closures into C++0x. I think this will make STL algorithms an order of magnitude more usable, and it will be a great boon to concurrent code where it’s important to be able to conveniently pass around a piece of code like an object

Introducing lambdas into C++ is extremely exciting.  Their omission has been one of the primary reasons why I’ve been finding myself using C# more and more for the little automation projects I often build to get work done.

Herb elaborates their value, I think he *almost* understates their value

C++ has always supported this via function objects, and lambdas/closures are merely syntactic sugar for writing function object

but it is quite clear from his tone that he is actually hugely excited about their inclusion.  In fact he goes on to provide a few examples, I’ll reiterate because the difference is quite dramatic and worth repeating.

 

Let’s compare using a function object to a lambda

Imagine you have a class widget that provides a weight function:

   class Widget{
   public:
       int Weight(){
           return m_weight;
       };
   };

Say you have a vector of them

   vector<Widget> w;

So far so good, right?  But here’s where it starts to get cumbersome… If now you’d like to find one of these widgets that has a weight greater than 100.  The stl has this great helper function for doing this called find_if and we’d like to use it…

So first we have to create a function object, it has to be declared outside of the scope of the function we’re using:

   class GreaterThan {
       int weight;
   public:
       GreaterThan( int weight_ )
          : weight(weight_) { }
       bool operator()(Widget& w ) {
           return w.Weight() > weight;

       }
   };

Great, now using it isn’t so bad, but unfortunately because the function object got declared out of scope an awful lot of context was lost and the code gets less readable.

   find_if( w.begin(), w.end(), GreaterThan(100) );

The lambda allows us to instead *skip* declaring the function object and just work inline:

   find_if( w.begin(), w.end(),[&]{return w.Weight() > 100;});

From a usability perspective this is a huge win. 

• We all like to write less code, as near as I can tell this removed 8 lines of code.
• We’ve also removed a level of indirection by declaring the lambda inline.

Please don’t underestimate the value of these because they are huge.  Developers are pretty darn good at keeping large numbers of concepts like this lowly function object and extra 8 lines of code in their head, but there really is no reason to do this unnecessarily.

 

And don’t forget about loops!

Using lambdas inside of loops may seem awkward at first, but it’s something that I think will grow on us:

   for_each( v.begin(), v.end(), []( Widget& w ){
       …

       //use or modify w

       …
   });

I can’t wait for C++0x!

-Rick