<html>
<!-- BEGIN WEBMAIL STATIONERY -->
<head></head>
<body>
<!-- WEBMAIL STATIONERY notheme -->
<div></div>
<!--<BR>-->
<div> </div>
<blockquote style="border-left: 2px solid rgb(16, 16, 255); padding-left: 5px; margin-left: 5px;">
-------------- Original message from Bill Long <longb@cray.com>: --------------
<br>
<br>
<br>>
<br>>
<br>> Aleksandar Donev wrote:
<br>> > Malcolm Cohen wrote:
<br>> >
<br>> >> "During an execution of a statement that invokes more than one
<br>> >> procedure, at most one invocation shall cause execution of an image
<br>> >> control statement other than CRITICAL or END CRITICAL."
<br>>
<br>>
<br>> We've mucked around with the list of image control statements, and I
<br>> think just overlooked updating this sentence. Given the similar nature
<br>> of LOCK/UNLOCK and CRITICAL/END CRITICAL, it seems reasonable to treat
<br>> them the same here. <br>Isn't one big difference that lock/unlock isn't a block construct. If I understand<br>it right, there's no requirement that the lock and unlock statement be in the<br>same procedure. [I don't even think you need an unlock statement.] What would<br>prevent the optimizer from invoking the procedure with the unlock first? <br><br>Dick Hendrickson<br><br><br>>As Malcolm points out, a reasonable user might want
<br>> to use this capability. The key point here is that execution of none of
<br>> these involves (at least semantically) the cooperative participation of
<br>> any other image. Actually, SYNC MEMORY falls into the same class. I
<br>> would further argue that STOP should be allowed in such a function. We
<br>> want people to be able to deal with error cases in the usual ways. If
<br>> someone executes a STOP statement in one of the two functions referenced
<br>> in a statement, the second function will never get executed anyway
<br>> unless the functions are executing in separate local threads. Even then,
<br>> allowing STOP should cause no problem.
<br>>
<br>>
<br>> Cheers,
<br>> Bill
<br>>
<br>>
<br>>
<br>> >>
<br>> >> I am puzzled as to why this doesn't allow LOCK/UNLOCK, since these are
<br>> >> data-object equivalents to CRITICAL/END-CRITICAL. Yes this is only
<br>> >> "good" if the LOCK/UNLOCK are either correctly "paired" within each
<br>> >> procedure or if they operate on disjoint locks
<br>> > By good do you mean "legal"? We can and perhaps should allow LOCK/UNLOCK
<br>> > as well, but then there is the danger that someone may in fact write
<br>> > code where the correct functioning depends on the procedures being
<br>> > executed in the same order on all images, which we do not want to
<br>> > guarantee. What rule tells that user that his code is "not good"? Either
<br>> > we should give proper semantics, in which case we tell the compilers to
<br>> > disable optimizations (or some such), or we need some additional
<br>> > constraints/restrictions.
<br>> >
<br>> > As an aside, I argued and still believe that we need a CRITICAL(lock)
<br>> > construct for exactly these sort of reasons. I was not at the J3 meeting
<br>> > where my proposal was rejected so I do not know the reasons, but given
<br>> > that proposal was rejected my suggestion is to keep things "safe" and
<br>> > keep the existing text.
<br>> >
<br>> > > An oversight? Deliberate?
<br>> > I seem to recall a direct discussion of this point at the last meeting
<br>> > but am not certain. I am cc'ing Nick since he was also there and may
<br>> > care about this issue.
<br>> >
<br>> > Best,
<br>> > Aleks
<br>> >
<br>>
<br>> --
<br>> Bill Long longb@cray.com
<br>> Fortran Technical Support & voice: 651-605-9024
<br>> Bioinformatics Software Development fax: 651-605-9142
<br>> Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120
<br>>
<br>>
<br>> _______________________________________________
<br>> J3 mailing list
<br>> J3@j3-fortran.org
<br>> http://j3-fortran.org/mailman/listinfo/j3
</blockquote>
<!-- END WEBMAIL STATIONERY -->
</body>
</html>