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

[Malcolm Cohen]

N.M. Maclaren wrote:

>
> In my experience, the unstructured nature of aliasing control is a more
> important factor, but I agree that getting unstructured parallelism 
> controls
> right is error-prone in the hands of experts and completely hopeless 
> in the
> hands of non-experts.

Bill Long wrote:
>
> I dislike this sort of imperious condescension. While it might be the 
> case that some hapless beginners will get things wrong,

Accusations of "imperious condescension" and implications that fellow 
committee members are "hapless beginners" (which sounds condescending in 
itself) are out of place on an international mailing list.  Your 
technical arguments would be stronger if you left this stuff out.

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

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.  We didn't do it that way, but expressing 
the opinion that the basic features the user is presented with should be 
robust and high level is not exactly heretical in my view: reasonable 
people can disagree about specific technical choices.

(As it happens, I agree that an something like an ISO_PARALLEL_ENV with 
the more obscure and harder-to-use or easier-to-get-wrong stuff in it 
would have been a good idea - though there are arguments on both sides.  
That doesn't mean I want to rewrite that stuff now though.)

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.  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.
>   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.  Again, JRFP is certainly going to fall into all the obvious 
well-known traps we provide for him.)

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.

Cheers,
-- 
.........................Malcolm Cohen, Nihon NAG, Tokyo.