(j3.2006) Integration of co-arrays with the intrinsic shift functions
Wed Jul 18 22:42:58 EDT 2007
On Thu, 19 Jul 2007 04:25:52 +0900, <dick.hendrickson at att.net> wrote:
> It's worse if the expression is something like
> X = f(b) + g(c)
> and the syncs happen in f and g. If every image is compiled with the
> same compiler, it doesn't matter because everything will be in the same
> (unspecified) order. If different images are compiled by different
> compilers, then they'll have to agree on expression evaluation odder. I
> think that's surprising.
Right, and this means that the argument about whether the CO_whatever is a
or a subroutine could be somewhat moot.
And you say "same compiler ... doesn't matter". But it's worse than that.
Evaluation order can be affected by compilation options,
in particular optimisation options.
So everything needs to be compiled with the same compiler with the same
This is getting pretty close to "the same executable".
The underlying mechanism/protocols of coarray handling are not
It seems unlikely that different vendors will all choose the same mechanism
with the same protocols - it's more likely that they'll all keep them as
trade secrets unless patented.
BTW, we've slightly acknowledged the problems in 7.1.7 where we say
"If a statement contains a function reference in a part of an expression
that need not be evaluated, no invocation of that function in that part
of the expression shall execute an image control statement other than
CRITICAL or END CRITICAL."
(a) Obviously this doesn't even attempt to tackle the ordering question.
(b) I find the wording quite confusing.
(c) I doubt that whether the expression part "needs" to be evaluated is
the right distinction.
(d) Maybe it is apparently already caught for the whole expression by
"The evaluation of a function reference shall neither affect nor be
affected by the evaluation of any other entity within the statement."
(7.1.4). People (well Aleks anyway) seem to believe that
counts as a side-effect. So it seems pretty clear that synchronisation
is "affecting" the evaluation of anything else that is being
In particular, deadlock is obviously an effect.
Actually, the quoted text in 7.1.4 could be interpreted as ruling out
the same CRITICAL section being used by more than one function in an
expression. (Even if it doesn't, it rules out all useful CRITICAL
sections being used by more than one function!)
Malcolm Cohen, Nihon Numerical Algorithms Group KK, Tokyo, Japan.
More information about the J3