<br><tt><font size=2>j3-bounces@j3-fortran.org wrote on 06/17/2009 12:27:25
PM:<br>
<br>
> Isn't one big difference that lock/unlock isn't a block construct.
<br>
> 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>
</font></tt>
<br><tt><font size=2>Short circuit in expression evaluation (such as in
IF (f(...) .or. g(...)) is another case that a compiler may choose not
to evaluate g() at all if f() turns to be true. I think in general
it is risky to relax restrictions on LOCK/UNLOCK in compound expression
when evaluation ordering is unclear. However in some cases, such
as recursive procedure calls, the order is well defined, and these image
control statements can be safely used.</font></tt>
<br>
<br><font size=2 face="sans-serif">Cheers,</font>
<br>
<br><font size=2 face="sans-serif">Jim Xia<br>
<br>
XL Fortran Compiler Test<br>
IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7<br>
Phone (905) 413-3444 Tie-line 313-3444<br>
email: jimxia@ca.ibm.com<br>
D2/YF7/8200 /MKM<br>
<br>
</font><a href=http://www.ibm.com/software/awdtools/fortran/xlfortran><font size=2 face="sans-serif">http://www.ibm.com/software/awdtools/fortran/xlfortran</font></a>
<br>