Computer systems have fully entered the age of multi-core processing. This trend was examined in a white paper entitled, "Preparing for the Revolution, Maximizing Dual-Core Technology." While much of the focus had been on dual-core processors, Intel has now delivered quad-core processors and AMD has announced quad-core availability in 2007. Software developers who are just taking advantage of multiple processors also need to be looking ahead since even larger multi-core platforms will reach the market soon. This new technology puts additional pressures on complex applications. In essence, the push beyond dual-cores has made the choice of development tools a key factor for successful projects.

When writing multi-core software, there are two important issues facing software developers. The first and most familiar is correctness of the program, i.e., does the program work properly and get the right answer. While this seems obvious, in multi-core applications, incorrect program behavior can arise from several sources not present in single-core design.

The second important feature is program performance. An assumption that speed-up is automatic just because a program has been modified to utilize multi-cores can be a huge mistake. Improved performance is not necessarily automatic or guaranteed.

With the introduction of quad-core processors, applications have the option of using eight cores on one dual-socket motherboard. Proper use of these additional resources will be critical to software development. This article will provide some insight into these issues and present some solutions to the problems facing multi-core programmers using the Linux operating system.

Prerequisites
As suggested in the white paper mentioned above, some consideration should be given to the method of parallelization. Two basic models are available to programmers - program threads and message passing. While message passing is the predominant method used in High Performance Computing (HPC), threads are becoming more important as both the core and socket sizes increase in most new motherboards.

Given that message passing programming is covered by other sources, this article will focus on threaded programming on multi-core processors using Linux.

A general approach to parallel computing is first to take a working sequential program, a program that is known to operate correctly on one CPU, and use it as the basis for a parallel program. This technique has two big advantages. First, the program can be tested to ensure that it operates at an acceptable level of correctness. (i.e., the program works and any issues are known in advance). Second, the programmer has a performance baseline with which to measure the new multi-core program.

If a new program is being written, it's highly advisable to create and debug a sequential version first. Adding the additional complexity of parallel programming to standard software development makes isolating bugs and problems more difficult.

In general, threaded programs often have multiple independent parts that share the same data set. One way to use threaded programming is to allow subroutines to operate independently and at the same time. It's also possible to break large loops up into threads as well. In all cases, however, a good design will allow the threaded version to "collapse" into a single thread by setting a thread count variable to one.

Finally, since there are adequate resources for learning about threaded programming, we'll concentrate on ways to ensure correct program operation and optimal performance.

Programming with Threads
The thread model is a way for a program to split itself into two or more concurrent tasks. These tasks can be run on a single processor in a time-shared mode, or on separate processors (e.g., the two cores on a dual-core processor can each run threads). The term thread comes from "thread of execution" and is a reference to how a fabric (computer program) can be pulled apart into threads (concurrent parts). Threads are different from individual processes (or independent programs), because they inherit much of their state information and memory from the parent process. Threads provide the ability to share memory and offer very fine-grained synchronization with other sibling threads.

On Linux and Unix systems threads are often implemented using a POSIX Thread Library (pthreads). There are several other thread models (Windows threads) from which the programmer can choose, however, using a standards-based implementation like POSIX is highly recommended. As a low-level library, pthreads can be easily included in almost all programming applications. This article will discuss debugging and optimizing Linux threads.

Ensuring Program Correctness
Of course, all programmers know that just because a program finishes, it doesn't mean the answers are correct. With multi-core programming, this situation may manifest itself differently. The same program and data, run at different times, may produce different answers, or cease functioning altogether for no apparent reason. We'll explore some of these causes and present some solutions.

Deadlock and Livelock
Because individual threads share memory and I/O, there must be a way for each thread to protect memory segments and I/O resources while they're using it. To solve this problem, threaded code employs "locks" that provide the thread exclusive access to a resource.

While the introduction of locks provides a solution to this problem, it also creates the possibility of a deadlock occurring in the program. Consider the following scenario where there are two global variables called Total and Sub-Total.

Process 1 locks the variable Total
Process 2 locks the variable Sub-Total
Process 1 attempts to acquire a lock on Sub-Total
Process 2 attempts to acquire a lock on Total

The program is now in a deadlock situation. Deadlock may develop every time the program runs or it may happen randomly when the timing is right. There's also a condition called "livelock" that's similar to deadlock. Livelock results when a thread or threads are constantly trying to acquire a lock, but can't because it's being used by another part of the program (or more likely hasn't been unlocked properly). Livelock may stop certain threads, but not necessarily cause the whole program to stop. With livelock, a program may appear to be working, but in reality it's often stuck in a loop, which can make it hard to determine the exact cause of the problem.

While deadlock and livelock can often be recognized through program behavior (i.e., the program stops, crashes, or gets stuck in one place), locating the cause can be difficult at times unless you can look at the threads in real-time. Certain lock conditions have a temporal component and can be hard to reproduce unless the program is running in production mode (i.e., a specific sequence or timing of events caused the situation).