(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