(j3.2006) LOCK/UNLOCK question

[Bill Long]

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