(j3.2006) (SC22WG5.3649) [ukfortran] A comment on John Wallin's comments on Nick MacLaren's comments
Bill Long
longb
Fri Nov 7 16:31:03 EST 2008
N.M. Maclaren wrote:
>
> The (simplified) issue is whether SYNC MEMORY is allowed to wait until the
> image that owns the data it is accessing reaches the next image control
> statement. No more than that.
>
I would have to say no to the idea of allowing SYNC MEMORY to wait for
other images to arrive at an image control statement. It lacks an
exclusion for volatile coarrays. For the important case of the
spin-loop synchronization you could end up with a hung program. Even in
the non-volatile case, I don't see it as necessary. Finally, it is
inconsistent with the semantics that SYNC MEMORY is a local operation
(irrespective of how it might be actually implemented).
> Yes, it would be possible to introduce a TIMEOUT value into SYNC MEMORY,
> and set STAT if it were exceeded, but that wouldn't help. All it would
> do is to allow a cautious programmer to diagnose the deadlock from within
> the program, rather than having it show up as a hung program. It wouldn't
> make it any easier to write portable code.
>
>
The standard wording is sufficiently "processor dependent" that an
implementation is already allowed to associate a specific STAT value
with a timeout condition. It would not be portable, though a single
named constant in a module might be all that is required for easy
porting. I agree that this is not the desired answer to the original
question.
Cheers,
Bill
--
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120
More information about the J3
mailing list