[Omp] A question about OpenMP 2.5
Greg Bronevetsky
greg at bronevetsky.com
Tue Mar 20 11:34:38 PDT 2007
The spec doesn't forbid multiple threads from reading the same variables,
so in this case it doesn't matter wherther different elements of a[] are
the same variable or different variables. The problem is with b[]. If
different elements of b[] are the same variable then Brad's loop is
invalid. If they're different variables, then its valid.
Greg Bronevetsky
On Tue, 20 Mar 2007, Dieter an Mey wrote:
> I understood the question differently.
>
> My understanding is that Brad found a contradiction between
>
> "... array elements ... are not considered variables"
>
> so the whole array is considered to be a "variable" in the terms of the
> OpenMP specs, which is shared by default in the given simple example
>
> >>> #pragma omp parallel for
> >>> for (i=1; i<n; i++) /* i is private by default */
> >>> b[i] = (a[i] + a[i-1]) / 2.0;
>
> and then because of
>
> >>> If multiple threads write to the same shared variable
> >>> without synchronization, the resulting value of the variable
> >>> in memory is unspecified. If at least one thread reads from
> >>> a shared variable and at least one thread writes to it without
> >>> synchronization, the value seen by any reading thread is
> >>> unspecified.
>
> the result of the piece of codes is unspecified although it is
> completely OK.
> I don't think that this is related to atomicity.
> a[2] is not written anywhere?
> Am I missing something?
>
> regards,
> Dieter
>
>
>
> Greg Bronevetsky schrieb:
> > Actually, I'm not so sure about that. The tricky business comes from the
> > fact that OpenMP never specifies a granularity of atomicity (i.e. "memory
> > locations" have no defined size). Its normally something like 32 or 64
> > bits but theoretically, it could be anything. For example, suppose that
> > the variable in question is an array of 8-bit characters but the shared
> > memory system's internal communication messages send updates in 64-bit
> > chunks. In this case Brad's example wouldn't work.
> >
> > OpenMP does force the compiler to generate appropriate code to ensure that
> > at least named variables don't collide in this way. However, it is unclear
> > what guarantees are provided for the components of these variables. As
> > such, while I agree with Dieter that the spec needs to make this clearer,
> > unless the text below specifies a size for these memory locations, it is
> > not sufficient. In light of the difficulties of getting OpenMP implentors
> > agreeing to a particular size, a proper fix may even be too complex to
> > make it into 3.0.
> >
> > Greg Bronevetsky
> >
> > On Tue, 20 Mar 2007, Dieter an Mey wrote:
> >
> >> I guess, you are right.
> >>
> >> It seems that the specification should be corrected to say something like
> >>
> >> > If multiple threads write to the same ** memory location **
> >> > without synchronization, the resulting ** memory content **
> >> > is unspecified. If at least one thread reads from
> >> > a shared ** memory location ** and at least one thread writes to it
> >> > without
> >> > synchronization, the value seen by any reading thread is
> >> > unspecified.
> >>
> >> best regards,
> >> Dieter
> >>
> >>
> >>
> >> Brad Bell schrieb:
> >>> I have a question about the OpenMP 2.5 standard
> >>> http://www.openmp.org/drupal/mp-documents/spec25.pdf
> >>>
> >>> In Section 1.2.3 Data Terminology of spec25.pdf,
> >>> the following text appears:
> >>>
> >>> variable
> >>> A named data object, whose value can be defined and
> >>> redefined during the execution of a program.
> >>>
> >>> Only an object that is not part of another object is
> >>> considered a variable. For example, array elements,
> >>> structure components, array sections and substrings
> >>> are not considered variables.
> >>>
> >>>
> >>> In Section 1.4.1 Structure of the OpenMP Memory Model of spec25.pdf,
> >>> the following text appears:
> >>>
> >>> If multiple threads write to the same shared variable
> >>> without synchronization, the resulting value of the variable
> >>> in memory is unspecified. If at least one thread reads from
> >>> a shared variable and at least one thread writes to it without
> >>> synchronization, the value seen by any reading thread is unspecified.
> >>>
> >>> It appears to me that, given the text above, that Example A.1.1.c of
> >>> in the OpenMP 2.5 standard is not correct (or at least misleading).
> >>> Here is the code for that example:
> >>>
> >>> void a1(int n, float *a, float *b)
> >>> {
> >>> int i;
> >>> #pragma omp parallel for
> >>> for (i=1; i<n; i++) /* i is private by default */
> >>> b[i] = (a[i] + a[i-1]) / 2.0;
> >>> }
> >>>
> >>> 1. As I understand the parallel command above, different threads may
> >>> execute
> >>> the loop for different values of i.
> >>>
> >>> 2. As I understand, the variable b is a shared variable because it is
> >>> defined before the loop.
> >>>
> >>> 3. The arguments b to the routine a1 may be an array, for example
> >>> it may be declared in the calling program by
> >>> float b[SIZE];
> >>> where SIZE is any positive integer constant greater than or equal n.
> >>>
> >>> 4. In the case of 3 above, b is a variable, and b[i] is not a variable,
> >>> hence multiple threads may be writing to the same variable; namely b.
> >>>
> >>> 5. Thus, in the case described above, the result of the loop is undefined.
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Omp mailing list
> >>> Omp at openmp.org
> >>> http://openmp.org/mailman/listinfo/omp
> >>>
> >> --
> >> --------------------------------------------------------------------
> >> Dieter an Mey
> >> High Performance Computing Hochleistungsrechnen
> >> RWTH Aachen University Rechen- und Kommunikations-
> >> Center for Computing and Communication zentrum der RWTH Aachen
> >> phone: ++49-(0)241-80-24377 Seffenter Weg 23
> >> fax: ++49-(0)241-80-22134 52074 Aachen, Germany
> >> email: anmey at rz.rwth-aachen.de
> >> --------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> Omp mailing list
> >> Omp at openmp.org
> >> http://openmp.org/mailman/listinfo/omp
> >>
> >
> >
> > _______________________________________________
> > Omp mailing list
> > Omp at openmp.org
> > http://openmp.org/mailman/listinfo/omp
> >
>
> --
> --------------------------------------------------------------------
> Dieter an Mey
> High Performance Computing Hochleistungsrechnen
> RWTH Aachen University Rechen- und Kommunikations-
> Center for Computing and Communication zentrum der RWTH Aachen
> phone: ++49-(0)241-80-24377 Seffenter Weg 23
> fax: ++49-(0)241-80-22134 52074 Aachen, Germany
> email: anmey at rz.rwth-aachen.de
> --------------------------------------------------------------------
>
>
More information about the Omp
mailing list