(j3.2006) (SC22WG5.4044) [ukfortran] LOCK/UNLOCK question

[N.M. Maclaren]

On Jun 25 2009, Bill Long wrote:
>> 
>> What version of the manual WAS it first documented in?
>
>Our current documentation policy is that the manuals mention only 
>differences between our implementation and the standard. Since 6.0 in 
>2007, we've used Fortran 2003 as the base standard for the document. 
>Since VOLATILE is part of the standard, it is not mentioned in the 
>documentation.  Ironically, when Fortran 2008 is published and we switch 
>to that as the base, we will need to start documenting that off-image 
>references to VOLATILE coarrays are exempted from the segment ordering 
>rules as an extension.

Yes, I know that.

The only relevant wording for VOLATILE in the Fortran 2003 standard is
in 5.1.2.16:

    The VOLATILE attribute specifies that an object may be referenced,
    defined, or become undefined, by means not specified by the program.

    NOTE 5.21
    The Fortran processor should use the most recent definition of a
    volatile object when a value is required. Likewise, it should make
    the most recent Fortran definition available. It is the programmer's
    responsibility to manage the interactions with the non-Fortran
    processes.

It requires a leap of faith to assume that it will have inter-image
atomicicity (let alone synchronicity) properties.  And, anyway, the
WHOLE support for multiple images was a Cray extension, and so was
necessarily outside the standard!  Any experienced programmer will
look in the processor-dependent section for what semantics can be
assumed for VOLATILE coarrays - and there wasn't any - so almost all
experienced programmers would avoid them like the plague.

Sorry, no, that does NOT count as providing enough documentation to
claim that there is significant experience by ordinary users.

>I'd argue that in the case of ScaLAPACK and HPF, the difficulty of 
>understanding how to write the program in the first place was a bigger 
>cause of failure than debugging.

You might.  It's not my experience.

>By comparison, I think OpenMP has been 
>widely successful for local (i.e. within image) shared-memory 
>parallelism.  The advent of multi-core chips has increased its usage.

That is not my experience, either.

>While there are some performance issues, and serious scaling 
>limitations, I think the OpenMP crowd can feel pretty good about its 
>acceptance. It's in enough benchmarks that vendors are essentially 
>forced to support it.

When I first came to specify it in a procurement, I had to write my own
benchmarks because there were NO open source OpenMP programs around.
There are now a few, but its acceptance is still very poor.  It is still
very much second to MPI, even on shared-memory systems.

>It has even affected MPI non-blocking
>> transfers; I have no feel for what has prevented MPI one-sided transfers
>> from taking off.
>
>I suspect it is partly inertia. Some who need one-sided transfers 
>already have access to coarrays or UPC which are a lot easier to code 
>than MPI. Others have been using Shmem for years, and see no point in 
>converting.

(a) That doesn't apply to MPI non-blocking transfers and (b) several of
the people I know of converted from their SHMEM code to MPI blocking calls
precisely because they couldn't debug their program when they needed to
move to a new system.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679