[Omp] A question about OpenMP 2.5
Shah, Sanjiv
sanjiv.shah at intel.com
Tue Mar 20 11:32:43 PDT 2007
Folks,
a and b are pointers in C, they are not arrays. The pointers are never
written in this loop.
Sanjiv
--
Sanjiv
217/403-4244 office
217/419-4390 mobile
-----Original Message-----
From: omp-bounces at openmp.org [mailto:omp-bounces at openmp.org] On Behalf
Of Dieter an Mey
Sent: Tuesday, March 20, 2007 1:28 PM
To: Greg Bronevetsky
Cc: omp at openmp.org; Brad Bell
Subject: Re: [Omp] A question about OpenMP 2.5
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
--------------------------------------------------------------------
_______________________________________________
Omp mailing list
Omp at openmp.org
http://openmp.org/mailman/listinfo/omp
More information about the Omp
mailing list