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

[Bill Long]

Malcolm Cohen wrote:
> 
> 
>> there are a lot of very good programmers out there who directly 
>> benefit from access to powerful features. They should not have their 
>> hands tied. Rather, we should cater to their needs.
> No, we should cater to the needs of all our users, we ABSOLUTELY should 
> not cater to one small subset if that would be at the expense of a 
> majority.

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.


> 
> I again quote our purpose:
>    "to promote portability, reliability, maintainability and efficient 
> execution"
> 
> 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.


> 
> Also, "low-level" and "powerful" are often not synonyms... if you said 
> "flexible" instead of "powerful" that would be more reasonable, though 
> some might say that sufficient rope is always flexible.
>>> I agree that it would be better to separate atomics, SYNC MEMORY and 
>>> locks out into a separate module, for 'library implementors' only, 
>>> and keep the basic features at a higher and more robust level. 
>> I also don't entirely agree with the philosophy that all sophisticated 
>> coding should be confined in libraries where it is hidden from all but 
>> a few self-appointed experts.
> This seems unnecessarily defensive.  We separated out quite a few things 
> into ISO_C_BINDING and ISO_FORTRAN_ENV without it being "hidden from all 
> but a few".
> 
> There's no real reason ATOMIC_DEFINE and ATOMIC_REF couldn't have been 
> in ISO_FORTRAN_ENV or even better, in ISO_PARALLEL_ENV along with 
> LOCK_TYPE, SYNC MEMORY, etc.  

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.


> 
> Common-or-garden scientist/engineer programmers don't want to reprogram 
> basic parallelism from scratch, they just want to use the language to 
> solve their problems.  

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.


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?


>>   It's quite possible that someone else would come up with a new 
>> approach that is better - as long as (s)he has access to the tools.
> And putting them all into ISO_PARALLEL_ENV would not have prevented that.
> 
> (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.


  Again, JRFP is certainly going to fall into all the obvious
> well-known traps we provide for him.)

I'm not so certain. But if he does, it will be a good learning 
experience, and he'll be a better programmer in the long run.

> 
> I might not agree with Van that LOCKs are too low-level to be 
> effectively usable (they are not as low-level as test-and-set, or for 
> that matter the atomic stuff), but I understand his mystification as to 
> why we don't have more powerful higher-level abstractions.  Maybe we're 
> just going to have to work through a couple of "GOTO 
> spaghetti"-equivalent decades of parallel programming before we get to 
> something usable, but I hope not.


I expect not.

Cheers,
Bill



> 
> Cheers,

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