A THREADPRIVATE variable is incorrectly used to pass data between parallel regions.
The THREADPRIVATE directive specifies that variables are replicated, with each thread having its own copy. Because OpenMP* assigns work to threads in a somewhat unpredictable fashion, the value of a particular thread's copy becomes indeterminate after a scheduling point. These error diagnostic flags cases where a THREADPRIVATE variable was read when its value was in an indeterminate state.
There are two main ways a THREADPRIVATE variable can become indeterminate. One case is when leaving a parallel region in which the variable was modified. The problem here is that it is generally impossible to predict which threads will have executed which assignments. Another case is when entering a parallel region. The problem here is that it is generally impossible to predict which threads will be enlisted to join the team that executes the region. Of course, if a parallel region has a COPYIN clause, then the copy of that variable for each member of the team is initialized on entry from the copy of that variable belonging to the master thread.
Specifically, this message flags the case where a value was assigned to a THREADPRIVATE variable in one parallel region and then read in another parallel region. OpenMP only guarantees that the values of data in THREADPRIVATE variables of non-initial threads will persist between two parallel regions under very narrow circumstances. In particular, the same number of thread must execute both parallel regions, neither region can be (dynamically) nested within an explicit parallel region, and the regions must execute sequentially. In addition, the dyn-var internal control variable must be false on entry to both parallel regions. If all these conditions hold, then a threadprivate variable with the same thread number in their respective regions will access the same copy of that variable.
The specific message text for this diagnostic will explain what it was that caused the two parallel regions to fail to meet this criteria. There are a number of possible causes. For example, two SECTIONS regions that have different numbers of SECTION directives will not always be executed by the same number of threads.
Usually, this error indicates that a THREADPRIVATE variable is not appropriate for the specific usage pattern. It may be necessary to restructure the parallel regions to unify operations that are done in separate regions, or it may be necessary to flatten out the data between the two parallel regions without using THREADPRIVATE variables.
ID |
Observation |
Description |
---|---|---|
1 |
Bad memory access |
The place where the value was referenced |
2 |
OpenMP declaration |
The place where the value was earlier defined |
3 |
OpenMP declaration |
The region where the value was earlier defined |
#include <stdio.h> #include <omp.h> int a[1000]; #pragma omp threadprivate(a) int main(int argc, char **argv) { int i; int sum = 0; #pragma omp parallel for schedule(static, 5) for (i = 0; i < 1000; i++) { a[i] = i; } // The above loop will not map loop iterations to threads // in the same way that the following loop did because // the chunk size is different in the two loops. // Therefore the threadprivate array "a" cannot be used to // pass values from the first loop into the other in parallel mode. #pragma omp parallel for reduction (+:sum) schedule(static, 20) for (i = 0; i < 1000; i++) { sum = sum + a[i]; } printf("%d\n", sum); return 0; }
Copyright © 2010, Intel Corporation. All rights reserved.