The Basics of Compilation
Using the OpenMP pragmas requires an OpenMP-compatible compiler and thread-safe libraries. A perfect choice is the Intel C++ Compiler version 7.0 or newer. (The Intel Fortran compiler also supports OpenMP.) Adding the following command-line option to the compiler instructs it to pay attention to the OpenMP pragmas and to insert threads.
If you omit /Qopenmp on the command-line, the compiler will ignore OpenMP pragmas, providing a very simple way to generate a single-threaded version without changing any source code. The Intel C++ Compiler supports the OpenMP 2.0 specification. Be sure to browse the release notes and compatibility information supplied with the Intel C++ Compiler for the latest updates. The complete OpenMP specification is available from www.openmp.org.For conditional compilation, the compiler defines _OPENMP. If needed, this define can be tested as shown below.
#ifdef _OPENMP
fn();
#endif<
The general form of all OpenMP pragmas is:
If the line does not start with pragma omp it is not an OpenMP pragma. The full list of pragmas is located in the specification found at www.openmp.org.The C-runtime thread-safe libraries are selected using the /MD or /MDd (for debug) command-line compiler options. These options are selected, when using Microsoft Visual C++, in the Code Generation Category for C/C++ Project Settings by selecting either Multithreaded DLL or Debug Multithreaded DLL.
A Few Simple Examples
The following examples illustrate how simple OpenMP is to use. In common practice, additional issues need to be addressed, but these are great to get you going.
- Problem 1: The following loop clips an array to the range 0...255. You need to thread it using an OpenMP pragma.
Solution: Simply insert the following pragma immediately before the loop.
- Problem 2: The following loop generates a table of square roots for the numbers 0...100. You need to thread it using OpenMP.
Solution: The loop variable is not a signed integer, so that needs to be changed and the pragma needs to be added.
Avoiding Data Dependencies and Race Conditions
When a loop meets all five loop restrictions and the compiler threads the loop, it may still not work correctly due to the existence of data dependencies. Data dependencies exist when different iterations of a loop-more specifically a loop iteration that is executed on a different thread-reads or writes shared memory. Consider the following example that calculates factorials.
// Do NOT do this. It will fail due to data dependencies.
// Each loop iteration writes a value that a different
iteration reads.
#pragma omp parallel for
for (i=2; i < 10; i++)
{
factorial[i] = i * factorial[i-1];
}
The compiler will thread this loop, but it will fail because at least one of the loop iterations is data-dependent upon a different iteration. This situation is referred to as a race condition. Race conditions can only occur when using shared resources (like memory) and parallel execution. To address this problem either rewrite the loop or pick a different algorithm, one that does not contain the race condition.Race conditions are tricky to detect because, in a given instance, the variables might "win the race" in the order tha t happens to make the program function correctly. Just because a program works once doesn't mean that it will always work. Testing your program on various machines, some with Hyper-Threading Technology and some with multiple physical processors, is a good starting point. Tools such as the Intel Thread Checker can also help, as can a sharp eye. Traditional debuggers are useless for detecting race conditions because they cause one thread to stop the "race" while the other threads continue to significantly change the runtime behavior
Managing Shared and Private Data
Nearly every loop (at least if it's a useful one) reads or writes memory, and it's the programmer's job to tell the compiler which pieces of memory should be shared among the threads and which pieces should be kept private. When memory is identified as shared, all threads access the exact same memory location. When memory is identified as private, however, a separate copy of the variable is made for each thread to access in private. When the loop ends, these private copies are destroyed. By default, all variables are shared except for the loop variable, which is private. Memory can be declared as private in the following two ways.
- Declare the variable inside the loop-really inside the parallel OpenMP directive-without the static keyword.
- Specify the private clause on an OpenMP directive.
The following loop fails to function correctly because the variable temp is shared. It needs to be private.
// WRONG. Fails due to shared memory.
// Variable temp is shared among all threads, so while one thread
// is reading variable temp another thread might be writing to it
#pragma omp parallel for
for (i=0; i < 100; i++)
{
temp = array[i];
array[i] = do_something(temp);
}
The following two examples both declare the variable temp as private memory, which fixes the problem.
// This works. The variable temp is now private
#pragma omp parallel for
for (i=0; i < 100; i++)
{
int temp; // variables declared within a
parallel construct
// are, by definition, private
temp = array[i];
array[i] = do_something(temp);
}
// This also works. The variable temp is declared private
#pragma omp parallel for private(temp)
for (i=0; i < 100; i++)
{
temp = array[i];
array[i] = do_something(temp);
}
Every time you instruct OpenMP to parallelize a loop, you should carefully examine all memory references, including the references made by called functions. Variables declared within a parallel construct are defined as private except when they are declared with the static declarator, because static variables are not allocated on the stack.
