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

[Bill Long]

N.M. Maclaren wrote:
> 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. 


The manual is specific to a particular combination of compiler and 
supported hardware.  For that hardware, there is no atomicity problem. 
(Besides, the same atomicity would affect other sorts of volatile memory 
operations - not just those related to coarrays.)



  And, anyway, the
> WHOLE support for multiple images was a Cray extension, and so was
> necessarily outside the standard!  

Yep. There is a whole section of the manual devoted to coarrays.


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.

The extension of volatile to coarrays was so completely obvious and 
trivial for this hardware that it did not seem necessary to include 
documentation.

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

Since when do ordinary users actually read the documentation? :)  In my 
experience, they tend to just try what they think should work, and read 
the docs only if the result is failure. In this case, things work the 
way one would naively expect.


> 
> 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.
> 

The benchmarks I referred to are actual customer production codes. 
OpenMP often occurs in them.  MPI occurs in almost every benchmark, 
including the ones that use OpenMP.  So, yes, MPI is solidly in first 
place, at least for now.


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