OpenMP issue: a threadprivate pointer doen't work when it has the dimension attribute
Hi,
I have a problem using OpenMP with the ifort compiler version 11.0.
Consider the following test program:
program test
use mod_test, only: check
implicit none
integer,pointer,save :: p=>null()
!$omp threadprivate(p)
!$omp parallel
allocate(p)
call check(p)
!$omp end parallel
end program test
The program uses this module:
module mod_test
implicit none
contains
subroutine check(num)
integer,pointer :: num
if (associated(num)) write (*,*) 'associated'
end subroutine check
end module mod_test
On a 4-cpu machine this program prints the word 'associated' 4 times, as predicted.
If, however, the pointer p is given the 'dimension' attribute, only the first thread that executes the parallel region works as anticipated. In the last three threads the condition is evaluated as false. Here is the modified program that produces the error:
program test
use mod_test, only: check
implicit none
integer,dimension(:),pointer,save :: p=>null()
!$omp threadprivate(p)
!$omp parallel
allocate(p(1))
call check(p)
!$omp end parallel
end program test
The program uses this module:
module mod_test
implicit none
contains
subroutine check(num)
integer,dimension(:),pointer :: num
if (associated(num)) write (*,*) 'associated'
end subroutine check
end module mod_test
Is this a compiler bug or what?
Thanks
| |
Re: OpenMP issue: a threadprivate pointer doen't work when it has the dimension attribute
In my post I didn't use the 'insert cose' feature, and so the code was not very readable. I apologize - and I fixed the original post.
I would appreciate any help with my problem,
Thanks
| |
Re: OpenMP issue: a threadprivate pointer doen't work when it has the dimension attribute
As no one else has bitten, I'll say that I don't know how the result of this code could be predicted. Do you mean, is it a compiler bug that it doesn't give more diagnostics? OpenMP is notorious for not checking at compile time. That's one of the reasons for the Intel Thread Checker.
|1 |I/O |Error |1 |omp |I/O operation at "ym2.f90":4 |"ym2.f9|"ym2.f9|
| |data-race| | |parallel|conflicts with a prior I/O |0":4 |0":4 |
| | | | |region |operation at "ym2.f90":4 | | |
|1 |I/O |Error |1 |omp |I/O operation at "ym1.f90":4 |"ym1.f9|"ym1.f9|
| |data-race| | |parallel|conflicts with a prior I/O |0":4 |0":4 |
| | | | |region |operation at "ym1.f90":4 | | |
| |
Re: OpenMP issue: a threadprivate pointer doen't work when it has the dimension attribute
I have been looking at this too. The OpenMP spec specifies special handling related to POINTER and ALLOCATABLE only when certain conditions do not hold, but I believe the second case should see the array pointer as associated by all threads the same as all threads see the pointer as associated in the first case. I will inquire with the developers and update the thread when I know more.
| |
Re: OpenMP issue: a threadprivate pointer doen't work when it has the dimension attribute
Try something like this:
program test
use mod_test, only: check
implicit none
integer,dimenstion(:), pointer,save :: p=>null()
!$omp threadprivate(p)
! Above is in variable declarations of program test
! ...
! initialization portion of program test
!$omp parallel
nullify(p) ! shouldn't be required, used for work-around
!$omp end parallel
! ...
! compute section of program test
!$omp parallel
allocate(p(1))
call check(p)
!$omp end parallel
end program test
Jim Dempsey
Blog: The Parallel Void
www.quickthreadprogramming.com | |
Re: OpenMP issue: a threadprivate pointer doen't work when it has the dimension attribute
Quoting - tim18:
"...I don't know how the result of this code could be predicted..."
To me it seems clear: there are 4 copies of the pointer p, one for each thread. Each one is being allocated and then tested for association, and it should always be associated.
Quoting - Kevin Davis (Intel):
"...I will inquire with the developers and update the thread when I know more"
Thanks!
Quoting - jimdempseyatthecove:
"Try something like this:
...
!$omp parallel
nullify(p) ! shouldn't be required, used for work-around
!$omp end parallel
..."
Thank you for your suggestion, it is true that in many occasions nullifying a pointer before using it can solve problems later on. Unfortunately, in this case this does not make any difference.
| |
Re: OpenMP issue: a threadprivate pointer doen't work when it has the dimension attribute
OK - Plan B
Create a user defined type for holding thread private data.
Inside this type place the pointer to allocatable array
Create an instance of the defined type for holding thread private data as thread private
OR
Create a pointer to an instance of the defined type for holding thread private data as thread private (and allocate in each thread).
I have a Windows based Fortran program that does the latter so I know this works
Jim Dempsey
Blog: The Parallel Void
www.quickthreadprogramming.com | |
Re: OpenMP issue: a threadprivate pointer doen't work when it has the dimension attribute
Quoting - tim18:
"...I don't know how the result of this code could be predicted..."
To me it seems clear: there are 4 copies of the pointer p, one for each thread. Each one is being allocated and then tested for association, and it should always be associated.
I've not found any reference to tell what a threadprivate directive outside a parallel region would do . It's not clear to me that it would take effect in the next, or all following, parallel regions. Your intention may be clearer to you than to me or to the compiler. I thought maybe your idea was the compiler should tell you what (if anything) is wrong with the source code. That's why I suggested attention to the race condition diagnosed by Thread Checker.
| |
Re: OpenMP issue: a threadprivate pointer doen't work when it has the dimension attribute
I've not found any reference to tell what a threadprivate directive outside a parallel region would do . It's not clear to me that it would take effect in the next, or all following, parallel regions. Your intention may be clearer to you than to me or to the compiler. I thought maybe your idea was the compiler should tell you what (if anything) is wrong with the source code. That's why I suggested attention to the race condition diagnosed by Thread Checker.
??
When you call a subroutine scalar variables are on stack (automatic vectors are on stack or descriptor on stack and data from heap)
If this subroutine is called from a parallel region, each thread having its own stack will thus have a private copy of those stack variables while all using the same symbolic name.
That I think you understand.
Now wouldn't it be nice if each thread in a multi-threaded program could have a thread private data items that share the same name in all threads but in fact reference different data (same as stack model). You may want to place temp arrays in the thread private area or some sort of context information (e.g. pointer to some object owned by the thread).
This thread private area is independent of entering or exiting !$OMP PARALLEL regions excepting for when the !$OMP PARALLEL region creates additional thread(s). When a thread is created, it gets a copy of the current state of the master threads thread private data.
Care must be taken as a copy of the thread private data from the master thread may contain allocated arrays. It may not be polite for the 2nd thread or later thread to deallocate or disturb this array if the array was intended to be a private copy for the master thread. To help get around that consider using a pointer to the array which you can NULLIFY and/or allocate.
Thread initialization of the thread private data area can be done once early in the program.
Caution, should you use nested parallel regions care must be taken for initialization of those threads private data as well.
ThreadPrivate is a compiler directive not a runtime directive.
Symbols marked with threadprivate have a little more overhead in access. The runtime system maintains a pointer to the thread private data area. The compiler auto-magicly inserts an additional dereference via this pointer for thread private data.
Experiment with thread private data as it can really help improve performance in areas where you want large thread scratch data arrays (too large for stack).
Jim Dempsey
Blog: The Parallel Void
www.quickthreadprogramming.com | |
Re: OpenMP issue: a threadprivate pointer doen't work when it has the dimension attribute
I've not found any reference to tell what a threadprivate directive outside a parallel region would do . It's not clear to me that it would take effect in the next, or all following, parallel regions.
A threadprivate directive can only be used outside a parallel region. Quoting section 2.9.2 from the OpenMP specification, page 84, line 34:
The threadprivate directive must appear in the declaration section of a scoping unit in which the common block or variable is declared.
The declaration section can never be in a parallel region. The threadprivate directive changes the status of the variable for all consecutive parallel regions that have the same number of threads. Notice also that the first version of the program I attached works perfectly, it is only the addition of the 'dimension' attribute that causes the error, and this is probably a compiler bug.
| | |
