(j3.2006) LOCK/UNLOCK question

[Malcolm Cohen]

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.
>
>
>
>     > However, it is also possible (and more likely) for a programmer
>     to write
>     > a function with both the lock and unlock, in the right order, and
>     > serving a useful purpose.
>     >
>     > I'd lean towards letting the second programmer do the useful
>     thing at
>     > the expense of having to tell the first programmer that he has
>     written a
>     > badly designed program.
>     >
>     But it's more than just telling him it's badly designed.  You've
>     got to
>     get the words right to define all of the illegal (not unwise) cases.
>
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
>     think it's harder than just adding LOCK/UNLOCK to the paragraph
>     in question.
>
Just adding LOCK/UNLOCK to the paragraph in question allows the "obvious 
reasonable" case where a function reference does a lock-unlock, and 
allows the "less obvious but semi-reasonable" case where a function 
reference does a lock or unlock and no other function reference in the 
statement touches that particular lock variable.

What is so evil about

   X = F(Y1) + F(Y2)

when Y1 and Y2 have LOCK_TYPE components and F does a LOCK-UNLOCK on 
those components.
>
>
>     I don't think it's totally unreasonable to acquire a lock in one
>     routine and
>     release it in another.
>
Not totally unreasonable, but certainly error-prone and likely to be bad 
practice.  And as you pointed out, we would not be allowing the user to 
do this anyway when the procedures are invoked by the same statement 
execution.
>
>       I can even imagine using a lock variable that is never
>     unlocked as a "control construct" to set up an execute only once
>     on whatever
>     image gets here first block of code.
>
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.

I don't think we need to consider this case with multiple procedure 
invocations from a single statement hitting the same 
locked-once-never-unlocked variable since it is invalid now and no-one 
is proposing to allow it.  Well, I hope no-one is proposing to allow it.
>
>
>     > dick.hendrickson at att.net wrote:
>     > >
>     > >
>     > > Isn't one big difference that lock/unlock isn't a block
>     construct.
>     > > If I understand
>     > > it right, there's no requirement that the lock and unlock
>     statement
>     > > be in the
>     > > same procedure. [I don't even think you need an unlock
>     statement.]
>     > > What would
>     > > prevent the optimizer from invoking the procedure with the unlock
>     > > first?
>     > > 
>
And I agree with your first point above that this would still not be 
valid after the "proposed" change and your second point that we would 
not want it to be valid.  (I say "proposed", but I didn't quite go so 
far as to "propose" it, I just wondered whether the omission was a 
deliberate or accidental.)

My concern was more that the user writing a function meant to be "safe" 
would
   (a) not see the difference between CRITICAL-ENDCRITICAL and 
LOCK-UNLOCK here;
   (b) given the scalability issues, might change a "legal" 
CRITICAL-ENDCRITICAL into a LOCK-UNLOCK.

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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://j3-fortran.org/pipermail/j3/attachments/20090618/b743af1d/attachment.html