(j3.2006) LOCK/UNLOCK question

[dick.hendrickson at att.net]

  -------------- Original message from Bill Long <longb at cray.com>: --------------


> 
> 
> Aleksandar Donev wrote:
> > Malcolm Cohen wrote:
> > 
> >> "During an execution of a statement that invokes more than one
> >> procedure, at most one invocation shall cause execution of an image
> >> control statement other than CRITICAL or END CRITICAL."
> 
> 
> We've mucked around with the list of image control statements, and I 
> think just overlooked updating this sentence.  Given the similar nature 
> of LOCK/UNLOCK and CRITICAL/END CRITICAL, it seems reasonable to treat 
> them the same here.  
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?   

Dick Hendrickson


>As Malcolm points out, a reasonable user might want 
> to use this capability.  The key point here is that execution of none of 
> these involves (at least semantically) the cooperative participation of 
> any other image.  Actually, SYNC MEMORY falls into the same class.  I 
> would further argue that STOP should be allowed in such a function.  We 
> want people to be able to deal with error cases in the usual ways.  If 
> someone executes a STOP statement in one of the two functions referenced 
> in a statement, the second function will never get executed anyway 
> unless the functions are executing in separate local threads. Even then, 
>    allowing STOP should cause no problem.
> 
> 
> Cheers,
> Bill
> 
> 
> 
> >>
> >> I am puzzled as to why this doesn't allow LOCK/UNLOCK, since these are
> >> data-object equivalents to CRITICAL/END-CRITICAL. Yes this is only
> >> "good" if the LOCK/UNLOCK are either correctly "paired" within each
> >> procedure or if they operate on disjoint locks
> > By good do you mean "legal"? We can and perhaps should allow LOCK/UNLOCK 
> > as well, but then there is the danger that someone may in fact write 
> > code where the correct functioning depends on the procedures being 
> > executed in the same order on all images, which we do not want to 
> > guarantee. What rule tells that user that his code is "not good"? Either 
> > we should give proper semantics, in which case we tell the compilers to 
> > disable optimizations (or some such), or we need some additional 
> > constraints/restrictions.
> > 
> > As an aside, I argued and still believe that we need a CRITICAL(lock) 
> > construct for exactly these sort of reasons. I was not at the J3 meeting 
> > where my proposal was rejected so I do not know the reasons, but given 
> > that proposal was rejected my suggestion is to keep things "safe" and 
> > keep the existing text.
> > 
> >  > An oversight? Deliberate?
> > I seem to recall a direct discussion of this point at the last meeting 
> > but am not certain. I am cc'ing Nick since he was also there and may 
> > care about this issue.
> > 
> > Best,
> > Aleks
> > 
> 
> -- 
> 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
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://j3-fortran.org/pipermail/j3/attachments/20090617/055472fc/attachment.html