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

[Bill Long]

N.M. Maclaren wrote:

> 
> It is the problem of putting SYNC MEMORY there that makes me feel that
> this can't be done - as I have said many times, users WILL use C code,
> POSIX and I/O for synchronisation, in conjunction with that.  And those
> bring in all of the problems being referred to.


We have provided enough capabilities that the use of C code, POSIX, and 
I/O synchronization should no longer be necessary.  This seems like an 
excellent topic for a section of a textbook on Fortran 2008.


  Also, I'm convinced that users who can get by with just
>> SYNC ALL and SYNC IMAGES will never venture into the low-level stuff. 
>> Why would they?
> 
> With all respect, Bill, I have some doubts that your experience is
> representative.  I searched Cray's documentation, and that use of
> VOLATILE was not documented until December 2008!  See, for example:
> 
>     http://docs.cray.com/books/S-3901-60
>     http://docs.cray.com/books/S-3901-70
> 
> Any experience before 2009 must necessarily have been in-house and
> selected users of pre-release software only - and I would expect the
> vast majority of those people to be classifiable as 'experts'.

We completely revamped our documentation with the 6.0 release (the 
S-3901-60 manual) which we release in September, 2007.  The older 
manuals might be no longer online.  However, I can assure you that we 
(like many other vendors) have supported VOLATILE for a very long time, 
and coarrays in compilers released to customers since 1998.  What you 
claim "must necessarily have been" is not correct.


> 
> Secondly, there is essentially no experience with coarrays outside Cray,
> so you can have little to no experience with code written for Cray
> coarrays being ported to other implementations. 

This is valid observation. It is often the case that new features in the 
language have limited prior implementation experience. So far we've 
implemented coarrays on four different network interconnects (excluding 
the never-released SGI Origin version), are mostly done with a fifth due 
for release next year, and I'm mostly focused on a 6th that's in design 
stage. No disasters so far.


  And, as I said above,
> THAT is when most experts will realise that there 'working' code was
> actually buggy, but the bug had not previously shown up.

Or that the new implementation is buggy, which is not that uncommon with 
new implementations of any non-trivial feature.  The initial f90 
implementations were not optimal either.  But vendors eventually got the 
kinks out and I think the overall result has been success.  I expect a 
similar trajectory for coarrays.  Andy seems to be off to a good start 
with g95, which is very encouraging.



>> But their work was outside Fortran - before coarrays there were no 
>> Fortran facilities at all.  LOCK was added precisely because there were 
>> situations where the previous set of tools was inadequate.
> 
> That attitude is appallingly reminiscent of the way that the 1970s and
> 1980s 'computer scientists' said that none of the previous mainframe,
> Fortran, Algol, Cobol and other experience was relevant.  And so we
> ended up with C-like languages, Unix and Windows 3.  

Thanks for the warning about "computer scientists". :)

We still have Fortran and Cobol. I think C was a big improvement over 
assembly language, which it was intended to replace. It also had a 
brilliant marketing strategy - provide free compilers to students. (The 
Java crowd was smart enough to realize this, with similar results.) So 
far, I've been mostly successful in avoiding Windows.

I started on mainframes and later migrated to Unix. I would never want 
to go back.  The same era also gave rise to VMS, which was (in my 
opinion) even better. Some of the VMS ideas are still being migrated 
into Unix-based systems. Unfortunately, DEC management thought that the 
elegance of their software was so compelling that the relatively weak 
performance of the VAX processors did not matter. That turned out to be 
commercially fatal, and a lesson imprinted on other vendors since.


> 
> Fortran, of all languages, should not make that mistake, especially
> not through intellectual arrogance.
> 

Agreed. Especially the lesson that performance is what sells. If Fortran 
did not offer better performance compared to more fashionable languages, 
its survival would be seriously endangered. Fortran 2003 has been 
roundly criticized for a swing too far in the direction of abstraction 
and theory. We need to keep up with "modern practices" to some extent, 
but cannot ignore the basis for continued acceptance.

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