I'm James Reinders and today we're going to talk about three key challenges that you need to have in mind as you approach adding parallelism to a project.

So you've heard about parallelism, you've heard about multicore, you're thinking about introducing parallelism to your project, either by doing some coding in your own team or perhaps buying some solutions from a supplier. What are the three key concepts you should be concerned about?

They're pretty simple, but extremely important.

One is scaling — or the scalability of your application as you develop it. Another is addressing correctness issues, and finally having an eye towards the maintainability of what you're producing.

So let's start with scaling, or scalability as it's often referred to. How well will your application scale to N processors? Perhaps you're looking at a dual-core or quad processor today and you're going to take advantage of it, but what are you doing about the future, what are you doing to think about the day when there are eight cores, or 16 or more? Are you really taking a look at how you design your approach to parallelism so you won't have to go back and redesign every few years as time goes on?

So the goal with scaling is not necessarily to get eight times performance out of eight processors. Let's go back and think about it more simply. You want your performance on two processors to be greater than it was on one processor, four processors to be greater than that and eight processors to be greater than four, and 16 processors to be greater, so you need to make that as more and more processors become available you've designed your program in such a way that it will find more and more opportunities for parallelism.

The best approach to getting scaling is to look for solutions that lend themselves to scalability. It turns out that those solutions will also help us with the other two cases, so let's go on and consider the other two challenges.

One that you may not have considered is correctness. How do you make sure that a parallel program is going to operate correctly? You may think that that is just normal debugging. Well there are a couple of types of failure that can happen only in a parallel program. They are called race conditions and deadlock. These are two types of failure that can only happen in a parallel program. And they are ones to understand: how are you going to code in such a way as to avoid them, and how are you going to have tools or techniques available to you to help debug these or eliminate them from your program? These issues are not readily debugged with tools that were designed only for sequential programs, and that's not surprising as sequential programs don't have these modes of failure.

So what is a race condition? A race condition is when two tasks running in parallel, two threads of execution running on different processors, don't properly co-ordinate their activities, and one of them runs off assuming something's happened that may not have quite happened yet. So race conditions are very difficult to debug unless you have tools specifically designed for that.

Deadlock is when you have multiple threads and one them is waiting for the other one and the other one is waiting for the first one and they just wait and wait and wait and no work ever happens. So these are sort of the opposites of each other — they are both about proper co-ordination between threads.

If you have a supplier who is supplying you software and they can't answer these basic questions about how they're addressing scalability or how they are avoiding deadlock or race conditions, you call on the question of whether that supplier has thought through their solution well enough. So these are key concepts to take a look at and understand whether you have a plan to address them or not.

Finally, maintainability. Are you allowing code to be written by an expert using very low level interfaces, things that will need to be rewritten time and time again and that very few people can maintain, or are you finding some level of abstraction?

We'll talk about abstraction in a future video, but if you use higher levels of abstraction you'll get more maintainable code. This is the equivalent of the question of whether you program in C, C++, Fortran or some higher level language, or do you program in assembly language.

There are equivalents in parallel programming, whether you're using higher-level abstractions like OpenMP, threading building blocks libraries, all sorts of different things that are available to you to program parallelism with — or are you diving down into native things like Posix threads or Windows threads.

One of them — abstractions — will give you greater maintainability. And maybe more importantly, a concept called future-proofing — trying to make your program ready for the day when there are more and more cores in the processors.

These are three concepts that I have given you at least a flavour of, and if you have a supplier or a design team adding parallelism, these are the three issues I would focus on first: what's your approach to focusing on scaling; what's your approach to make sure that correctness issues don't frustrate you and stall your project; and what do you have in mind for the maintainability of your application when you're done? Have you approached it with the idea of operating at the proper level of abstraction?