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

[N.M. Maclaren]

On Jun 25 2009, Bill Long 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.

In principle, that is true.  In practice, people will both leave
existing mechanisms in when converting programs, and will use those when
they provide mechanisms that the users prefer (for whatever reason).
Note that I said "will" not "should".

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

S-3901-60 makes no reference to the use of VOLATILE for atomicity, which
is precisely why I included it there.  Furthermore, I specifically
looked for VOLATILE coarray support on your Web pages when writing N1754
(in October 2008), and the latest language reference manual that I could
find did not mention it.

What version of the manual WAS it first documented in?

You are doubtless correct that Cray has supported it for some time, but
I would expect the vast majority of the people who know about supported
but undocumented facilities to be classifiable as 'experts'.

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

Most users do claim that the implementation is buggy, but my experience
is that 90% of their failures are actually where they have relied on
undefined or processor dependent features.  I have not so far heard of
anyone who has experience with serious use of coarrays in f95.

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

That is a very one-sided point of view.  While it is true that
performance sells computers, it is NOT necessarily what 'sells'
programming languages.

In the past decade, we have seen major shifts of much of conventional
programming from 'performance' languages to more powerful equivalents
(Matlab, Mathematica are examples).  I am pretty sure that more Fortran
coders have converted to one of those two than to C++.  In the past, the
same was true when Algol and Fortran replaced the various Autocodes
(and, no, it WASN'T primarily portability, because we are talking the
1960s here).

A more directly relevant issue is the number of parallel programming
paradigms that have failed to take off because users couldn't debug
their code (especially up to the level of portability).  To a great
extent, that applies to all of ScaLAPACK, HPF, OpenMP and POSIX threads,
plus a multitude of less widespread paradigms; HPF had performance
problems as well, of course.  It has even affected MPI non-blocking
transfers; I have no feel for what has prevented MPI one-sided transfers
from taking off.

And closely related to that is the matter of tuning.  Both atomics and
non-acquiring locks bring in the potential for livelock and (much worse)
constructions whose very correctness depends on the properties of the
scheduler.  Most HPC systems are set up so that the scheduling system is
'HPC friendly' and there are no more images than cores.  But doing that
on general operating systems requires the ADMINISTRATOR to jump through
hoops, and users WILL have problems on any system not set up for HPC.
That issue is why quite a lot of users have abandoned OpenMP and POSIX
threads.

Will coarrays do better?  It remains to be seen.  But my point is that it
is a good idea to try to avoid the features that we know have caused trouble
with those paradigms - and explicit, low-level, unstructured synchronisation
is one such aspect.


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