To: J3                                                   08-248r1
From: Bill Long
Subject: Reply to Comment J32034
Date: 11 Aug 2008
References: J3/08-007r2 (WG5/N1723)

-------------------------

Comment from James Giles:

I won't be commenting on most of the CO-ARRAY features
because I don't quite yet fully understand them.  But in
most of the different kinds of parallel computing I've done
in the past the need for critical sections arises.

Instead of a CRITICAL construct, I think that CRITICAL
should be a keyword like PURE or RECURSIVE (and such) that
applied to procedure declarations.  Similarly, it should
be an optional keyword on the new BLOCK construct:

block-stmt is [ block-construct-name : ] [ CRITICAL ] BLOCK

The reason is that when I've needed critical sections the
shared data being manipulated is often something that should
be imported (USE) for that particular section alone and not
visible elsewhere.  There are also often additional local
variables needed only temporarily for manipulating the
shared data.  So it's often the case that critical sections
coincide with the need for declarations.  Rather than add
the ability to declare within CRITICAL constructs, it makes
sense to  combine the feature with existing constructs that
already can declare things.

As an aside, except for this possible merging with CRITICAL,
the only real value I see for the BLOCK construct is if some
form of control of host association is forthcoming.

------------------------

J3 Response:

Many of the expected uses of a CRITICAL construct involve the simple
update of a coarray on a fixed image, or forced ordering of input and
output operations.  These uses are addressed fully by the simple
CRITICAL construct.

By separating the CRITICAL and BLOCK constructs in the standard, an
implementation could implement one without the other, providing
greater flexibility in meeting customer demands.

The argument for combining the critical idea with blocks or procedures
has merit and could be considered in a future standard. These ideas
could be incorporated as natural extensions of the current
specification. We prefer to not include the feature in this revision
of the standard.