tags:

views:

79

answers:

2

I have the following code:

#pragma omp parallel sections private(x,y,cpsrcptr) firstprivate(srcptr) lastprivate(srcptr)
{
    #pragma omp section
    {
       //stuff
    }
    #pragma omp section
    {
       //stuff
    }
}

According to the Zoom profiler, two threads are created, one thread executes both the sections, and the other thread simply blocks!

Has anyone encountered anything like this before? (And yes, I do have a dual core machine).

A: 

No, I can't say that I have encountered anything quite like this before. I have encountered a variety of problems with OpenMP codes though.

I can't see anything immediately wrong with your code snippet. When you use the Zoom profiler it affects the execution of the program. Have you checked that, outside the profiler, the program runs the sections on different threads ? If you have more sections do they all run on the same thread or do they run on different threads ? If you only have two sections, add some dummy ones while you test this.

High Performance Mark
+1  A: 

I guess I don't know too much about profilers yet, but one problem I've run into is forgetting to use the OpenMP flag and enable support.

Alternatively, what if you just created a simple application to try to verify the threads?

#pragma omp parallel num_threads(2)
{
#pragma omp critical
    std::cout << "hello from thread: " << omp_get_thread_num() << "\n" << std::endl;
}

Maybe see if that works?

Brett
+1 for using num_threads(2) - sometimes you actually have to force OpenMP to use multiple threads, as it will occasionally decide to serialize everything if there are no processors available. I think you can use omp_get_max_threads() to get the maximum number that it will use, or you could ask your system how many procs it has and use that value inside num_threads(). Good luck!
Mike