(j3.2006) (SC22WG5.3653) [ukfortran] FW: Notes on WG5 coarray papers
Mon Nov 10 21:31:11 EST 2008
I have a couple of obvious comments...
> As a consequence, the object must additionally be a scalar, since the last
> cited sentence would also apply to arrays of the above types. It may be
> necessary to change the wording of 8.5.1, para6 to
> "A scalar coarray
An array is just a collection of scalars. We've been here before: it is
not trivial to describe what you seem to be meaning in standardese, and
might not have the effect you thought you were intending.
I'm not necessarily arguing about what your probable intent is here, but
you are not going to hit all (or possibly even most) of the problem
cases just by putting the word "scalar" in this one place.
> the following additional Note is suggested for 8.5.1:
> NOTE 8.29a
> A scalar coarray that is volatile and of type default integer, default real,
> or default logical is 'atomic' in the sense that read accesses from any image
> other than those altering its value will obtain either the value previous to
> an alteration, or the value after an alteration.
Be careful: either there is normative text that obviously supports this
(in which case the note is probably unnecessary), there is normative
text but the reasoning to get here is convoluted (in which case an
explanation would be useful) or there is no normative text (in which
case the note is wrong - it's not worded as a requirement, and
requirements are not allowed to appear in notes anyway).
In any case, I find this suggested note wanting.
> Example 2.3 ("Composite object") is non-conforming since the VOLATILE
> coarray is not a scalar and hence the restrictions from 8.5.1 apply.
You mean "would not be conforming if we could somehow word the
restriction I want". There is no such restriction in 8.5.1 at present
that I see.
> Example 2.4 ("Protected Context") is non-conforming since the cited
> restriction is violated by the object in question being VOLATILE within
> the scope of the DO loop. This would apply even if the CASE(1) statements
> were not present.
There is no restriction that says a DO index variable cannot have the
VOLATILE attribute, and the "cited restriction" does not even mention
VOLATILE. So I cannot agree with your reasoning. (In fact I think the
example is conforming when used as described in the paper.)
> In section 4 ("Behaviour on Commodity Clusters"), the example with the
> INTEGER, VOLATILE :: table(1000)[*]
> has a high likelihood of being non-conforming since again the object is
> not scalar, and there may be updates coming in from other images in an
> unordered segment.
Au contraire, there are no references to the array table in the example
code, only to scalar subobjects thereof. Scalar subobjects of a
VOLATILE object are themselves VOLATILE. And scalar. And thus don't
even fall foul of the imaginary restriction that is not yet in 8.5.1.
..........................Malcolm Cohen, Nihon NAG, Tokyo.
More information about the J3