[J3] [SC22WG5.6483] RE: [ukfortran] [EXTERNAL] [BULK] are race conditions allowed in do concurrent?

Thu Sep 14 05:04:49 UTC 2023

Hi Brad,

There is no contradiction, subtle or otherwise, here.

Locality-specs are only for named variables. However, as noted, subobjects of variables are also variables.

> The way I've heard "definition" applied to arrays is that definition of an element of an array does not constitute definition of the variable,

Correct (except in the trivial case of an array with a single element). This is all spelled out explicitly: defining every “part” of a multi-part variable defines the variable.

I can see some potential wording improvements for the next revision, but nothing that rises to the level of a defect.

E.g. it may be better to mention that “if a variable has SHARED locality, all of its subobjects have SHARED locality”. It’s not written there now, because, like, how could it possibly be anything else? There is nothing else it could be.  But making it explicit would lead naturally into writing “If a variable with SHARED locality is defined…” instead of the current “If it is defined…”.

>variable/data entity/data object

>[are] circular, and doesn't seem to include individual array elements

Yes it does, see 3.138 subobject.

The circularity is unfortunate, but they are all reasonably worded for comprehensibility (not for trail-following). So it’s either deleting one of them (ugh) or rewording one to break the circle without making it hard to understand (it’s not obvious exactly what to do here, which is why it is still like this).

If it were a glossary of terms, instead of a list of definitions, there would be no problem with circularity, right?

Anyway, I agree it would be good to fix it as long as it doesn’t make any individual term hard to understand.

Given our experience this time around, I would be in favour of pruning our terms and definitions, down to a more minimal set. If there are “useful” terms that do not lend themselves to trivial drop-in replacement, and I think there are, we could consider adding a “Glossary” (of “useful terms”, but probably better not to call them “terms”!). 

Cheers,

-- 

..............Malcolm Cohen, NAG Oxford/Tokyo.

From: Brad Richardson <everythingfunctional at protonmail.com> 
Sent: Wednesday, September 13, 2023 3:49 AM
To: General J3 interest list <j3 at mailman.j3-fortran.org>; WG5 <sc22wg5 at open-std.org>
Subject: [ukfortran] [SC22WG5.6480] [EXTERNAL] [BULK] [J3] are race conditions allowed in do concurrent?

Hmm... I decided to work through this a bit more thoroughly.

>From the syntax definitions:

R902

variable

is designator

or function-reference

R901

designator

is object-name

or array-element

or array-section

or coindexed-named-object

or complex-part-designator

or structure-component

or substring

Ok, so according to the syntax an array element is a variable.

>From the terms and definitions:

variable

data entity (3.41) that can be defined (3.48) and redefined during execution of a program

data entity

data object (3.42), result of the evaluation of an expression, or the result of the execution of a function reference

data object

constant, variable, or subobject of a constant

which is circular, and doesn't seem to include individual array elements.

So now the question is which "definition" does the DO CONCURRENT constraint refer to?

>From the syntax definitions:

R1129

concurrent-locality

is

[ locality-spec ]...

R1130

locality-spec

is LOCAL ( variable-name-list )

or LOCAL_INIT ( variable-name-list )

or REDUCE ( reduce-operation : variable-name-list )

or SHARED ( variable-name-list )

or DEFAULT ( NONE )

only allows variable-name, not designator, so it's not exactly clear.

The "constraint" appears in normative text, I.e.

If a variable has

which is not hyperlinked and is not in a font indicating reference to the syntax term.

My reading of this is that we have a subtle contradiction between the syntax and normative terms. My guess is that the syntax meaning (i.e. an array element is a variable) is what is intended for the rules here, and thus it's valid to (un)define *different* elements of an array in separate iterations, but not valid to (un)define and reference the same element of an array in separate iterations.

I think it would be worth "fixing" the terms and definitions to eliminate the circular definition and make it consistent with the syntax.

Regards,

Brad

On Tue, 2023-09-12 at 17:37 +0000, Clune, Thomas L. (GSFC-6101) wrote:

“Variable” does not mean what we think it means:     <variable>   <<is>>  <designator> <<or>> <function-reference>

And <designator> includes <array-element>.

But I for one would not mind an explanatory note that clarifies the common use case of array elements in this context. 

From:J3 <j3-bounces at mailman.j3-fortran.org <mailto:j3-bounces at mailman.j3-fortran.org> > on behalf of j3 <j3 at mailman.j3-fortran.org <mailto:j3 at mailman.j3-fortran.org> >
Reply-To: j3 <j3 at mailman.j3-fortran.org <mailto:j3 at mailman.j3-fortran.org> >
Date: Tuesday, September 12, 2023 at 12:19 PM
To: j3 <j3 at mailman.j3-fortran.org <mailto:j3 at mailman.j3-fortran.org> >, WG5 <sc22wg5 at open-std.org <mailto:sc22wg5 at open-std.org> >
Cc: Brad Richardson <everythingfunctional at protonmail.com <mailto:everythingfunctional at protonmail.com> >
Subject: [EXTERNAL] [BULK] [J3] [SC22WG5.6477] are race conditions allowed in do concurrent?

CAUTION: This email originated from outside of NASA.  Please take care when clicking links or opening attachments.  Use the "Report Message" button to report suspicious messages to the NASA SOC. 

Hi Jeff,

Based on " If it is defined or becomes undefined during any iteration, it shall not be referenced, defined, or become undefined during any other iteration.", the provide program is invalid, because `x` becomes defined in more than one iteration.

The way I've heard "definition" applied to arrays is that definition of an element of an array does not constitute definition of the variable, because it is then only partially defined. I.e. an array is only defined once each of its elements has been defined.

My opinion is that the above constraint simply does not adequately describe/is still ambiguous about the case of arrays. I think an interp would be warranted, and we should say that an element of an array should have the same constraint as above if the variable is shared.

Regards,

Brad

On Tue, 2023-09-12 at 14:43 +0000, Jeff Hammond via J3 wrote:

Is this a legal program in Fortran with defined behavior?  If it is illegal or the behavior is undefined, where do we say that?

program main

  integer :: k

  real :: x

  x = 0.0

  do concurrent (k=1:2) shared(x)

    x = real(k)

  end do

  print*,x

end program main

Is that what the following is intended to do?

“If a variable has SHARED locality, appearances of the variable within the DO CONCURRENT construct refer to the variable in the innermost executable construct or scoping unit that includes the DO CONCURRENT construct. If it is defined or becomes undefined during any iteration, it shall not be referenced, defined, or become undefined during any other iteration.”

If so, then I am struggling to apply this to arrays.  When we say a variable has shared locality, is the variable the array or the element?  We can only put array names in SHARED(), but applying the text regarding “to become defined” from the perspective of arrays appears to have interesting consequences.

Thanks,

Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20230914/6bc2c182/attachment-0001.htm>