Cannot understand the error reported by Thread Checker
Hello, I have the following loop parallelized with openmp directives:
do jg = 1,ng c$omp parallel shared (jg,nr,nt,in,out) private (c1,i) c$omp do schedule(dynamic,1) do i = 1, nr c copying the column of the three-dimensional array to c one-dimensional array c1 of the size nt c1 = in(0:nt-1,i,jg)
c calling some function affecting c1 f1 (c1,nt)
c copying the transformed array to output three- c dimensional array out(0:nt-1,i,jg) = c1 enddo c$omp end do nowait c$omp end parallel enddo
While analyzing this code region with Thread Checker the read/write error is reported in this parallel region. But as I suppose there is no conflict in read/write access becuase each parallel thread deals with its own column of in and out arrays and c1 array is private to the threads.
How can I change this code to work properly? I can not exactly understand the nature of the error: whether it is impossible to declare the whole array c1 as private to the threads or the out array is treated as the instance i have to syncronyze access to.
If anyone dealed with parallelization in terms of openmp, would you please help me?
I need more of the source code to knowif your program is correct. For example, how is c1 declared? The code is incorrect if array c1 has an allocatable or pointer attribute because the private clause will only create a copy of the descriptor, not the full array.
The threads could be overflowing their stacks. How large is nt? According to the Intel compiler documentation, the stacksize for OpenMP threads is only 2 MB for IA-32 and 4 MB for Itanium. What does Thread Checker report for stack usage?
Thefunction f1might not bethreadsafe? Is f1 included in the Thread Checker analysis?
Thank you for your answer. My c1 array is declared as local automatic array. Maybe the problem is the stack size. I've applied the attachment with the source code of the procedure. In my example ng = 2, nt = 1024 and nr = 450. Changing implicit loops on the explicit ones didn't help, the problem remains, so I also apply the report of the thread checker in the next message. Thanks, Olga