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

[N.M. Maclaren]

On Jun 25 2009, Bill Long wrote:
>
>I agree with that. I just don't think that providing these lower-level 
>capabilities comes "at the expense of a majority".  No one forces users 
>to implement spin loops.   We supply a lot of features that have narrow 
>usage (erfc(), for example).  But they are sufficiently interesting to 
>enough users that we include them.

Even before the bureaucrats got in on the act, engineers and similar
realised that it was essential to have standard procedures and rules on
what must not be done, so that relatively inexperienced workers did not
make catastrophic errors when working under stress.  That is most of the
point of military training, too.  The point is that, humans being what
they are, UNDER THOSE VERY COMMON CIRCUMSTANCES, flexibility is the enemy
of reliability.

Virtually EVERY designed item of hardware and software puts its more
flexible, powerful and tricky facilities behind some sort of a 'door',
which has to be explicitly opened to enable them.

>> There is a lot of experience with low-level parallelism providing the 
>> opposite of reliability and maintainability, and quite some experience 
>> with it providing the lack of portability too.  Efficient execution does 
>> not trump the other three parts of our purpose.
>
>But little to none of that experience is with Fortran constructs. The 
>experience I've seen with coarrays is that these constructs can be quite 
>reliable and maintainable. The current lack of portability is precisely 
>the reason for standardizing the features.

Eh?  Fortran is not a particularly unusual Von Neumann language, and
coarrays are not all that much different from many other parallel
models.  It is seriously bad science and engineering to ignore the
lessons that have been learnt in closely related areas.

There is another aspect - see later.

>ISO_PARALLEL might have been a better location for LOCK_TYPE - it really 
>has little to do with the "environment". SYNC MEMORY is a statement - I 
>don't see how that fits into a module. Overall, I'm happy with the 
>current arrangement.

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.

>Certainly no one is requiring them to reprogram basic parallelism from 
>scratch.  Indeed, most of them will want to migrate their current MPI 
>programs to use coarrays incrementally. That's what many of the current 
>users of coarrays are doing.  And some have found that customized spin 
>loop synchronization is a useful tool in that context. Others use only 
>SYNC ALL for synchronization.  It depends on the nature of the code.

Nobody is say that they shouldn't write encapsulated spin loops, though
LOCK/UNLOCK would generally be a cleaner method.  The problems arise
with ensuring that data are not accessed in unsynchronised segments,
when there is a lot of shared data and lots of images all synchronising
in an unstructured fashion.

>Providing them with low-level parallel stuff is
>> asking for trouble - 90% of them don't have the background to avoid 
>> falling into the more obvious traps, let alone the less obvious ones.
>
>Well, that's not been the experience I've seen with coarray users so 
>far. Maybe they are all "experts".  Of course, most of that experience 
>is with volatile coarrays rather than the somewhat less elegant atomic 
>subroutines.  But I don't think they will have that hard a time with the 
>adjustment.  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'.

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

>> (Actually, the idea that Joe Random Fortran Programmer is going to come 
>> up with some dynamic new way of using the same old low-level parallel 
>> stuff that will revolutionise the parallel programming industry is 
>> beyond wishful thinking.  Lots of very bright people have been and are 
>> still working on these problems, and the current absence of SYNC MEMORY 
>> and LOCK in Fortran does not appear on any list of obstacles I have ever 
>> seen. 
>
>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.  In the 1990s, they
realised (but did not admit) their mistake, and people have been busy
reinventing the wheel ever since - sometimes even getting the number of
sides right, too.

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


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