On Apr 27, 5:14 pm, Charles Coldwell <coldw...@[EMAIL PROTECTED]
> wrote:
> [N.B. Fortran keywords are capitalized below.]
>
> jomarbue...@[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
Hi Chip,
Thank you for your answer. I am a bit puzzled about your explanation
that the threads are clobbering each other's lvalues in the second
loop. I might be missing something in the way that OpenMP works. As I
understand, the parallel do directive before the outer loop will make
sure that different threads use different non-overlaping sets of
values of i2. Thus I'd expect that at a given time each thread is
working on a different column of x, thus the memory location x(i1, i2)
written too in the second inner loop is different for each thread
(that is, even though all threads write to the same set of rows, they
are writing different columns). Am I correct in this assumption or am
I missing something fundamental about OpenMP?
Just in case, I re-wrote the construct as an "!$omp parallel (without
the do) in which the range of values of i2 is calculated explicitly
for each thread from omp_get_thread_num() and omp_get_num_threads().
In this case, I'm making sure that the range of i2 values (and thus
the columns) that different threads use do not overlap. I still have
the same problem -the program hangs.
Thank you again for your response,
Jomar
|
