In this week’s multicore automation article, we talked about multicore and we talked about concurrency. It’s easy to conflate these two concepts, so an important distinction should be drawn. The terminology isn’t particularly precise here, but the notions are.

“Multicore” typically refers to a computing platform. The number associated with it is the number of cores available for running a program. This number is completely independent of the program being run (although for embedded systems, it may have been designed with a specific program in mind).

“Concurrency” is a property of a program. It reflects how easy it is to pull apart and parallelize. It has nothing to do with a computing platform. A given algorithm can be designed with more or less opportunity for concurrency.

In a perfect world, the multicore structure matches the concurrency of the program being run. In the real world, a given program may need to be made to work on a number of different platforms. The more concurrency opportunities there are in a program, the more it can be optimized for different multicore platforms. If it’s really only possible to split a program in two, then a four-core platform will be no better than a two-core platform.

For this reason, it can be beneficial to optimize your program for as much concurrency as possible so that it can be partitioned in many different ways over many different platforms.