[N.B. Fortran keywords are capitalized below.]
jomarbueyes@[EMAIL PROTECTED]
writes:
> The main problem I'm having is with subroutines, not with functions.
If you think about it for a second, you'll realize that there's no
such thing as a nontrivial PURE subroutine. A PURE function is one
where the return values depends only on the values of the actual
arguments passed, not on any prior execution. Since a subroutine has
no return value, it cannot be PURE, otherwise it would simply be a
no-op that the compiler could optimize away.
> The object of the subroutines is to do an in-place calculation and
> thus they modify at least one of the arrays passed as arguments.
Another key feature of a PURE subroutine is that all of the dummy
arguments could be passed by VALUE. Since a PURE function does not
alter system state, in particular it does not alter the values of its
actual arguments, so these can be passed by VALUE.
> However, the output array depends strictly on the input
> arguments. There is no state to keep track off. In the parallel
> ****tion, I tried making private copies of the array that the
> subroutines change. I also tried making private copies of all arrays
> the subroutines use. Neither approach worked.
IIUC, the problem was in a section of code that looks something like
this:
!$omp parallel do private(wk, i2, i1) shared(x, z)
do i2 = 1, N2
do i1 = 1, N1
wk(i1) = x(i1, i2)
end do
call <NetLibSubroutine>(wk, z, <other stuff>)
do i1 = 1, N1
x(i1, i2) = wk(i1)
end do
!$omp end parallel do
The problem here is most likely coming in the second DO loop.
Although wk is private, x is shared, and all the threads are executing
the same iterations over i1, and therefore clobbering each other's
lvalues.
If this is the case, then the NetLib subroutine, reentrant or not, is
innocent.
Chip
--
Charles M. "Chip" Coldwell
"Turn on, log in, tune out"
GPG Key ID: 852E052F
GPG Key Fingerprint: 77E5 2B51 4907 F08A 7E92 DE80 AFA9 9A8F 852E 052F
|
