Intel Software Network - <![CDATA[ OpenMP issue: a threadprivate pointer doen't work when it has the dimension attribute ]]> feed http://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/64009 en-us Re: OpenMP issue: a threadprivate pointer doen&#39;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
]]> http://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/64009/ Tue, 03 Mar 2009 00:02:12 -0800 http://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/64009/ ISN General Re: OpenMP issue: a threadprivate pointer doen&#39;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     |       |       |

]]> http://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/64009/ Tue, 03 Mar 2009 06:38:19 -0800 http://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/64009/ ISN General Re: OpenMP issue: a threadprivate pointer doen&#39;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. ]]> http://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/64009/ Tue, 03 Mar 2009 07:41:11 -0800 http://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/64009/ ISN General Re: OpenMP issue: a threadprivate pointer doen&#39;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
]]> http://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/64009/ Tue, 03 Mar 2009 11:24:49 -0800 http://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/64009/ ISN General Re: OpenMP issue: a threadprivate pointer doen&#39;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.


]]> http://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/64009/ Wed, 04 Mar 2009 01:02:56 -0800 http://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/64009/ ISN General Re: OpenMP issue: a threadprivate pointer doen&#39;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
]]> http://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/64009/ Wed, 04 Mar 2009 08:29:04 -0800 http://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/64009/ ISN General Re: OpenMP issue: a threadprivate pointer doen&#39;t work when it has the dimension attribute
Quoting - ymost
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.
]]> http://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/64009/ Wed, 04 Mar 2009 10:23:47 -0800 http://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/64009/ ISN General Re: OpenMP issue: a threadprivate pointer doen&#39;t work when it has the dimension attribute
Quoting - tim18
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
]]> http://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/64009/ Wed, 04 Mar 2009 15:37:19 -0800 http://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/64009/ ISN General Re: OpenMP issue: a threadprivate pointer doen&#39;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

Great idea, and it worked! I used the first option you offered, since I didn't want to risk using a threadprivate pointer again. This way I get a de-facto threadprivate pointer without the risk, and that's great.
I actually conjured up my own workaround too: I added a threadprivate integer to hold the address of the pointer after it is allocated (I extracted the address using the 'loc' function), and referred to the correct address in every thread by using the 'pointer(a,b)' mechanism. I think I'll switch to your method, though, since it's more elegant than mine, and more importantly, my method is not portable since the loc function and pointer mechanism are specific to the Intel compiler.
Thanks a lot!

Press ENTER to look up in Wiktionary or CTRL+ENTER to look up in Wikipedia
]]> http://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/64009/ Wed, 04 Mar 2009 23:37:28 -0800 http://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/64009/ ISN General Re: OpenMP issue: a threadprivate pointer doen&#39;t work when it has the dimension attribute
Quoting - tim18
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. ]]> http://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/64009/ Wed, 04 Mar 2009 23:56:53 -0800 http://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/64009/ ISN General