A Stroll Down Concurrency Lane
With the introduction of multi-core processors, parallel programmers face a tough decision.
Thursday, December 15th, 2005
If you develop software, then sometime in the near future you’ll be forced to make a decision. The decision will be a fork in the road, and once you choose a direction, you won’t be able to turn back. No developer will be spared. And no, it’s not another Perl Apocalypse.
As I noted in my premiere “Cluster Rant” column (available online at
http://www.linux-mag.com/2005-09/cluster_01.html), multi-core processors are going to change everything. To use multiple processors, applications will need to be poured into a concurrent framework of some sort, and once a framework is chosen, switching to another framework will be difficult (read: expensive). Now is the time to consider the implications.
This month and next, let’s look at concurrency, starting with the whole idea of doing two or more things at once.
Concurrent Versus Parallel
The terms concurrent and parallel are often used interchangeably, but the two aren’t the same thing. Concurrency is a property of a program or algorithm. If parts of a program can run independently, those parts are considered concurrent. If the independent parts can run on separate processors, then the program can further be called parallel.
Admittedly, the distinction between concurrent and parallel is subtle, so it may help to keep these three rules in mind:
1.Concurrency doesn’t necessarily imply parallel execution.
2.Concurrency is a property of the program.
3.Efficient parallel execution of concurrent programs depends on the hardware.
