(j3.2006) LOCK/UNLOCK question

[N.M. Maclaren]

Thanks, Aleks, for adding me to this.  Personally, I would prefer that the
WG5 list were used for these issues, as this will be a matter that will be
relevant during the voting.  However, here goes.


On Jun 18 2009, Malcolm Cohen wrote:
>dick.hendrickson at att.net wrote:
>>     -------------- Original message from Bill Long <longb at cray.com>:
>>
>>     > It is possible to have a clue-limited programmer who would put a
>>     > lock in
>>     > one function and an unlock for the same variable in a different
>>     > function, and then write a statement that executes both functions.
>>
>>     Actually, that's probably already illegal.  I think the
>>     no-side-effects-on-
>>     the-same-statement rule in section 7 would also apply to lock
>>     variables.
>>
>I agree - but I think this only underscores Bill's point.
>
> ...
>
>Well, we only needs words to define the cases we make valid; I believe 
>that, as long as we leave the "no-side-effects" rule intact we already 
>have the words for what LOCK/UNLOCK do.

I agree with that.  My understanding is that there is no statement in
which two impure subroutines can be called in an arbitrary order, where
no functions are involved in the call chain.  That is the circumstance
which would cause a major conflict between reasonable code and the above
wording.

In a parallel-ab-initio language, the problem (for BOTH ordinary side
effects and locks) would need addressing, but Fortran has so far shied
away from introducing such concepts.  At least, I THINK it has :-)

>I think that is close to totally unreasonable actually.  Either this is 
>a deliberate deadlock (obviously totally unreasonable) or the subsequent 
>images don't need to wait for the first block of code to be executed.  
>99.9% of the "execute once only" code I have ever seen has subsequent 
>references actually use some variable the execute-once-only code 
>initialised.

Not really, once you have atomics.  Think of a pseudo-random number
generator, memory allocator or whatever.  The fast path tests the atomic,
and uses the atomic only if it might need to initialise.  Yes, writing
such logic is a bit tricky, but it's not hard or unreliable.

But such logic is beyond Fortran's conventional envelope.

>I take Aleks' point though that if we had a sort-of "LOCK construct" 
>that this would be safer... but there is still no suggestion of lifting 
>the no-side-effect rule, and I don't think we should consider lifting 
>that rule in this revision if ever.

A far, far better solution would be to add a LOCK construct, and give
it the same exemption as CRITICAL.  TR fodder?


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